-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multiple encrypted devices #54
base: master
Are you sure you want to change the base?
Conversation
how does dracut solve this problem? how do you specify multiple cryptroots? |
Dracut allows
So I provided something analogous with this patch. Let me walk through my usage more directly. My boot command line looks like this:
I also have /boot/key.img included in my initfs. With this patch, the init script:
My goals were:
|
I had another look at this and #57 which solves same problem but differently. I sort of like that you can specify Basically, I'd like nlplug-findfs handle multiple crypt devices. |
1bd35cc
to
fb11260
Compare
It's been a minute, but I need to retool my boot process, so I'm taking another look at this.
I'm not sure this works for multi-encrypted-device btrfs. (The initial version of this PR wrongly called It's not clear to me that Calling the I updated this PR with a simple implementation of these ideas. This satisfies my use case of multiple-encrypted-device btrfs root, with single password entry. I use Out of curiosity, why does alpine not package dracut? It would be nice to have access to it for these more complex cases. |
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 latercryptkey
argument. Note: I couldn't figure out a way to getnlplug-findfs
to 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 invokenlplug-findfs
to do hotplugging, for e.g. USB keyboards to enter the passphrase, so I do a "no-op"nlplug-findfs
.cryptroot=...
supports multiple arguments. If multiple arguments are detected, we unlock each explicitly withnlplug-findfs
.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 thatKOPT_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.