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!
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
