Nice, that was something I wanted for my Fileserver.

The only issue I see is, that I can imagine use cases where I want to unlock a device at boot if a keyfile is available, but still continue booting when it is missing. I'm not sure if this is possible at the moment with luksroot but I have this issue with the filesystems.*.encrypted module atm so it would be nice if that'd (still) work.

That's a good point -- I was mostly thinking of the case of unlocking / : if it is not available, the system just doesn't boot.
What should I do ? adding an option required guarding this fallback mechanism ? Adding a timeout to the cryptsetup prompt ?

maybe a enablePasswordFallback oder disablePasswordFallback Option?

If a timeout is chosen there should be a option to configure it IMO, with the possibility of waiting forever. Actually that might be the most flexible way.

Timeout feels somewhat wrong to me (what if you have a long password?). Something better may be to set a number of retries before booting continues. Usual three seems to be enough. What do you think?

EDIT: I need to test that, but won't ^C kill the password prompt?

@abbradar not sure I understand your point about retries. The main problem is that if the luks device is not so important, and that the key goes missing, the system can't boot unattended anymore.
That the user can ^C is (from that point of view) irrelevant.
By the way, if a key is missing with the current bahavior for a "non-essential" drive, what happens ?

@symphorien Hm, indeed, ^C doesn't help the usecase when you want to continue unattended boot with the key missing but the partition not strictly required.

Maybe then use timeout not for the prompt itself, but for the fallback? In lines of "Key for ${foo} is not found. Press any key in N seconds to enter password phrase instead". Then one can type the password at their own leisure.

@symphorien I don't remember the code well now, but I think the system will just continue to boot. The drive will stay encrypted.

I pushed a commit implementing an option fallback guarding the interactive prompt. It is set to false by default and thus backward compatible.
I am open to bikeshedding about the name of the option.
I tested all the 4 combination of {key file is present}×{fallback==true} on my computer. It works for me™

I think it would be good to name the option, so it is clear what it does. But I don't have a good idea sadly.

A few ideas, but they might be too verbose

• fallbackToPasswordIfKeyFileIsMissing (long, and doesn't have 'keyfile' at the start)
• passwordFallback (unclear that it only applies when keyfile is set)
• keyFileFallback (unclear what that means. E.g. is it another file?)
• keyFilePasswordFallback (Could be interpreted, that is is a string with the password)

I think I'd prefer the last one, if no one has a better idea.

I had also thought of interactiveFallback

Sorry for the delay.
I finally went for fallbackToPassword.
If nobody objects, I think this is ready to merge.

hum should I add something to make this mergeable ?

I know there's the 18.03 milestone, but… is there anything missing for this PR to be merged?