Just to give an update, creating the crypttab
file via etc.environment
did end up working!
For now I went with the simplest possible approach, which I’ve copied below:
environment.etc.crypttab = {
enable = true;
text = ''
# sda3_crypt UUID=2644f599-e320-4c60-bc1a-bc0d4cba7d46 none luks
data_disk1_crypt UUID=2b7c47cb-a425-4493-8d7d-4227537a40d5 /root/keyfile luks
data_disk2_crypt UUID=ebaf3ced-e0ec-4978-bf7c-839c30ba0051 /root/keyfile luks
data_disk3_crypt UUID=353ce3c1-7c53-448a-909b-d239d210c99b /root/keyfile luks
parity_disk1_crypt UUID=a7c2e0a5-c5ec-4dc9-94fd-4118890e6486 /root/keyfile luks
'';
};
The contents of the file are almost identical to the file I had on the Debian installation I’m moving away from. The key different is that the entry for the disk containing the the root filesystem (sda3_crypt
) had to be commented out.
I’m guessing that’s unlocked by the Stage1 Bootloader via the preLVMCommands
and that seems to interfere in minor ways with having it in the crypttab
.
I use ssh in my initrd
via the boot.initrd.network.ssh
option. Having that first line in my crpyttab
causes the boot sequence to ask for the password a second time, once when I’ve already unlocked it over ssh via cryptsetup-askpass
.
I’ll investigate whether or not that double prompting behaviour is exclusive to ssh unlocking and report back tonight.
Thank you for the help @ElvishJerricco and @emmanuelrosa