Bug#618862: systemd: ignores keyscript in crypttab

[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

 
On Oct 18, 2015, at 4:17 AM, Marcello Barnaba <vjt at openssl.it> wrote:

> 
>>> 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,
> 
> ~Marcello
> -- 
> ~ vjt at openssl.it
> ~ http://sindro.me/
> 
> -- 
> To unsubscribe, send mail to 618862-unsubscribe at bugs.debian.org.
>