Bug#707831: Broken UUID detection code makes another system unbootable

[Yann Dirson]

retitle 707831 Broken UUID detection code makes LVM systems unbootable after adding a new PV
severity 707831 critical
thanks

I also got bitten by this issue, like others as seen in #612402.
Since it makes (at least some) LVM systems unbootable, it surely
deserves a higher severity.

Now what happens ?  As Daniel said, grub-probe is failing.  More
specifically:

# /usr/sbin/grub-probe --device /dev/mapper/home-root --target=abstraction
/usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map.


So what does that message mean, ie. what does this "pv1" comes from ?
A bit of googling shows that the problem is linked to me having added
a PV to the machine.  The previous reboot was certainly the one during
which I have plugged the drive, and the machine had had no need to
reboot since its inclusion as PV into my VG.

So well, does moving away the old map and running grub-mkdevicemap fix
the problem ?  Not really, since I now see many dozens of "physical
volume pv0 not found" lines, where I used to have a single complaint
about "pv1".  What happened ?

If I look at the generated grub.cfg now, the linux commandline has
changed back to using the correct /dev/mapper/ path, but the UUID used
for "search --set=root" is now that of my /usr partition instead of
that of the (non-LVM) /boot.  Is this *only* used to load the
background image and font from /usr ?


In short:

* grub-probe issues completely unhelpful messages about PVs, where it
  could surely give their Linux names, and give a hint that *checking*
  the device map is not going to be sufficient, and that grub-mkdevicemap
  may come handy
* I surely missed something, or the use grub-mkdevicemap should not have
  generated a situation that just looks more messy
* As the original report says, such problems should surely not propagate to
  grub.cfg