Why can `nixos-generators` not worry about `hardware-configuration.nix`?

Help
1

I was excited reading about nixos-generators, I liked the idea that I could capture the current state of my config so the initial install picks up right where I left off, instead of going through the installer then copying in my config from github. But I don’t understand the component of hardware-configuration.nix in that context.

My hardware-configuration.nix contains lines like this

  boot.initrd.availableKernelModules =
    [ "xhci_pci" "thunderbolt" "nvme" "usb_storage" "sd_mod" ];
  boot.initrd.kernelModules = [ ];
  boot.kernelModules = [ "kvm-intel" ];
  boot.extraModulePackages = [ ];

  fileSystems."/" = {
    device = "/dev/disk/by-uuid/6a2640f4-3576-4b30-b16a-8802b2362444";
    fsType = "ext4";
  };

  fileSystems."/boot" = {
    device = "/dev/disk/by-uuid/733C-1474";
    fsType = "vfat";
  };

  swapDevices =
    [{ device = "/dev/disk/by-uuid/87de26f4-5b03-4a7e-9bd9-5065ea7d1b76"; }];

Which seem very precise to the local conditions. If I built an .iso from github based on my current machine, wouldn’t that also put the hardware-configuration.nix in there, which would be wrong because it wasn’t generated by the nixos-generate-config on the machine in particular?

The .isos from nixos-generators would make sense to me if they were simply skipping hardware-configuration.nix, and the user had to generate one first thing upon boot. – is that how they work?

1 Like
2

parts of the hardware-configuration will be ignored by the iso format. like the fileSystems. For more portability on different systems I would suggest using the installer-iso which would also add a bunch of common kernelModules and hardware and should usually work with a generated hardware-configuration.nix (although I have not really tested that). I would suggest trying it out and if stuff breaks we can discuss it in an issue on the nixos-generators project.

2 Likes
3

To spell it out a bit more clearly, stuff like fileSystems is ignored because the boot process doesn’t follow the usual module at all, and therefore the iso “ignores” those settings - it just happens to not actually use them, but other settings (or hardcoded flags in some buildPhase more likely).

As for the kernelModules, since those are lists, they will be merged with whatever defaults are set by the generator, so setting them elsewhere is harmless, at worst it installs and loads some kernel modules that don’t end up doing anything because the hardware isn’t present.

You’re right though that you probably shouldn’t add a hardware-configuration.nix to something you feed to a nixos-generators generator. It just happens not to be harmful today because of the specific options it sets. At best it’s confusing for anyone reading your project who doesn’t know that, so it’s probably good practice not to do that.

You can exclude things from your config depending on variables using e.g. lib.mkIf, or you can create different entrypoints for your config/image which import slightly different modules. There’s no need to add your hardware-configuration.nix to the image as well.

2 Likes
4

parts of the hardware-configuration will be ignored by the iso format

Does this also apply other non-installer based formats like sd-aarch64?

1 Like