Just to confirm: my situation is really the same that has been described in this bugreport. When dropped into the initramfs shell I can verify that ROOT=/dev/disk/by-uuid/xxxx, and furthermore, I also have resume=UUID=xxxx trying to reference my swap partition.
If I just set them to the /dev/mapper/vg-lv paths expected by local-top/lvm2 and rerun the script, the LVs are properly activated. Now: * I did not recall changing anything in that field, so whatever change in whatever package, that is responsible for this seems to warrant the "critical" severity this bug used to have. It may be more tricky than just "grub uses UUID by default and LVM does not want that", but we have to track this problem. * both ROOT and resume seem to be set by /usr/share/initramfs-tools/init which belongs to package initramfs. Although it was updated from 0.112 to 0.113 since the last succesful boot, there is change in that area, and what it does to set ROOT from the kernel commandline seems legit. I can't say the same for "resume", which apparently should go through the same processing but fails to. * that switches the focus to whoever sets root=UUID= on the commandline, and /etc/grub.d/10_linux seems to be where the thing originates. There we have a test looking at « uses_abstraction "${GRUB_DEVICE}" lvm » that should just avoid the issue completely, and obviously fails. Grub had been updated one month before from 1.99-27 to 1.99-27+deb7u1 - this change includes something labelled "TPU upload to lose dependency blockage on LVM." and in fact Daniel Pocock already reported Bug#707831 with a short and clear statement, just a pity this was not mentionned here... I'll raise the severity of Bug#707831. You may want to keep this one open so users are aware of the problem, or just reasign/merge with that other bug... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org