At the top of my
hardware-configuration.nix there is a nice warning not to edit the file as it may be overwritten:
# Do not modify this file! It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations. Please make changes
# to /etc/nixos/configuration.nix instead.
I admit that I’ve edited it a bunch, as to me it makes sense to put things there like filesystem mount options, swap file options, auto-unlock settings for luks volumes, kernel boot parameters. In my mind these are mostly specific to the machine and make sense to go there. If I was moving to a new machine I would mostly copy
I know I could heed the warning and put all my changes into
configuration.nix instead, but I’m wondering in practice whether that’s worthwhile.
How strictly do you heed this warning, and avoid editing this file?
You are free to create any structure you want. If you have multiple machines, you would very quickly start modularizing the setup anyway and come up with an entirely new structure.
I make changes to it when I need. One example in which you can’t really on nixos-generate-config is it doesn’t work well with btrfs, it doesn’t include all mounts options.
From the config directory:
$ find modules -type f | wc -l
Includes custom modules as well as configuration.
$ find modules -type f -name hardware-configuration.nix | wc -l
Not a single file named
Heed the warning or don’t - it doesn’t matter.
After installation I maintain that file completely by hand.
The parts that change the most are usually related to how partitions are mounted. And I hate how
nixos-generate-config always creates mount points for ephemerally mounted drives. So I had to remove them manually anyway.
And change all the
One thing I didn’t see mentioned so far is that one benefit of not editing
hardware-configuration.nix is that you can in theory re-run
nixos-generate-config and get the same output (or at least someething relatively similar).
This can be helpful in the following situations:
You’ve made some changes to
hardware-configuration.nix but they are causing problems, so you want to go back to the “default”. (Although in this situation it might be better to just version control your NixOS configuration.)
You’ve upgraded to a later version of NixOS, and you want to see if there have been any changes to
nixos-generate-config that give you a configuration more appropriate for your hardware (or a recent kernel). If you’ve edited
hardware-configuration.nix by hand, it can be a little difficult to make out what changes are necessary and need to be copied over, and which things are just strict improvements by people in how
Personally, I’m quite strict about it, for the reasons @cdepillabout mentions.
It’s no real additional effort to override the configuration in
configuration.nix if need be, and I think that’s preferable - the config needs to be somewhere after all, no harm in having the autogenerated file around as well, even if I override its settings a bit.
To be honest, as network and DHCP config has moved from generated
hardware-configuration.nix somewhen between 19.09 and 22.05, there has to happen careful manual join anyway, whether you edited the hardware configuration or not.
Who knows whether or not the network was the first or the last or neither.
I’m considering creating a
hardware-configuration-overrides.nix file and including it to specify the overrides in a separate place, just in case.
Using NixOS on approximately 80 hosts - not a single hardware-configuration.nix in sight. What exactly is the use case here?
I realize that my earlier mail came across little “short”.
There is nothing magical about the filenames generated other than
configuration.nix (outside flakes). You could easily store the hardware configuration in a file named after your favourite character in “Veep” or “Arrested Development” (both fantastic shows btw, but I digress).
nixos-generate-config will write out
hardware-configuration.nix but the generated configuration is really just meant as inspiration for you to get started and you will inevitably end up with “hardware configuration” spread out over multiple files/modules as you start accomodating new hardware.