Here is my workaround on debian, given the bug referenced above by @sebasth.
My setup is slightly different. I have an encrypted root partition and a bunch of raid disks. For me, I had to add a initramfs option to the crypttab:
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
This tells update-initramfs that I want to have these crypttab entries mounted in the initramfs. I checked my crypttab by running
Note that my raid disks are plain dm-crypt. This meant that I could not use the luks keyfile method that works around the systemd keyscript bug. For plain dm-crypt, I would have to store the passphrase in plaintext.
The package keyutils has to be installed and the encrypted disks have to be mounted before
update-initramfs is run ; otherwise it will throw errors. I had to look for the following lines when my initramfs was built:
update-initramfs -u -v | grep 'keyctl'
which showed the following two files:
being added to the initramfs.
Finally, I had to disable systemd handling my crypttab, to deal with the bug referenced above: systemd does not support the keyscript option in crypttab. For this, I added the kernel option
to /etc/default/grub and ran
update-grub. systemd now ignores crypttab, and all the encrypted partitions are loaded in the initramfs.
Because I have an encrypted root partition, cryptroot does not appear to cache my key. This means I have to enter my password twice; one for the root partition and once for my raid array.
expectscript or similar that gets called to mount the disks instead of having the system do it. Instead, the system would call the script which would ask for the password, store it, and provide it to each of the mount operations.
/etc/crypttabto unlock the second drive.