grub-mkconfig fails on a system where "/" can not be accessed by grub.
The is_path_readable_by_grub function only checks that the filesystem is
known to grub. In my case (lvm+raid) grub understands the filesystem, but
not device partition mappings. grub-mkconfig incorreclty tries to use files
(specifically unicode.pf2) under /usr, causing 00_header to fail when it calls
prepare_grub_to_access_device for this file.
Patch below fixes this by making is_path_readable_by_grub also probe the
partmap. grub-mkconfig then correctly falls back to the files in
/boot/grub.
diff -ur clean/util/grub-mkconfig_lib.in grub2/util/grub-mkconfig_lib.in
--- clean/util/grub-mkconfig_lib.in
+++ grub2/util/grub-mkconfig_lib.in
@@ -61,6 +61,11 @@ is_path_readable_by_grub ()
return 1
fi
+ # abort if file is in a partition we don't know about
+ if ${grub_probe} -t partmap $path > /dev/null 2>&1 ; then : ; else
+ return 1
+ fi
+
return 0
}
Further investigation shows that it's actually the use of GUID partition tables that cause confusion. grub-probe correctly identifies filesystem and LVM device, but fails to map partitions for the constituent devices. The lack of GUID partition table support is not directly relevant to this bug. I'm sure there are other partitioning schemes that grub does not understand. Paul
GPT is supported by GRUB. As long as it correctly has 0xee partition in its protective MBR.
GPT support (or lack of) is a tangential issue. The issue is that grub should gracefully cope with cases where it is unable to access some partitions. The probe function (is_path_readable_by_grub) fails to check for appropriate partmap support, causing higher level code to make incorrect decisions. Paul
Forgot to mention that I will gladly test any patches related to this issue, as I have a bunch of root-over-nfs-lennies that need to be upgraded. Motiejus Jakštys
I think this e-mail did not go through.
Package: grub-pc
Version: 1.98+20100804-14
Severity: normal
Tags: patch
Does not work with root over nfs as well. Was upgrading from lenny to
squeeze and update-grub failed:
aviastopas:/usr/sbin# update-grub2
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev
mounted?).
digging with bash -x...:
aviastopas:/usr/sbin# grub-probe --target=device /
grub-probe: error: cannot find a device for / (is /dev mounted?).
Quick hack working for me is here. Of course, it will break "normal"
systems:
aviastopas:/usr/sbin# diff grub-mkconfig.*
152c152
< GRUB_DEVICE="`${grub_probe} --target=device /`"
---
When I changed it, update-grub fully worked and this was the only issue
while upgrading to squeeze. Wheee :)
Does not work with root over nfs as well. Was upgrading from lenny to
squeeze and update-grub failed:
aviastopas:/usr/sbin# update-grub2
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev
mounted?).
digging with bash -x...:
aviastopas:/usr/sbin# grub-probe --target=device /
grub-probe: error: cannot find a device for / (is /dev mounted?).
Quick hack working for me is here. Of course, it will break "normal"
systems:
aviastopas:/usr/sbin# diff grub-mkconfig.*
152c152
< GRUB_DEVICE="`${grub_probe} --target=device /`"
---
When I changed it, update-grub fully worked and this was the only issue
while upgrading to squeeze. Wheee :)
This has nothing to do with Paul's bugreport. Instead it's a duplicate of 561855 <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561855>. And this would break any non-nfs, separate /boot user.
tag 561855 fixed-upstream thanks The thing is that GPT had nothing to do with it. In fact your problem was because device.map didn't contain all the devices needed to reconstruct mdraid/lvm. It's fixed upstream