Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#23182 - [cryptsetup] Multiple device support for encrypt hook

Attached to Project: Arch Linux
Opened by Stefan J. Betz (encbladexp) - Monday, 07 March 2011, 22:04 GMT
Last edited by Jelle van der Waa (jelly) - Thursday, 31 March 2011, 12:13 GMT
Task Type Feature Request
Category Packages: Core
Status Assigned
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No


Currently the encrypt hook for mkinitcpio can parse only on volume for encryption in the early boot stage. But there are some situations where multiple encrypted volumes are required to build a lvm or raid device.

sda1 -> Encrypted
sdb1 -> Encrypted

Both volumes (sda1 and sdb1) are from the same volume group or raidset, but encrypted with different settings and/or passwords. The following syntax for encrypt maybe a good solution for this:
This task depends upon

Comment by Tobias Powalowski (tpowa) - Wednesday, 09 March 2011, 08:49 GMT
Why not just encrypt the final device?
The lvm volume or the raid volume.
Comment by Stefan J. Betz (encbladexp) - Wednesday, 09 March 2011, 19:21 GMT
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.
Comment by Tobias Powalowski (tpowa) - Thursday, 10 March 2011, 06:59 GMT
If you use raid then encrypt the whole md and set lvm on top, let initcpio load mdadm first, then encrypt then lvm.
Comment by Stefan J. Betz (encbladexp) - Thursday, 10 March 2011, 08:16 GMT
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).
Comment by Izidor Matušov (iyo) - Sunday, 09 September 2012, 10:49 GMT
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)
Comment by Valerio (valo) - Friday, 23 August 2013, 12:01 GMT
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.
Comment by Stefan J. Betz (encbladexp) - Thursday, 12 September 2013, 08:30 GMT
Any News on this enhancement?
Comment by beta990 (beta990) - Thursday, 24 April 2014, 20:05 GMT
@all: I've added instructions to the Wiki about unlocking multiple drives at boot.
Does this solve the issue?
Comment by Aaron Hsu (arcfide) - Monday, 21 July 2014, 16:09 GMT
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.
Comment by Jan (medhefgo) - Thursday, 26 February 2015, 15:32 GMT
You can unlock multiple encrypted volumes using the systemd hook's cryptsetup support.
Comment by Tom Hunt (alethiophile) - Friday, 01 January 2016, 06:26 GMT
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.