Bug#618862: systemd: ignores keyscript in crypttab

[Marcello Barnaba]

> On Sat, 19 Mar 2011 03:40:25 +0100 Mourad De Clerck wrote:
> my root and swap partition are encrypted with cryptsetup; root uses a custom
> keyscript and swap uses the cryptsetup-provided "decrypt_derived" keyscript.
> systemd seems to be unable to work with keyscripts at all

I confirm the same problem albeit while using the passdev keyscript.

Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

Debian Jessie *supports* keyscripts, as long as faulty software is disabled.

~Marcello
--
~ v...@openssl.it
~ http://sindro.me/

[Rick Thomas]

Marcello,

Does this work for encrypted root as well? Or is it only for things like swap and /home that can wait until after switching out of initramdisk?
If it works for encrypted root, this is genuinely good news!


Thanks!
Rick

[Marcello Barnaba]

>> Workaround: add "luks=no" to the kernel command line to disable systemd's generator: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html

> Does this work for encrypted root as well? Or is it only for things like swap and /home that can wait until after switching out of initramdisk?
> If it works for encrypted root, this is genuinely good news!

Yes. I'm using passdev in initramfs at the scripts/local-top
stage as per cryptsetup docs to mount an encrypted root,
unlocking it via a keyfile located on an USB key.

/etc/crypttab:

# dev source keyfile opts
root /dev/sda2 /dev/disk/by-label/keys:/rootkey luks,keyscript=passdev

Then, update-initramfs -u

/dev/sda2 set up using cryptsetup luksFormat. No LVM.
Working on current Kali Linux, based on Jessie/sid.
Sorry I don't have version numbers at hand.

HTH, YMMV! :)

[Rick Thomas]

Woo Hoo! I can’t wait to test it! (-: (-: (-:

[Martin Pitt]

Rick Thomas [2015-10-16 8:40 -0700]:

> Does this work for encrypted root as well?

FTR, systemd isn't involved in unlocking the root file system, that
already (has to) happen in the initramfs. So this can only affect
non-root file systems.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Marcello Barnaba]

>> Does this work for encrypted root as well?

> FTR, systemd isn't involved in unlocking the root file system, that
> already (has to) happen in the initramfs. So this can only affect
> non-root file systems.

With the setup I've detailed above (encrypted LUKS root
unlocked via the passdev keyscript) I see autogenerated
systemd units trying to setup an *already mounted root*.
Same for encrypted swap, already set up in initramfs.

The units wait and time out after 90 seconds, causing a
noticeable boot delay. Adding "luks=no" (or rd.luks=no)
disables the generator and the delay.

If you need more details or information other than what I've
provided above please let me know.

Thanks,

[Rick Thomas]

I tested Marcello’s workaround. It works! That’s wonderful! Thank you so much, Marcello!

Now some further thoughts on the subject…

It’s a workaround for this bug, but, unfortunately it’s just a workaround not a real fix. In particular, using a “luks=no” kernel command line option disables all luks encryption that is not unlocked in the initrd phase. Decryption that waits until we’re out of the initrd is a less common use-case, but nevertheless a legitimate one.

A better work around would be to recognize the (documented but not currently working under systemd) crypttab option “noearly” — which prevents attempts to decrypt when in initrd — and a new (not currently documented or implemented) option “earlyonly” — which specifies that decryption for this item must occur while in initrd and should not be attempted outside of initrd.

But even that’s just a workaround. A true _fix_ would be to never attempt to decrypt any item has already been successfully decrypted by an earlier stage.

Enjoy!
Rick

> --
> To unsubscribe, send mail to 618862-un...@bugs.debian.org.
>