lucid update-grub wrong root=UUID=

Yeah, same problem with all Lucid versions up to Beta 1 now. I also have a separate /boot partition (ext2), karmic on /dev/sda5 and and lucid on /dev/sda8 . Whenever I update grub.cfg via some kernel update in Lucid, Lucids's UUID is written to all entries in grub.cfg which makes Karmic not bootable any more. I manually have to revert the changes. Seems to be similar to bug 392836 or bug 462961, but they're marked as fixed...

Still there in a fresh install of Beta 2.

i have a fresh install of 10.10 - with all updates, but i see exactly the same behaviour. other partitions with ubuntu (say 10.04) are correctly found, but the UUID for the root is set to the one grub-update is run for (or the one, the installation is made for). this makes it impossible to run with the previous installation.

any workaround? - any fix?

I, too, have a fresh install of 10.10 with all the updates... And I see the same behavior as well.

In my case, I have a /boot partition (/dev/sda3) and two RAID-1 partitions containing 10.04 (/dev/md8) and 10.10 (/dev/md9). It will boot as expected to 10.10 (which was installed after 10.04), but /boot/grub/grub.cfg lists the UUID for the root of 10.10 for all the entries, both 10.10 and 10.04, making it not possible to boot 10.04 (without manually editing the grub.cfg file).

This is a pain, obviously, because every update that rebuilds grub.cfg undoes my edits.

Bug 392836 reported this problem for Karmic, but it was not fixed (then). Bug 462961 re-reported it, and Martin Pitt apparently came up with a patched update-grub that fixed it -- that patch was added to 'proposed packages' (Comment #17), but it doesn't look like it ended up in subsequent builds/versions. (Or it regressed.)

Bug 508901 appears to be another case of this...

Just to add to my comment above in #4, I have checked partition UUIDs using 'blkid', 'mdadm --detail', and 'tune2fs' and everything is consistent and as it should be, except for what 'update-grub' generates.

More... After patching my 'grub.cfg' file, I was able to reboot into 10.04. I then ran 'update-grub' within 10.04 to see what it would generate. Lucid has the same problem as Maverick: With a single, common '/boot' partition, it applies the UUID for the Lucid partition to Lucid and Maverick roots.

I have noted that in the '00_header' section of the generated 'grub.cfg' file, it also lists the UUID of the '/boot' partition (correctly, as it does for each OS entry), as well as the UUID of the OS that was booted at the time the 'update-grub' command was issued (10.04 or 10.10 in my two test cases).

Further, it lists the kernels in numerical sequence, regardless of which OS generates the 'grub.cfg' file -- likely because these are all contained in the '/boot' directory. But it appears to apply the *one* UUID listed in the '00_header' section to *all* the Linux boot lines, regardless of which partition they're actually located on.

Here's what's interesting: Martin Pitt's patch, '969_os_prober_separate_boot' as described in Bug 462961 implies that the problem is in the '30_os-prober' section of building 'grub.cfg' -- but it's not... The problem arises while it's building the '10_linux' section, as it finds the kernels for all the Linux OSes in the one common '/boot' partition -- and makes the mistake of using the one UUID for all of them, too.

Normally what happens when you install two *independent* versions of Ubuntu on a system is that the first one is detected and listed in the '10_linux' section, and the other one isn't found and listed until the '30_os-prober' section runs. Notice that in these cases, the other Ubuntu OSes are listed *after* the '20_memtest86+' section.

But in the case of the problem I've described here and in comment #4, all Linux OSes are listed together first, before the '20_memtest86+' section, in the section generated by '10_linux'. So the problem likely lies there. This section is failing to determine the actual partitions that hold the root filesystems for the kernels found in the common '/boot' directory; it finds the first and appears to presume that it applies to all the kernels listed.

That's NOT the case in general, however. Potentially, each kernel in '/boot' *could* be associated with a different root partition. But what is commonly done, of course, is that the *set of kernels* for each Ubuntu distro use a common root partition. And, of course, a multiboot system with two or more root filesystems can put all its kernels into one common boot directory. 'update-grub' needs to take this into account...

I suspect this bug (or one very like it) is what just bit me on the upgrade from Kubuntu 10.10 64-bit to 11.04. It may not be exactly the same though, since in my case the upgrade didn't get confused by multiple valid installs - it just plain picked the wrong drive.

Post-install, the reboot brought up a grub prompt with an "ls /" that listed the contents of an old hard drive I had in the machine with assorted remnants of a previous install's "/usr" directory. For some reason, the upgrade process had decided to nominate /dev/sdc1 as the root of the machine, even though that directory contained no /boot and no /etc. The *actual* root directory (on /dev/sda1) was ignored.

I'm currently still tinkering to get back to a bootable system - I suspect missed some references to the incorrect root partition in my first attempt.

After booting into the system manually from the GRUB prompt, setting "GRUB_DISABLE_OS_PROBER=true" in /etc/defaults/grub and rerunning update-grub was enough to get the system booting again on its own.

It turned out the "root" partition OS prober was choosing wasn't an old one at all, but the "/usr" partition for the current installation (I'd missed that initially, because I set up this system a couple of years ago and had forgotten how the partitions were mapped).

I believe I have a similar related issue. I first experienced this issue in 10.10 (but that was the first version where I my current mount configuration of mounts), and it persists in 11.04.

My setup: Ubuntu's root (/) is on one partition, and Ubuntu has a separate /boot partition. On the same PC, I have openSUSE (11.4, but I do not think that matters here) installed with its root on a third partition, and its separate /boot on a fourth partition. Under Ubuntu, openSUSE's root is mounted under /opensuse, and openSUSE's /boot is mounted under /opensuse/boot. These mounts occur automatically when Ubuntu starts. Ubuntu's grub2 is the boot manager that the PC boots into. I have very similar dual-boot and mount configurations on two other PCs, and both experience the same issue.

The issue: Whenever Ubuntu updates its grub.cfg through any installation or update, I can no longer boot using the entries in it for openSUSE. (Booting Ubuntu works fine.)

Workarounds: I use two individual workarounds. A) I've manually added a menuentry to /etc/grub.d/40_custom which chainloads directly into openSUSE's grub, which is written to its /boot partition's boot record. B) From an Ubuntu terminal window as root, manually unmount /opensuse/boot, then rerun update-grub. This produces a grub.cfg with working entries for openSUSE.

Discussion: The differences between the good and bad grub.cfg files are confined to the openSUSE entries. Under Ubuntu, when /opensuse/boot is mounted, these entries in the generated grub.cfg file have "set root..." and "search..." lines pointing to openSUSE's root partition. When /opensuse/boot is not mounted, these entries in the generated grub.cfg file have "set root..." and "search..." lines pointing to openSUSE's /boot partition.

Attached is my mount configuration under Ubuntu and the diff output comparing the bad and good grub.cfg files.

the same still happens in natty:
with different ubuntu installations on various partitions
the root=UUID=... parameter contains the same uuid in all entries referring to any of these installations

same issue in 12.04 precise

Stas, you only showed the entries for one system ( sda3 ). Please show the entries for the duplicate system as well.

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]

This is fixed by applying this:
https://gist.github.com/pepa65/85d5fcd1e12bc6028501c746258ac8cf