I’m working on creating a more portable configuration.nix and I’ve hit a snag with LUKS. My goal is to have a main configuration that can be version-controlled and deployed to different machines or new disks without needing to edit hardware-specific identifiers like UUIDs.
Currently, my LUKS setup is defined in configuration.nix like this:
This ties my configuration to a specific disk. I’d like to find a more dynamic way to specify the LUKS device.
My main question is: Are there built-in NixOS options or common patterns to automatically discover and unlock a LUKS partition during boot without hardcoding its UUID?
Ultimately, I’m looking for the “Nix way” to define something like “unlock the LUKS partition on the primary disk” without needing to know its UUID beforehand.
Any pointers, examples, or discussions on this topic would be greatly appreciated!
The machine-generated hardware-configuration.nix should contain the boot.initrd.luks.devices settings. If you give your LUKS device a name (not luks-[UUID], but decrypted-disk or something), then you can reference /dev/mapper/decrypted-disk elsewhere in your config and leave the details of the underlying UUID to hardware-configuration.nix, which should be generated anew at each installation site.
So the “Nix way” here is to keep the hardware-configuration.nix machine-specific and let it handle the UUIDs, while my main configuration.nix stays clean and refers to the device by a generic name like decrypted-disk. I will try to use labels (/dev/disk/by-label/…) to make it even more consistent across different installs. Thanks for pointing me in the right direction!
Theoretically you can avoid the need for hardware-configuration.nix that way. disko can also set up partitioning for you and will allow reproducibly configuring your systems with the same disk labels and such.
You’ll still need details like the kernel modules and platform tuple defined by hardware-configuration.nix, though, so completely hardware-independent NixOS configuration is only possible if the hardware you deploy to is almost exactly the same, or at least same enough that you can have one fully portable kernel config.