Support multiple cryptroot= devices.
Created by: sbrudenell
I use btrfs on multiple LUKS-encrypted disks. In order to support single password entry, I have a keyfile that is a LUKS-encrypted image that, once decrypted, also decrypts the other volumes.
I made some changes to init to support this. I feel they're in line with the current design and don't interfere with other use cases. Let me know if I should make any changes to support this goal.
cryptkey=...has special behavior if the key matches
*.img: We'll treat it as a LUKS-encrypted file (with embedded header), and try to unlock it. We use the unlocked key as a later
cryptkeyargument. Note: I couldn't figure out a way to get
nlplug-findfsto do this with a single invocation, so I invoke cryptsetup directly, so it needs to be included as a feature. However I still need to invoke
nlplug-findfsto do hotplugging, for e.g. USB keyboards to enter the passphrase, so I do a "no-op"
cryptroot=...supports multiple arguments. If multiple arguments are detected, we unlock each explicitly with
We now support multiple entries of a single argument, e.g.
cryptroot=UUID=a cryptroot=UUID=b. This will accumulate the arguments joined by whitespace, such that
KOPT_cryptroot="UUID=a UUID=b". This matches the way one passes multiple arg entries to the kernel, so hopefully it makes sense to users.
Note: I made change 3 really because the apparent intended use was broken for me. Code comments imply that I should be able to pass
cryptroot="UUID=a UUID=b". I did this in my grub.cfg and verified it in the command list at boot time, but once booted,
/proc/cmdline looked like
... "cryptroot=UUID=a UUID=b" ..., and init did not parse this as intended. I'm not sure if this is a known bug. I'm using grub-efi-2.02-r14 and linux-vanilla-4.19.41-r0.