Dual-boot Flake Outputs

Help
1

Apologies if this is something that is obvious, I’m still relatively new to Nix/NixOS

I’m familiar with NixOS specialisations, but I’ve found them problematic when using with flakes.

Lower-level NixOS options (e.g. boot.consoleLogLevel) don’t seem to work properly through specialisations, and specialisation.<name>.inheritParentConfig makes flake inputs inaccessible.

Is there a way to multi-boot multiple flake outputs?

2 
nixos-rebuild boot flake#host1
nixos-rebuild boot flake#host2

or am I missing something?

3

Alright, I suppose that will work.

I was hoping there might be a method that keeps it in one nixos-rebuild call for easier updates, but I can always just put it all in an alias with &&, I suppose.

Thanks for the help!

4

They absolutely should, though of course things like consoleLogLevel will require booting into the specialisation rather than switching to it at runtime.

Huh? I see no such problem.

5

I’m using the imports option to modularize my configuration, so certain modules can be shared between specialisations. When I try to import my module for splash boot (uses plymouth) it doesn’t work. It also uses boot.consoleLogLevel = 0, which doesn’t seem to work either. Maybe it is incorrectly imported?

When I use specialisation.<name>.inheritParentConfig, imported flakes (for example, home-manager) seem to be inaccessible.

It throws an error suggesting that the option ‘does not exist’.

6

You’ll have to actually share your config. The problems you’re describing do not align with my understanding of how specialisations work or my experience with them.

7

Strange. Perhaps those problems were due to simple misconfigurations. I’ve just tested, (made changes since I last tested,) and now inheritParentConfig seems not to be causing any problems.

I think it was because I had some bits of config not separated into modularized files, just being loose in the flake.nix. Forgetting about these, I ran into problems due to their absence.

Upon further testing, the second problem seems to be completely unrelated from specialisations. It’s broken when I use it system-wide as well. I must have changed something since it had worked previously.

Relevant parts of my config

flake.nix:

{
  description = "My NixOS system flake";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

    nixpkgs-stable.url = "github:NixOS/nixpkgs/nixos-24.05"; # I should update this.

    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };

   # ...
  };

  # ... (CUDA cachix)

  outputs =
    {
      self,
      nixpkgs,
      nixpkgs-stable,
      home-manager,
      # ...
      ...
    }@inputs:
    {
      nixosConfigurations = {
        nixos = nixpkgs.lib.nixosSystem {
          system = "x86_64-linux";
          specialArgs = { inherit inputs; };
          modules = [
            home-manager.nixosModules.home-manager

            # ...

            {
              specialisation = {
                main.configuration = {
                  system.nixos.tags = [ "main" ];

                  imports = [
                    # ...
                  ];
                };

                unplugged.configuration = {
                  system.nixos.tags = [ "unplugged" ];

                  imports = [
                    # ...
                  ];
                };

                distraction-free.configuration = {
                  imports = [
                    # ...
                    "${inputs.self}/modules/niceboot.nix" # Splash boot, doesn't seem to work.
                  ];
                };
              };
            }

            "${inputs.self}/hardware-configuration.nix"
            "${inputs.self}/configuration.nix"
            "${inputs.self}/modules/zsh-config.nix"
          ];
        };
      };
    };
}

niceboot.nix:

{ ... }:

{
  boot = {
    consoleLogLevel = 0;
    initrd.verbose = false;
    kernelParams = [
      "quiet"
      "splash"
      "boot.shell_on_fail"
      "loglevel=3"
      "rd.systemd.show_status=false"
      "rd.udev.log_level=3"
      "udev.log_priority=3"
    ];
  };
}

Sorry for the inconvenience!

8

I’ve found that using inputs.self.outPath in configs (which this does, implicitly) caused eval to take longer, sometimes even causing spurious rebuilds depending on where it’s used, though I forgot the exact details.

IMO the idiomatic way to write this would just be ./hardware-configuration.nix.

9

Yes, using "${inputs.self}/foo" syntax can cause spurious rebuilds, but it’s not relevant in this case. It will evaluate to the string "/nix/store/...-source/foo", where that source directory is the one that your flake was copied into in the nix store. Importing a Nix expression from a string like that is fine; it’s just evaluating Nix code, after all. But if you do something like src = "${inputs.self}/rust/src";, this will be a problem. In this case, the src will change any time that inputs.self changes at all, causing the derivation to be rebuilt. Whereas src = ./rust/src; will copy ./rust/src into the nix store at its own content-addressed path, which only changes when ./rust/src changes.

10

Thanks!

I’ve adjusted my configuration to use ./thing instead of "${inputs.self}/thing" everywhere I had been using it.
Glad to receive insight!