What's the difference between `boot.initrd.luks.devices` and `fileSystems.<name>.encrypted`?

Help
1

Hi,

I want to add another encrypted SSD to my PC that will just hold user data (i.e. is not required for boot, only at the point I log in).

Of course I added the required fileSystems.<name> stuff but when it comes to the encryption part, I see two options:

  • boot.initrd.luks.devices and
  • fileSystems.<name>.encryption

I went with the filesyStems approach because I don’t need the disk to be available very early and I guess this approach opens the encrypted disk later during boot, which in my imagination might improve boot time (due to parallel running tasks at boot time).

Then I realized, that allowDiscards = true and bypassWorkqueues = true (which increase SSD performance) can not be set using fileSystems.<name>.encryption, so I dove into the nix code of both modules to find out their differences.

It seems to me that fileSystems.<name>.encryption actually just adds the value of it’s blkDev setting as boot.initrd.luks.devices.<name>.device and adds a luks open call to boot.initrd.postMountCommands. (see encrypted-devices.nix#L72-L85)

But why is it then, that I get asked for the disk password, when I set boot.initrd.luks.devices.<name>.device myself?

So what’s really the difference between those two? And If it wasn’t for the allowDiscard and bypassWorkqueses options (which require me to use boot.initrd.luks.devices anyways) which option should one use?

3 Likes
2

I’m in a similar situation, and from what i found in the internet this kind of thing is achievable in other distros by editing /etc/crypttab, but i can’t find an option related on nixos, only stuff to unlock in initrd…

3

I’ve just ran into this question while trying to configure a filesystems block for a non-root device which should be unencrypted using a keyfile present in root. The following configuration works:

  environment.etc.crypttab.text = ''
    redundancy UUID=16d8517a-db8a-467c-8c37-82ed6e595747 /root/mykeyfile
  '';

    filesystems."/mnt/redundancy" = {
      device = "/dev/mapper/redundancy-data";  # this is a LVM, data is the LV
      fsType = "ext4";
      options = [ "nofail" ];
    };

while the following fails:

    filesystems."/mnt/redundancy" = {
      encrypted = {
        enable = true;
        label = "redundancy";
        blkDev = "/dev/disk/by-uuid/16d8517a-db8a-467c-8c37-82ed6e595747";
        keyFile = "/mnt-root/root/mykeyfile";
      };
      device = "/dev/mapper/redundancy-data";  # this is a LVM, data is the LV
      fsType = "ext4";
      options = [ "nofail" ];
    };

As you noticed, the module should just add a cryptsetup call to the stage-1-init.sh but the boot simply fails to find the drive by the uuid, not even tries to decrypt it.

In a different machine I succesfully configured using systemd:

boot.initrd.= {
      systemd.enable = true;
      luks.devices =
        lib.mapAttrs
          (name: uuid: {
            device = "/dev/disk/by-uuid/${uuid}";
            keyFile = "/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_4C530799930103105381-0:0";
            keyFileSize = 4096;
            keyFileOffset = 0;
            keyFileTimeout = 5;
          })
          {
            "root" = "d553bb8e-c491-4412-b317-e904f905c0df";
            "swap" = "8429c2f2-1ca5-43db-8baf-e1a4ff10e93a";
          };
    };
 };

which let me wondering why one is failing but the other is not.

4

If this works, this is what you should be doing. The initrd should be doing as little as possible, so doing this in stage 2 is a lot better.

As for why fileSystems.<name>.encrypted didn’t work, I’m honestly not sure. My guess is that the drive actually isn’t available in initrd because of a missing driver, like boot.initrd.availableKernelModules = [ "uas" ]; or something.

(Furthermore, I dislike the fileSystems.<name>.encrypted option and I think it probably should be removed, so I’d avoid it in favor of boot.initrd.luks or /etc/crypttab anyway)

1 Like
5

Thanks for the explanation.My initial goal was to see if I could configure the same thing through a more structured interface, with attrs instead of just appending text to environment.etc.crypttab.text.

I don’t know much about boot process, do you have any thoughts on the use of boot.initrd.systemd? Is it also an overload of the stage 1? Or am I misunderstanding?

6

As a person who did a very large percentage of the work creating boot.initrd.systemd, I sure do have opinions :stuck_out_tongue:

We recently merged the PR to make systemd stage 1 the default. It’s an alternate implementation of the entire NixOS initrd, and the consensus has been for a long time now that it’s a lot better than the scripted initrd. It’s a lot more flexible, it has a lot more features, and it benefits a lot more from functionality provided by upstream systemd.

2 Likes
7

Thanks for the explanation. It was really helpful but I still have to learn more about boot processes.

Could you also explain me how this change was discussed in the community? Like, how it started, where and with whom? This question is more about the dynamics of such changes in NixOS/nixpkgs, just so I can be in the loop and maybe eventually even participate or propose something.

8

I don’t know about this specific PR but any new change can just be sent as a PR without prior discussion - the discussion would happen on the PR, and if there’s a fair amount of support it’d be more likely to get merged quickly. If there’s not sufficient support, you may want to get some committer’s attention/interest somehow. And if it’s controversial and disruptive enough, then usually that’s when the RFC process comes in prior to sending the PR.

If you want to participate in the discussions, this PR was open for nearly a year - and if you have some investment in such changes then you’d likely come across this PR anyway (see the associated taskboard in systemd in Stage 1 · GitHub).

1 Like