Ubuntu
grub package

update leaves bootloader unable to find root partition

Bug #108554 reported by Robert Persson
6
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

This bug is similar to #75655, but I don't think it's the same one exactly.

Having been away from my desktop machine since early january I have just installed all the Edgy updates that have been issued since then. When I tried to reboot I got a kernel panic - unable to find root file system (or words to that effect).

The kernel I was trying to boot from was a hand-rolled one, rather than one that came with one of the updates.

The grub entry for that kernel included a "root=UUID=..." argument. This must have been changed during installation of one of the updates because I would have used "root=/dev/hda...". Replacing the "root=UUID..." with "root=/dev/hda8" enabled the machine to boot properly.

Revision history for this message
Robert Persson (ireneshusband) wrote :

My recent experience upgrading to Feisty suggests that this is part of a larger issue of installers getting confused when trying to deal with partitioning schemes and fstab files created by people who are not used to working with evms. I'll need to file a more comprehensive bug report about this when I get time.

Revision history for this message
TJ (tj) wrote :

I've found that often this is caused when a disk has multiple partitions, with 2 or more root partitions to support multiple distributions or versions.

For example, on a new laptop that comes pre-installed with Microsoft Windows Vista (UUIDs shortened for clarity):

sda1 = UUID=1 Recovery (7GB)
sda2 = UUID=2 Windows Vista (28GB)
sda3 = swap (2.5GB)
sda4 = >> Extended
 sda5 = UUID=5 /boot (512MB)
 sda6 = UUID=6/ (12GB - Feisty 32-bit)
 sda7 = UUID=7 / (8GB - Feisty 64-bit, Gutsy testing, different distribution, etc.)
 sda8 = UUID=8 /home (remainder)

If the 32-bit install in sda6 is performed first and later a different install is done to sda7, the later install will update sda5's /grub/menu.lst so kopt = UUID=7:

# kopt=root=UUID=7 ro

From then on, any kernel updates or other process that runs /usr/sbin/update-grub will set the kernel options root to the UUID of sda7:

title Ubuntu, kernel 2.6.20-16-generic
root (hd0,4)
kernel /vmlinuz-2.6.20-16-generic root=UUID=7 ro vga=791 quiet splash
initrd /initrd.img-2.6.20-16-generic
quiet
savedefault

The workaround is to manually edit /boot/grub/menu.lst and set kopt to the currently-running root UUID prior to doing updates.

Longer term, /usr/sbin/update-grub should take the current menu entries in preference to kopt *especially* for the running kernel - it couldn't have started if the options were incorrect, assuming no manual over-ride.

Revision history for this message
TJ (tj) wrote :

Assigning to correct package

Revision history for this message
TJ (tj) wrote :

This is almost, but not quite, a duplicate of bug #62195

Revision history for this message
Oleksij Rempel (olerem) wrote :

This is not bug but default option of update-grub. It is not normal to make use of one grub with two different update-grub from different roots. Instead you should edit /etc/kernel-img.conf to disable post[install/remove] update-grub,

Revision history for this message
Oleksij Rempel (olerem) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? If so, please reopen the bug. Thanks in advance.

Changed in grub:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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