[pkg-cryptsetup-devel] Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

[Simon McVittie]

On Sat, 01 Nov 2014 at 11:50:40 +0100, Arnaud Installe wrote:
> After successfully unlocking and mounting root and swap devices, the system
> hangs a while, then drops to a rescue shell, with /usr, /var and /home not
> unlocked by cryptsetup. After manually running cryptsetup for the underlying
> devices, and exiting the rescue shell, boot proceeds normally.

I think this may be the same thing as <https://bugs.debian.org/767832>.
Am I right in saying that your system looks like this?

    /dev/sda (or whatever)
      \- /dev/sda1 (or whatever): /boot
      \- /dev/sda2 (or whatever): LVM PV for VG "boulez"
         \- boulez/root LV: encrypted, boulez-_root__crypt
            \- / (rootfs)
         \- boulez/swap LV: encrypted, boulez-_swap__crypt
            \- swap
         \- boulez/home LV: encrypted, boulez-_home__crypt
            \- /home
         \- boulez/usr LV: encrypted, boulez-_usr__crypt
            \- /usr
         \- boulez/var LV: encrypted, boulez-_var__crypt
            \- /var

With initramfs-tools < 0.117, the intended result for a system like this
is that the initramfs decrypts the root filesystem and swap, mounts
the root filesystem, and hands over to the "real system" (systemd as pid 1).
The "real system" is meant to decrypt and mount /home, /usr and /var.

With initramfs-tools >= 0.117, the intended result for a system like this
is that the initramfs also decrypts and mounts /usr. However, cryptsetup
does not currently decrypt /usr.

It should be unnecessary to decrypt /home or /var in the initramfs
in either case.

It would be great if you could try rebuilding the initramfs after
installing a version of cryptsetup with the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767832#22
applied. I believe that should fix your situation too, but
so far I have only tested LUKS on partitions, not LUKS on LVM.

    S