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