Bug#707831: UUID detection code broken, wrongly uses UUID
This bug affects wheezy as well. I just had trouble booting a wheezy system after adding a second Physical Volume to my LVM setup. The workaround is setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub That will make boot again as it will use the root=/dev/mapper/nameofrootlv for the kernel cmdline in /boot/grub/grub.cfg I'm still getting those errors when doing an update-grub: physical volume pv0 not found (many of them) Not using the workaround in advance will kill remote servers, if you don't have access to a KVM console, spice or anything to fix the kernel cmdline in grub's boot menu manually, though. The machine affected is a KVM/quemu VM instance. That machine is using virtio disks, thus I'm having /dev/vda, /dev/vdb and so on. I've noticed that udev does not generate devices nodes for virtio disks in /dev/disk/by-id nor /dev/disk/by-uuid . Perhaps this is why grub is having trouble finding those disks. Additionally, this might be a corner case when one is using a complete unpartitioned disk as LVM Physical Volume, as the second PV I've added to the system is an unpartitioned virtio disk. Strangely enough, on another KVM/qemu VM running unstable (acutally running on the same host as the wheezy VM), but having a similar virtio disk setup, everything is fine. I'm seeing the virtio disk nodes in /dev/disk/by-id and grub is not complaining about not having found PVs, either. I'd likt to ask to re-open this bug, as this still affects wheezy. I'd kindly request a fix backported to wheezy, as well. Thank you. Regards, Dominik Bódi signature.asc Description: OpenPGP digital signature
Bug#707831: UUID detection code broken, wrongly uses UUID
On Sat, May 11, 2013 at 05:28:34PM +0200, Daniel Pocock wrote: /etc/grub.d/10_linux wrongly adds root=UUID entries to grub.cfg if grub-probe fails Specifically, in one case I observed grub-probe had failed because a new disk was added (some months ago) and grub-mkdevicemap had not been run. Users typically see this error in that case: /usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map. The update-grub script should refuse to write out grub.cfg after such failures. Currently it appears to default to UUID= entries, and if root is on LVM, the system is then unbootable. I think most of this was fixed by this upstream commit, and thus is fixed in 2.00: 2012-03-28 Vladimir Serbinenko phco...@gmail.com * grub-core/disk/diskfilter.c (grub_diskfilter_memberlist): Degrade the error when some elements are missing into a warning. In other words, it's not that important that this PV is missing; in other cases it might in theory result in missing modules to access bits of the VG, but that's not actually going to be true in this case so it's fine for grub-probe to carry on anyway. The piece noting that we shouldn't carry on if GRUB is unable to determine the file system of / remains; after consideration I'm inclined to agree with it, and I've posted a patch for this upstream. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707831: UUID detection code broken, wrongly uses UUID
Package: grub-pc Version: 1.99-27+deb7u1 Severity: serious /etc/grub.d/10_linux wrongly adds root=UUID entries to grub.cfg if grub-probe fails Specifically, in one case I observed grub-probe had failed because a new disk was added (some months ago) and grub-mkdevicemap had not been run. Users typically see this error in that case: /usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map. The update-grub script should refuse to write out grub.cfg after such failures. Currently it appears to default to UUID= entries, and if root is on LVM, the system is then unbootable. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
