Bug#618862: systemd: ignores keyscript in crypttab

[An Inbox]

     Hi,

     I have the same issue as Evgeni above in a similar set-up and can 
provide a bit more information. It seems some alignment is needed 
between packages cryptsetup, initramfs-tools and systemd.

     In the cryptsetup documentation, there is a README on how to 
configure an encrypted root disk where the decryption key is read from 
another media file, see /usr/share/doc/cryptsetup/README.initramfs.gz 
section 10.
     The recommended approach is to use the passdev "script" (it's 
actually a binary, but makes use of the "keyscript" feature discussed 
here). This requires putting an entry in /etc/crypttab.
     As a good documentation reading user ;) this is what I did, and got 
a set-up like Evgeni. This used to work fine before I switched to 
systemd (on Jessie too), and now I have this same delay at boot.

     What happens is that the keyscript/passdev is correctly handled by 
the initramfs tools. They pick up the /etc/crypttab entry, puts 
everything required in the initramfs. And the encrypted root is 
successfully mounted and switched to by the initramfs.

     Then systemd is started from the root filesystem. Its cryptsetup 
generator processes the /etc/crypttab entries. It also processes the 
root entry, with its "keyscript" parameter, and generates under /run a 
service unit for it. Then systemd tries opening and mounting the LUKS 
device that is already opened and mounted, and get stuck until it times 
out. Then the boot proceeds successfully.

     It seems to me that systemd has the assumption that an encrypted 
root device is NOT described in /etc/crypttab. I may be wrong on this 
but when I look at documentation from Arch, which has migrated to 
systemd, the encrypted root is handled through kernel parameters handled 
in the initramfs and not through /etc/cryptab. See for example:
https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Boot_loader

     This issue can be worked-arounded by using the (different from 
Arch) kernel parameters "cryptopts" in Debian too, and removing the root 
entry from /etc/crypttab. This is documented in README.initramfs.gz 
section 7, but the doc actually recommends against this and says it's 
better to use crypttab instead.

     Another work-around would be for the generated systemd 
configuration to be robust against an already opened/mounted device, in 
case the system or user does things in the initramfs already. Or to 
ignore the root fs in /etc/crypttab, as on principle it is already there 
when systemd is started from it.
     As a user I personally prefer having all my crypto partitions in 
one place under /etc/crypttab, rather than having to special case the 
root fs using kernel parameters. The root fs is a special case 
technically, but I'd rather have the infrastructure deal with this. I'm 
sure there will be othe opinions, in the end it's not a big deal as long 
as what's required is documented consistently across packages and 
existing configurations are migrated properly (if need be).

     In any case, the initial bug does not apply to me: the keyscript 
parameter is for the initramfs and cryptsetup, and they handle it just 
fine. If Mourad still follows the thread, could you try on a recent 
Jessie or Sid release? (the initial bug is old now). The fix could be 
just a documentation alignment, and/or having systemd ignoring the root 
fs entry in crypttab.

     All this under Jessie, with:
     - systemd 208-6
     - initramfs-tools 0.115
     - cryptsetup 2:1.6.4-4

     And by the way, thanks to all for the good work. The transition to 
systemd is rather smooth considering how big a change it is, and I like 
the result so far.

     Thanks!