Comment 7 for bug 551790

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...