os-prober entries do not use correct /boot device

[Marien Zwart]

Binary package hint: grub2

I'm encountering this on a system using lvm with a separate /boot partition outside of lvm used by jaunty but no separate /boot for karmic, but I think it will affect every system with grub 1 on a separate /boot partition, not just those also using lvm.

"sudo os-prober" gives me:

/dev/sda1:Microsoft Windows XP Home Edition:Windows:chain
/dev/mapper/main-jaunty_chroot:Ubuntu 9.04 (9.04):Ubuntu:linux
/dev/mapper/main-root:Ubuntu 9.04 (9.04):Ubuntu1:linux

which as far as I know is correct: main/jaunty_chroot is an sbuild-lvm chroot, main/root is a regular jaunty install.

"sudo linux-boot-prober /dev/mapper/main-root" gives me:

/dev/mapper/main-root:/dev/sda2:Ubuntu 9.04, kernel 2.6.28-15-generic:/boot/vmlinuz-2.6.28-15-generic:/boot/initrd.img-2.6.28-15-generic:root=/dev/mapper/main-root ro quiet splash
/dev/mapper/main-root:/dev/sda2:Ubuntu 9.04, kernel 2.6.28-15-generic (recovery mode):/boot/vmlinuz-2.6.28-15-generic:/boot/initrd.img-2.6.28-15-generic:root=/dev/mapper/main-root ro single
/dev/mapper/main-root:/dev/sda2:Ubuntu 9.04, kernel 2.6.28-3-rt:/boot/vmlinuz-2.6.28-3-rt:/boot/initrd.img-2.6.28-3-rt:root=/dev/mapper/main-root ro quiet splash
/dev/mapper/main-root:/dev/sda2:Ubuntu 9.04, kernel 2.6.28-3-rt (recovery mode):/boot/vmlinuz-2.6.28-3-rt:/boot/initrd.img-2.6.28-3-rt:root=/dev/mapper/main-root ro single
/dev/mapper/main-root:/dev/sda2:Ubuntu 9.04, memtest86+:/boot/memtest86+.bin::

which again I think is correct. Notice /dev/sda2 is my separate /boot partition.

However /etc/grub/30_os-prober completely ignores the /boot partition information supplied by linux-os-prober ($LBOOT in the script) and generates a grub.cfg that looks for the kernel on the root device, which does not work. That is: it generates entries like:

menuentry "Ubuntu 9.04, kernel 2.6.28-15-generic (on /dev/mapper/main-root)" {
 insmod lvm
 insmod ext2
 set root=(main-root)
 search --no-floppy --fs-uuid --set 096600f3-ffce-445c-8cd7-588461a4894e
 linux /boot/vmlinuz-2.6.28-15-generic root=/dev/mapper/main-root ro quiet splash
 initrd /boot/initrd.img-2.6.28-15-generic
}

while a manually added entry that works is:

menuentry "Ubuntu 9.04, kernel 2.6.28-15-generic (on /dev/mapper/main-root)" {
 insmod lvm
 insmod ext2
 set root=(hd0,2)
 linux /vmlinuz-2.6.28-15-generic root=/dev/mapper/main-root ro quiet splash
 initrd /initrd.img-2.6.28-15-generic
}

Notice that just changing the prepare_grub_to_access_device call to use ${LBOOT} instead of ${DEVICE} does not quite suffice: the leading /boot component needs to be removed from the initrd and vmlinuz paths too. Since it looks like /usr/lib/linux-boot-probes/mounted/40grub actually prepends /boot if there's a separate /boot partition it might make sense to have linux-boot-probe pass the path grub uses unchanged (instead of having another check for a separate /boot partition to chop off the path component 40grub added).

ProblemType: Bug
Architecture: i386
Date: Wed Oct 7 13:24:42 2009
DistroRelease: Ubuntu 9.10
Package: grub2 (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.39-generic
SourcePackage: grub2
Uname: Linux 2.6.31-12-generic i686

[Ralph (ralph-puncher-deactivatedaccount)]

I am having the same problem but without LVM. I am using two SATA drives, the first with Windows and the second with Jaunty with a separate /boot partition and one external USB disk on which Karmic is installed with no separate /boot partition. In Karmic I have created a 06_custom level script in /etc/grub.d in which I have changed the UUID on the search command line to that of the /boot partition for Jaunty and removed "/boot" from the "Linux" and "Initrd" lines. Without removing the execute bit from the 30 level script I just ignore the generated menu entries for Jaunty which follow the Karmic entries. This also gives me the opportunity to do a quick test of any changes to Grub2 by trying the 30 level menu entries to see if they still fail.

[Tuomas Heino (iheino+ub)]

Seems like a duplicate of bug #392836 - wrong UUID reported there may be a consequence of using ${DEVICE} instead of ${LBOOT} as described by reporter.

[Marien Zwart (marienz)]

Looks like this got fixed as bug #462961 so marking this as a duplicate of that. If someone can teach me what caused that bug report to be picked up and fixed instead of this one I would appreciate it, so I can file better bug reports in the future. Description too long? Important keywords missing from the summary?

[Steve Langasek (vorlon)]

The other bug report was filed by the desktop team technical lead. I'm afraid it's unavoidable that bug reports from the developers are going to get attention much more quickly, since they can escalate such bugs directly without the need of a bug triager to process the bug first.

Since becoming an Ubuntu developer is probably not the sort of solution you had in mind, here are some other ways to get more attention on your bugs:

- Participate in ISO testing before the milestones - https://wiki.ubuntu.com/Testing/ISO - and include links to your bugs in your ISO test reports.
- If you think a bug has gone unnoticed and should be a higher priority for the release, try talking to the developers directly on IRC (#ubuntu-devel on irc.freenode.net).
- Yes, a dfferent bug summary might also have helped. E.g., discussing the high-level consequence of the bug, as was done in bug #462961.

Hope that helps - it obviously would have been better if we could have fixed this bug weeks earlier when you first noticed it!