grub not adding correct uuid to grub.cfg

Reported by Kevin C on 2009-06-27
This bug affects 8 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Nominated for Karmic by Lucio M Nicolosi

Bug Description

Binary package hint: grub

I have a dual boot Kubuntu - Jaunty and Karmic

Jaunty runs nicely without any problems

When I installed Karmic the first time, during installation using alternate CD, it refused to write grub to mbr, saying that it couldn't. I tried with both options given, grub2 and grub. I also tried selecting a partition manually and putting (hd0) which is the mbr. After 12 attempts, I exited without installing grub, it was the only way out of the installation. On reboot, the grub2 menu appeared with only the Karmic option.

I used the option to manually boot from Jaunty. With the /boot/grub/grub.cfg suggesting not to edit, I used my Jaunty install disk on rescue mode to run grub-install which correctly wrote a mbr and I could boot either Jaunty or Karmic.

This week grub has been updated twice in Karmic and both times, installing the updates has led to Karmic writing grub to my mbr and not allowing me to boot Jaunty. At least now it recognizes Jaunty and adds a line the menu.cfg but it has the wrong UUID. Selecting Jaunty at boot gives the error message 'Kernel not found'
obviously, because it does not have the UUID of the root partition

I have Jaunty root /dev/sda5 and Jaunty /boot is /dev/sda9 - very simple using this

Karmic can find the Jaunty kernel or the link to it but it can't boot it. It should be able to find the right partition and boot it from the menu list.

Steve Langasek (vorlon) on 2009-06-27
affects: grub (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
importance: Undecided → High
Download full text (3.9 KiB)

Steve Langasek wrote:
> ** Package changed: grub (Ubuntu) => grub2 (Ubuntu)
> ** Changed in: grub2 (Ubuntu)
> Importance: Undecided => High
Hi, would it help to see the menu.cfg from Kubuntu Karmic using grub2
and the menu.lst from Kubuntu Jaunty using grub?
I highlighted the problem in red and showed the correct UUID in green.

First, menu.cfg from Karmic

# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
set root=(hd0,1)
search --no-floppy --fs-uuid --set 5c33e75f-d1e0-4dfd-b1a6-f1ac98c5791f
if loadfont /usr/share/grub/ascii.pf2 ; then
  set gfxmode=640x480
  insmod gfxterm
  insmod vbe
  if terminal_output gfxterm ; then true ; else
    # For backward compatibility with versions of terminal.mod that don't
    # understand terminal_output
    terminal gfxterm
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.30-8-generic" {
    set root=(hd0,1)
    search --no-floppy --fs-uuid --set 5c33e75f-d1e0-4dfd-b1a6-f1ac98c5791f
    linux /boot/vmlinuz-2.6.30-8-generic
root=UUID=5c33e75f-d1e0-4dfd-b1a6-f1ac98c5791f ro quiet splash
    initrd /boot/initrd.img-2.6.30-8-generic
menuentry "Ubuntu, Linux 2.6.30-8-generic (recovery mode)" {
    set root=(hd0,1)
    search --no-floppy --fs-uuid --set 5c33e75f-d1e0-4dfd-b1a6-f1ac98c5791f
    linux /boot/vmlinuz-2.6.30-8-generic
root=UUID=5c33e75f-d1e0-4dfd-b1a6-f1ac98c5791f ro single
    initrd /boot/initrd.img-2.6.30-8-generic
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory test (memtest86+)" {
    linux /boot/memtest86+.bin
menuentry "Memory test (memtest86+, serial console 115200)" {
    linux /boot/memtest86+.bin console=ttyS0,115200n8
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Kubuntu 9.04, kernel 2.6.28-11-generic (on /dev/sda5)" {
    set root=(hd0,5)
    search --no-floppy --fs-uuid --set 89c07ebd-cc8e-4d65-be8d-e4db7fbfef06
    linux /boot/vmlinuz-2.6.28-11-generic
root=UUID=89c07ebd-cc8e-4d65-be8d-e4db7fbfef06 ro quiet splash
    initrd /boot/initrd.img-2.6.28-11-generic
menuentry "Kubuntu 9.04, kernel 2.6.28-11-generic (recovery mode) (on
/dev/sda5)" {
    set root=(hd0,5)
    search --no-floppy --fs-uuid --set 89c07ebd-cc8e-4d65-be8d-e4db7fbfef06
    linux /boot/vmlinuz-2.6.28-11-generic
root=UUID=89c07ebd-cc8e-4d65-be8d-e4db7fbfef06 ro single
    initrd /boot/initrd.img-2.6.28-11-generic
menuentry "Kubuntu 9.04, memtest86+ (on /dev/sda5)" {
    set root=(hd0,5)
    search --no-floppy --fs-uuid --set 89c07ebd-cc8e-4d65-be8d-e4db7fbfef06
    linux /boot/memtest86+.bin
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###

Second, menu.lst from Kubuntu Jaunty

title ...


der_vegi (m-may) wrote :

Same here, Karmic Alpha 6. I didn't have any problems/errors intalling Karmic, but in the grub.cfg the uuid for Jaunty was set to Karmic's uuid. When I updated Karmic today, the manually corrected entry was overwritten with the wrong uuid again.

Lucio M Nicolosi (lmnicolosi) wrote :

Problems here with double boot configuration.
Running Jaunty perfectly (/root at secondary hd0,8). Installed Karmic Beta (sept/29) at primary partition (hd0,0). Could not boot after install. Still unable to find out why, (perhaps it did not like my grub[1] at [hd0,8]?). Reset Grub to previous conditions and Jaunty booted OK. Installed Grub2 in Jaunty, just in case. Menu.lst was set to default (Karmic) parameters (hd0,0) and corresponding (wrong) UUID. Of course the system didn't boot. Restored original menu.lst parameters from (good grace, there was a) backup and managed to make Jaunty work again. No way I can further test Karmic with double boot. I'm currently trying to reinstall original Grub.

der_vegi (m-may) wrote :

You have to change the UUID in 'root=UUID=89c07ebd-cc8e-4d65-be8d-e4db7fbfef06 ro quiet splash' to match your Jaunty's UUID. But every time, your kernel in Karmic gets updated and the grub.cfg is updated as well, this setting gets lost and is overwritten with Karmic's UUID.

I am running a system with 1 IDE drive (Intrepid), 1 SATA (Windows XP), 1 SATA (Jaunty) and 1 USB external drive which I am using to test Karmic. The Windows drive has the Windows MBR and all others have GRUB with the USB drive having GRUB2. The Jaunty drive also has a separate Boot partition. After Karmic installation all systems would boot from GRUB2 except for my current production system, Jaunty. My initial workaround was just to set the BIOS to boot from this drive first. After experimentation I have found that I must set the "search" specification in the GRUB2 menu to the UUID of the Boot partition and remove the "/boot" from each of the "linux" and "initrd" lines to get Jaunty to boot.

der_vegi (m-may) on 2009-10-08
Changed in grub2 (Ubuntu):
status: New → Confirmed
Tuomas Heino (iheino+ub) wrote :

Bug #445367 seems like a duplicate of this. As described there, /etc/grub.d/30_os-prober ignores boot partition reported by os-prober.

/usr/lib/linux-boot-probes/mounted/40grub and /usr/lib/linux-boot-probes/mounted/40grub2 are the files prepending the "/boot" to linux kernel/initrd lines.

Tuomas Heino (iheino+ub) wrote :

As a temporary workaround (that only works with setups similar to mine, since the test for separate /boot is simply wrong) I changed 30_os-prober as follows:

--- 30_os-prober.orig 2009-11-01 13:26:40.787934691 +0200
+++ 30_os-prober 2009-11-01 13:27:21.897932968 +0200
@@ -128,6 +128,11 @@
         LINITRD="`echo ${LINUX} | cut -d ':' -f 5`"
         LPARAMS="`echo ${LINUX} | cut -d ':' -f 6- | tr '^' ' '`"

+ if [ "${LBOOT%%dev/md*}" = "/" ] ; then
+ LKERNEL="${LKERNEL#/boot}"
+ LINITRD="${LKERNEL#/boot}"
+ fi
         if [ -z "${LLABEL}" ] ; then
@@ -136,7 +141,7 @@
 menuentry "${LLABEL} (on ${DEVICE})" {
        save_default_entry | sed -e "s/^/\t/"
- prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"
+ prepare_grub_to_access_device ${LBOOT} | sed -e "s/^/\t/"
        cat << EOF
        linux ${LKERNEL} ${LPARAMS}

Tuomas Heino (iheino+ub) wrote :

Or maybe that bug I mentioned above is separate one. But both seem to be symptoms of missing/broken support for separate /boot -partitions for kernels found by os-prober.

Also my "workaround" above doesn't work as-is, so please ignore it. Since bug db isn't a discussion forum, guess I'll shut up until I have something that actually works, and for others besides me as well.

der_vegi (m-may) wrote :

Duplicate of bug 462961?

Christoph (christop) wrote :

I think so either, and bug 462961 has been fixed some hours ago.

der_vegi (m-may) wrote :

I don't think, this bug is fixed. I now have a dual-boot Karmic and Lucid (Beta 1) with a separate /boot partition. Whenever I upgrade my kernel in Lucid grub.cfg is updated and the wrong uuid is set in Karmic's entry of 'root=UUID=': It is always changed to the uuid of Lucid. To be able to boot into Karmic, I have to manually revert this change.

Barry Coleman (barry-bcoleman) wrote :

I have set up an extra instance of Karmic on a separate partition, for testing an upgrade. I am using grub2.

After running update-grub this line -

linux /boot/vmlinuz-2.6.31-21-generic-pae root=UUID=373d9796-9311-4975-94c9-78e78bc5e7a9 ro quiet splash

- is the same in the grub.cfg entries for both partitions. It should be -

linux /boot/vmlinuz-2.6.31-21-generic-pae root=UUID=66e71417-90bd-4d38-9828-5768765078b4 ro quiet splash

- where the extra partition UUID is different.

I have edited grub.cfg manually to match the above and all seems OK.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers