Bug#612402: Info received (Similar issue, system suddenly needs help to boot up)

[Yann Dirson]

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...