Arch Linux

Why not just encrypt the final device?
The lvm volume or the raid volume.

Because lvm has snapshots, and many people have many volumes. Entering a password several times on system startup (one for each volume) is IMHO no usable option. But on RAID encrypting the final volume is the better solution, point taken.

If you use raid then encrypt the whole md and set lvm on top, let initcpio load mdadm first, then encrypt then lvm.

Forget the RAID, for RAID setups encrypting the final volume is a good and recommended solution. But many People have no RAID, but more than one lvm physical volume.

The goal is only that you can decode multiple volumes / partitions directly in the initrd, I think there are enough applications for it! My LVM Setup is only one, but there are many others (encrypted swap without LVM for hibernate).

I have the same problem. My use case:

In the morning I turn on my laptop, wait to enter password for the encrypted disc and use the bathroom. When I am back, GNOME is running with opened windows, just sit down and start working. :D

I changed the "encrypt" hook to split cryptdevice by ',,' (you can have a comma in parameters) and for each device ask for a password. The password is remembered and tried for the next disc by default. In other words, I enter the password only once and both discs are decrypted. If you want to enter your password in the secure way, attach /bin/stty to ramdisk (FILES="/bin/stty" in /etc/mkinitcpio.conf)

My setup is cryptsetup+luks and, on top, lvm,: 2 disks, different passphrase, same volume goup
I searched for a while and with the current encrypt hook for me works the setup contained in the patch. It's my first edit and i'm not sure it's correct. I tested with passphrase and i'm testing for keyfile.

Any News on this enhancement?

@all: I've added instructions to the Wiki about unlocking multiple drives at boot.
Does this solve the issue?

I don't consider the Wiki sufficient on a number of grounds: 1) It hard codes the assumption that you have only two devices; 2) it is fragile and error prone to extend the method above two devices; 3) the btrfs example suggests the use of device= in the fstab, but the use of udev makes this step unnecessary and more work (also another point to make a mistake); 4) It requires messing with your file system in ways that I find hackish. I've attached the encrypt hook that I'm currently using, which I think improves on the previous entries on a few points. I don't think either previous hook actually enables multiple keyfiles, and mine does not either, but I make that clear by lifting out the keyfile logic, which @Valerio 's hook doesn't. Mine doesn't do password caching. This might be a nice thing, but I don't know about the security, and I haven't had time to look at it. I'd welcome suggestions to do that well. I might incorporate the technique used in @lzidor's method. It's very clear to see what I did with my patch, as I have all the main device logic in a single open_device function, and the loop over the core objects is in a simple if block at the bottom. I also use ';' instead of ',' to represent the device separator, as the crypt options are already comma separated, and this presents a bit of an issue if you have multiple devices with options in them. The main problem with my hook is that I install it as a replacement for "encrypt" so I have to remember to do this installation after every cryptsetup upgrade or I will lose my changes. I'm not sure I understand the resistance to putting this in the main package, as it's a fairly small, easily verified patch, and it greatly assists with what I think is an important use case: encrypting btrfs over multiple volumes as the root partition.

You can unlock multiple encrypted volumes using the systemd hook's cryptsetup support.

I have also run into the lack of this functionality. My use case is a multi-device BTRFS root volume; both devices must be available to mount the root. I previously used the systemd hook, but a recent update broke that (which should probably go in a separate bug report), and systemd is painful enough to debug that it was less effort to edit the encrypt hook.

I've attached the patch I'm using, which is inspired by a version found on the forums. At least one of the versions mentioned here is probably better-thought-out; I wrote this at 11pm thinking mostly of bed. I'll echo the sentiment that it would be very nice having something like this in the package.

I opened another bug not knowing this one was here: https://bugs.archlinux.org/task/50901

But my encrypt hook is 100% backwards compatible with the existing encrypt hook, yet adds support for (unlimited, up to kernel command line limit) multiple devices and caches passwords in between them, any way we could get that merged so it can *just work* in the future?

Hook is attached, and full change history can be seen here:
https://github.com/moparisthebest/archlinux_encrypthook

I wrote some hooks a while back to do something like this:

https://bbs.archlinux.org/viewtopic.php?id=196840

Feel free to add / adapt it. I'm willing to do it if someone will point me in the right direction.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.