Hi,

As you probably know, os-prober is used by grub-mkconfig to generate grub.cfg
entries for other operating systems. Today I ran update-grub in order for it to
pick up the Fedora 14 Kernel I had installed today. The command line it
generated looked like this:
linux /boot/vmlinuz-2.6.35.6-45.fc14.x86_64 root=/dev/sdb3
But with the Fedora kernel the relevant device isn't called /dev/sdb3 but
/dev/sda3, so this command line doesn't work, and I guess UUIDs should be used
instead. The following change to /usr/share/os-prober/common.sh did the trick
for me: replace

mapdevfs () {
    readlink -f "$1"
}

with

mapdevfs() {
    echo "/dev/disk/by-uuid/$(blkid -o value -s UUID "$1")"
}

Perhaps this can be applied upstream?

I don't think this is generally safe.  It relies on the kernel in
question coming with an initramfs with suitable UUID support; os-prober
can't reliably know this.

os-prober presumably picked this kernel up from some other boot loader's
configuration file - perhaps /boot/grub/grub.conf in your Fedora system.
Could you please attach that file?

Thanks,

Hi Colin,

thank you for your response.
Well, on the other hand, the current assumption that the device files are
named the same on debian and fedora doesn't seem to be safe either.
Perhaps it would be possible to introduce a blacklist for distros that
don't support UUIDs? I don't think there are that many.
I didn't install the boot loader when I installed Fedora, so this isn't the
case.

Regards
Matthias

Dear Maintainer,
Issuing update-grub command sometimes creates menu entries
for coexisting linux installations with
root=/dev/sdaX parameter at "linux" line.

My CentOS likes to name my drive at random "sda" or "sdb"
so entry mentioned above likes to cause CentOS boot to fail.
-------

I fixed my problem locally by applying following patch to:
/usr/lib/linux-boot-probes/mounted/90fallback.

#v+
--- linux-boot-probes/mounted/common/90fallback	2011-09-16 14:29:55.000000000 +0200
+++ /usr/lib/linux-boot-probes/mounted/90fallback	2011-12-13 18:55:53.000000000 +0100
@@ -2,6 +2,10 @@
 # Fallback in case nothing else works. Look for vmlinu[xz] file in root and
 # /boot, see if there is a matching initrd, and wing it.
 . /usr/share/os-prober/common.sh
+if [ -f /etc/default/grub ] ; then
+	. /etc/default/grub
+fi
+
 set -e

 partition="$1"
@@ -11,6 +15,10 @@

 mappedpartition=$(mapdevfs "$partition" 2>/dev/null) || mappedpartition="$partition"

+if [ "x${GRUB_OSPROBER_FALLBACK_USE_UUID}" = "xtrue" ] ; then
+	mappedpartition=$(blkid -s UUID -o export ${partition})
+fi
+
 exitcode=1
 for kernpat in /vmlinuz /vmlinux /boot/vmlinuz /boot/vmlinux "/boot/vmlinuz*" \
 	        "/boot/vmlinux*" "/vmlinuz*" "/vmlinux*" "/kernel-*" "/boot/kernel-*"; do
#v-

and added:

#v+

# Uncomment to use UUID for root= option on kernel line
# for coexisting linux installations for last resort configuration attempt.
GRUB_OSPROBER_FALLBACK_USE_UUID=true

#v-

to /etc/default/grub.

After I rerun update-grub required entries were in place, i.e.
CentOS menu entry had root=UUID=xxxxx-xxxx-xxxxx-xxxxx parameter at "linux" line.

Old bug; per suggestion from this thread:
https://forums.debian.net/viewtopic.php?p=825776 I am adding:

I did a fresh install of Debian 12 which is my main daily driver desktop
environment. I installed a headless Debain 12 (from same installer .iso)
to a seperate partition but did not have it run update-grub on the install.

I then reboot to my main install, update-grub to pick up the new
install, reboot and try to boot to the headless install but the grub.cfg
uses /dev/sdX instead of the UUID, so it can't boot (because dev names
are different.)

I tried the patch suggested 2011-12-13 by Marcin but it seemed to
corrupt my grub.cfg (not surprising, given the age and that it was
perhaps for CentOS).

My hack solution was to change /etc/grub.d/30_os-prober line 248 to be:

|linux ${LKERNEL} root=UUID=${boot_device_id}|

...which I assume is a Bad Idea for some reason, but I don't know
anything about this stuff. Just wanted to report that this is still an
issue.