Package: grub-common Version: 2.02~beta3-1 distro: stretch, 64bit
After update to 2.02~beta3-1 my system failed to boot with repeated blkid usage screens (blkid -t needs NAME=value pair) with any kernel. Turns out in initramfs-tools a function calls blkid -t $(DEV) to get the details of the root partition, but this throws an error, and finally gives up and falls back to a restricted initramfs-shell. Turns out, in environment I had: ROOT='UUID=' - feeding this to blkid provokes the error. But why was this so?
Turns out, in /boot/grub/grub.cfg all linux command lines had a "root=UUID=" - manally inserting the blkid of the root partition enabled a successful boot again.
Running update-grub, the blkids where missing again from grub.cfg. In grub-mkconfig I saw the UUID is provided by grub-probe, and entering all grub-probe calls by hand I found out it throws an error (on all partitions tested):
grub-probe --device /dev/sdb4 --target=fs_uuid 2 grub-probe: error: cannot find a GRUB drive for /dev/sdb4. Check your device.map.
and this produces the empty UUID for the root partition. My device.map didn't change, and every other partition (instead of /dev/sdb4) gives exactly the same error.
As grub-probe from 2.02 beta 2 did work, the recent update has introduced a severe bug.
Please fix! As a workaround I have a sed script that enters the UUID manually in case of kernel updates.
Heinz Repp
