partition numbering changed after installing 7.10 gutsy

Bug #156476 reported by DF Morrow
8
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

After upgrade of 7.04 to 7.10, I could boot to windows XP but booting to UBUNTU gave grub error 15 File not found. Since the grub boot menu displayed properly I suspected a problem in grub's menu.lst. Inspection of menu.lst showed that the partition numbers had changed. The partition number for windows XP was 1 just as it was before. The partition number for UBUNTU had changed from 3 to 4. I used the GRUB boot diskette invoked the "find" function to find that GRUB found UBUNTU in partition 5. I updated menu.lst to change the partition number for the UBUNTU entries to 5. After that the boot function worked properly.

Analysis:

The partitions on my hard disk are as follows in address order:

number/type/file system/usage

0/primary/??/Dell Utility
1/primary/NTFS/Windows XP
2/extended/FAT32/shared
3/extended/ext3/UBUNTU
4/extended/??/UBUNTU swap
5/primary/??/Dell Restore

In 7.04 UBUNTU was number 3 as in the list. To get 5 as 7.10 does I would hypothesize that it counts 0 to 3 as the 4 primary partitions (including the primary extended partition) and then counts the the three extended sub-partitions as 4 through 6

Revision history for this message
DF Morrow (danfm01) wrote :

I'm not sure this is a duplicate. In bug 8497, the reported problems all involved multiple hard disk systems where the wrong hard disk number was assigned in menu.lst. In this case there was only one hard disk and the hard disk number (hd0) was always correct. The problem that occurred was with the partition number on the hard disk, i.e. (hd0,4) when (hd0,5) was what worked.

Revision history for this message
TJ (tj) wrote :

DF Marrow, I agree. It is related to another bug I've been looking at:

Bug #108554 "update leaves bootloader unable to find root partition"

In your circumstances I suspect the unexpected "Dell Restore" primary partition *after* the Extended partition is part of the issue. The numbering may have got confused.

Primary Partitions are numbered 1-4. Logical partitions in an Extended Partition are numbered 5-8, so the usual discoery order is:

1 Recovery/Utility
2 Windows
3 Extended
5 Ubuntu
6 Linux Swap

In your case it'll be something like:

1 Utility
2 Windows
3 Extended
5 Ubuntu
6 Linux Swap
4 Restore

The best way to solve it is to use UUIDs to identify each partition. You can discover them using:

$ ls -l /dev/disk/by-uuid

Add them to /boot/grub/menu.lst so you have something like this:

## ## Start Default Options ##

## default kernel options for automagic boot options
# kopt=root=UUID=bb2c3a14-1588-4fb9-8411-71f114b568b4 ro

## default grub root device
# groot=(hd0,4)

## ## End Default Options ##

title Ubuntu Gutsy 64-bit, kernel 2.6.22-14-generic
root (hd0,4)
kernel /vmlinuz-2.6.22-14-generic root=UUID=bb2c3a14-1588-4fb9-8411-71f114b568b4 ro quiet splash
initrd /initrd.img-2.6.22-14-generic
quiet
savedefault

title Ubuntu Gutsy 64-bit, kernel 2.6.22-13-generic (recovery mode)
root (hd0,4)
kernel /vmlinuz-2.6.22-13-generic root=UUID=bb2c3a14-1588-4fb9-8411-71f114b568b4 ro single
initrd /initrd.img-2.6.22-13-generic

title Ubuntu, memtest86+
root (hd0,4)
kernel /memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title Other operating systems:
root

# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda1
title Sony Windows Recovery Tool
root (hd0,0)
makeactive
chainloader +1

# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda2
title Windows Vista Home Premium
root (hd0,1)
makeactive
chainloader +1

Revision history for this message
Tormod Volden (tormodvolden) wrote :

I am not sure UUID will help, because only the initrd uses UUID to find the root partition when the kernel has booted. Grub can not use UUID (yet).

If the partition table was changed between 7.04 and 7.10 this is really not a bug, since grub only uses the partition numbering given to it by the BIOS. If this has changed, grub has to be told so to update its boot loader.

Revision history for this message
TJ (tj) wrote :

Tormod, good point. I was thinking at cross-purposes with some other grub-related issues I'm working on.

For this one I should have focused on the default setting of groot.

## default grub root device
# groot=(hd0,4)

Revision history for this message
DF Morrow (danfm01) wrote :

You asked if the partition table was changed between 7.04 and 7.10. The
answer is yes and no. The sequence of events was as follows.

1. -- 7.04 installed.
2. -- Created "shared" extended partition between "NTFS" and "Ubuntu
partitions using "Partition Magic" program to shrink "NTFS" to create
room.
3. -- GRUB totally failed to work.
4. -- Modified menu.lst to reflect new partition numbers and reinstalled
GRUB from the grub diskette. GRUB now worked. Partition numbers were
now: 1-Windows XP, 3-UBUNTU.
5. -- Installed 7,10.
6. -- Windows booted ok but UBUNTU didn't. menu.lst partition numbers
were 1-Windows XP, 4-UBUNTU. Install had apparently changed partition
numbers.
7. -- Ran GRUB diskette find function. It identified UBUNTU as
partition 5. This was the GRUB diskette I created from the 7.04
release!
8. -- Updated menu.lst to show UBUNTU as partition 5. Every thing
worked. I did not reinstall GRUB, so the installed GRUB should be the
one installed by 7.10, I presume.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

DF Morrow, can you please attach the output from: sudo fdisk -l
I do not understand why the partition numbering changed from step 4 to 7 and why it was changed in menu.lst from step 4 to 6. You just installed 7.10 in the same partition as 7.04, right?

Revision history for this message
DF Morrow (danfm01) wrote :

When I installed 7.10 over 7.04, I made no changes to the partitions.
Part of the problem may be a confusion over whether to start the
partition numbering at 1 or 0. The fdisk listing is attached.
sda4 is what I called the Dell Restore partition in previous messages.

Changed in grub:
status: New → Confirmed
Revision history for this message
DF Morrow (danfm01) wrote :

When I installed the latest system fixes this morning, the bug happened again. This update apparently changed the kernel files and in the process also altered menu.lst. The partition numbers of all the kernel entries were changed from (hd0,5) to (hd0,4). I had to edit menu.lst to restore the partition numbers back to (hd0,5) to get the system to boot linux. I did not have to reinstall grub. The bug apparently happens somewhere in the kernel update process.

dino99 (9d9)
Changed in grub (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.