Conflicting definition values when regenerating `hardware-configuration.nix'

[shadowrylander]

Hello!

If you regenerate hardware-configuration.nix, you get something like the following:

error: The option `fileSystem./home/curtis/VirtualBox VMs.device' has conflicting definition values:
       - In `/etc/nixos/hardware-configuration.nix': "/persist/home/curtis/VirtualBox040VMs"
       - In `/nix/store/[hash]/nixos.nix': "/persist/home/curtis/VirtualBox VMs"

Can I mkForce the latter somehow, instead of constantly having to edit the former?

Thank you kindly for the help!

[talyz]

Well, they shouldn't be defined in hardware-configuration.nix at all, so you should remove them if you regenerate it while the mounts are active. Why do you need to frequently regenerate hardware-configuration.nix?

[shadowrylander]

Not quite frequently, actually; when I installed my system, I forgot to bind mount /mnt/etc/nixos to /mnt/persist/etc/nixos, which means the generated configuration.nix and co. were not saved the first time around. Ergo, I had to regenerate the configs for the first rebuild on the new system, and voilà. Basically, in case I ever need to regenerate the configs, I'd like to not have to manually rewrite hardware-configuration.nix again. Is there anything wrong with mkForceing your fileSystems options?

[talyz]

No, and I don't think we should either. You're expected to edit nixos-hardware.nix, since it probably doesn't contain exactly what you want from the get-go. Ignoring what it contains would also give you a surprise when you remove items from the list of persisted directories, since they would be kept persistent anyway.

[shadowrylander]

Ah; well that's unfortunate. Actually, related to that, I really only keep the hardware config around for the default kernelParameters, etc. ; would you happen to know how I can get those without the fileSystems attributes? My config sets up the fileSystems manually.

[talyz]

Okay, I now noticed that the comment at the top of nixos-hardware.nix actually says to not edit the file, so you're not expected to, but I've always had to. Infact, I always just extract the useful parts of it and put them in configuration.nix together with other machine specific config. If you want to, I guess you could just import ./nixos-hardware.nix args and extract the data you want from it. It would make the config less readable than just copying stuff, though.

[shadowrylander]

Actually, what I did was not import it directly, but use something like import <nixpkgs/nixos> { configuration.imports = ./hardware configuration.nix; }, then modify the config.fileSystems attribute of the above, merge the modified fileSystems set with my own fileSystems set, then merge the rest with my overall config set after removing fileSystems from it. So something like:

let
    hc = import <nixpkgs/nixos> { configuration.imports = ./hardware configuration.nix; };
in {
    options = { ... };
    imports = [ ... ];
    config = (builtins.removeAttrs hc.config [ "fileSystems" ]) // {
        fileSystems = [modified hc.config.fileSystems] // { ... };
    };
}

I got the idea from here: https://discourse.nixos.org/t/how-to-remove-an-attribute-from-another-nixos-file/383/5

Basically, I want to automate everything possible; just git clone my config, run my script to install, and done!

[shadowrylander]

Actually, these imports and these ignores should work; I just tested them.

But anyway; thanks for all the help!

[reinux]

No, and I don't think we should either. You're expected to edit nixos-hardware.nix, since it probably doesn't contain exactly what you want from the get-go.

OTOH, nixos-hardware.nix's header says:

# 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.

[talyz]

Yes, I expanded on this in the comment after: https://github.com/nix-community/impermanence/issues/86#issuecomment-1059997463. In my experience, nixos-generate-config gives you a good starting point, but is not clever enough to generate a fully functioning hardware config in all cases, and this issue shows that.