[Bug 1046826] [NEW] cryptroot fails silently fails if LVM fails when /run/lock is non existent

[Muelli]

Public bug reported:

I just updated my machine from 11.10 to 12.04. The update itself failed,
because update-manager didn't prevent the laptop from going into
suspend. Anyway, I rebooted, chrooted and did dpkg --configure -a and
apt-get dist-upgrade. All packages were fine. However, the machine
wouldn't boot, because it couldn't find the crypto volume. Turns out,
that conf.d/cryptroot was missing. That was because of a *silent*
failure from the cryptroot script from initramfs-tools.

The hook ran LVM which in turn expected /var/run/lock to be present. It
was indeed present, but a symlink to /run/lock. But that did not exist.
So LVM failed and so /etc/crypttab was not copied in the initramfs.

I pulled my hair out for 8 hours to find that out. As a note to that
poor person being in trouble next time: When trying to fix and
luksOpening the crypto volume, name it exactly as it's written in
/etc/crypttab. Because the cryptroot hook from initramfs-tools expects
the LUKS device to be named exactly as /etc/crypttab indicates. That
took with a couple of hours to figure out.

Anyway, I expected update-initramfs to fail loudly if it couldn't set up
the initramfs properly to decrypt my container.

** Affects: initramfs-tools (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1046826

Title:
  cryptroot fails silently fails if LVM fails when /run/lock is non
  existent

Status in “initramfs-tools” package in Ubuntu:
  New

Bug description:
  I just updated my machine from 11.10 to 12.04. The update itself
  failed, because update-manager didn't prevent the laptop from going
  into suspend. Anyway, I rebooted, chrooted and did dpkg --configure -a
  and apt-get dist-upgrade. All packages were fine. However, the machine
  wouldn't boot, because it couldn't find the crypto volume. Turns out,
  that conf.d/cryptroot was missing. That was because of a *silent*
  failure from the cryptroot script from initramfs-tools.

  The hook ran LVM which in turn expected /var/run/lock to be present.
  It was indeed present, but a symlink to /run/lock. But that did not
  exist. So LVM failed and so /etc/crypttab was not copied in the
  initramfs.

  I pulled my hair out for 8 hours to find that out. As a note to that
  poor person being in trouble next time: When trying to fix and
  luksOpening the crypto volume, name it exactly as it's written in
  /etc/crypttab. Because the cryptroot hook from initramfs-tools expects
  the LUKS device to be named exactly as /etc/crypttab indicates. That
  took with a couple of hours to figure out.

  Anyway, I expected update-initramfs to fail loudly if it couldn't set
  up the initramfs properly to decrypt my container.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1046826/+subscriptions