Unlock luks after initrd

I know there is the boot.initrd.luks option to unlock disks in initrd, but is there an equivalent for unlocking after initrd? Do I have to write crypttab file with environment.etc?

I think so, something like this:

  fileSystems."/var/archive" =
    { device = "/dev/mapper/archive";
      options = [ "defaults" "noauto" ];
    };

  environment.etc."crypttab".text = ''
    archive /dev/sda /path/to/key noauto
  '';
1 Like

Ah, there’s also security.pam.mount (with users.<name>.cryptHomeLuks) to unlock /home/ on login.

I’ve thought about implementing convenient options to autogenerate /etc/crypttab, but so far haven’t found a compelling reason to do so. I mean, I’d like for our luks options to be able to autodetect which ones are needed in stage 1 and which ones we can defer to stage 2, which would be a good reason to have abstract options for luks like we do for fileSystems. But it’s not trivial to know which LUKS devices are needed in stage 1, since they aren’t always the device for a stage 1 fileSystems entry.

For now, you can just write your own environment.etc.crypttab for things you know can go in stage 2, and I don’t see anything wrong with that.

1 Like