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 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 -k -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.