2024-09-25 09:37:57 +00:00
|
|
|
{ hostPkgs, ... }: {
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
name = "nixos-rebuild-specialisations";
|
|
|
|
|
2024-09-25 09:37:57 +00:00
|
|
|
# TODO: remove overlay from nixos/modules/profiles/installation-device.nix
|
|
|
|
# make it a _small package instead, then remove pkgsReadOnly = false;.
|
|
|
|
node.pkgsReadOnly = false;
|
|
|
|
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
nodes = {
|
|
|
|
machine = { lib, pkgs, ... }: {
|
|
|
|
imports = [
|
|
|
|
../modules/profiles/installation-device.nix
|
|
|
|
../modules/profiles/base.nix
|
|
|
|
];
|
|
|
|
|
|
|
|
nix.settings = {
|
|
|
|
substituters = lib.mkForce [ ];
|
|
|
|
hashed-mirrors = null;
|
|
|
|
connect-timeout = 1;
|
|
|
|
};
|
|
|
|
|
2023-06-10 16:23:02 +00:00
|
|
|
system.includeBuildDependencies = true;
|
|
|
|
|
|
|
|
system.extraDependencies = [
|
|
|
|
# Not part of the initial build apparently?
|
|
|
|
pkgs.grub2
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
];
|
|
|
|
|
2024-09-10 14:54:34 +00:00
|
|
|
system.switch.enable = true;
|
|
|
|
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
virtualisation = {
|
|
|
|
cores = 2;
|
2023-12-17 16:27:07 +00:00
|
|
|
memorySize = 4096;
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
};
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
testScript =
|
|
|
|
let
|
2024-09-25 09:37:57 +00:00
|
|
|
configFile = hostPkgs.writeText "configuration.nix" ''
|
nixos: add --specialisation to nixos-rebuild
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
2022-12-23 20:23:36 +00:00
|
|
|
{ lib, pkgs, ... }: {
|
|
|
|
imports = [
|
|
|
|
./hardware-configuration.nix
|
|
|
|
<nixpkgs/nixos/modules/testing/test-instrumentation.nix>
|
|
|
|
];
|
|
|
|
|
|
|
|
boot.loader.grub = {
|
|
|
|
enable = true;
|
|
|
|
device = "/dev/vda";
|
|
|
|
forceInstall = true;
|
|
|
|
};
|
|
|
|
|
|
|
|
documentation.enable = false;
|
|
|
|
|
|
|
|
environment.systemPackages = [
|
|
|
|
(pkgs.writeShellScriptBin "parent" "")
|
|
|
|
];
|
|
|
|
|
|
|
|
specialisation.foo = {
|
|
|
|
inheritParentConfig = true;
|
|
|
|
|
|
|
|
configuration = { ... }: {
|
|
|
|
environment.systemPackages = [
|
|
|
|
(pkgs.writeShellScriptBin "foo" "")
|
|
|
|
];
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
specialisation.bar = {
|
|
|
|
inheritParentConfig = true;
|
|
|
|
|
|
|
|
configuration = { ... }: {
|
|
|
|
environment.systemPackages = [
|
|
|
|
(pkgs.writeShellScriptBin "bar" "")
|
|
|
|
];
|
|
|
|
};
|
|
|
|
};
|
|
|
|
}
|
|
|
|
'';
|
|
|
|
|
|
|
|
in
|
|
|
|
''
|
|
|
|
machine.start()
|
|
|
|
machine.succeed("udevadm settle")
|
|
|
|
machine.wait_for_unit("multi-user.target")
|
|
|
|
|
|
|
|
machine.succeed("nixos-generate-config")
|
|
|
|
machine.copy_from_host(
|
|
|
|
"${configFile}",
|
|
|
|
"/etc/nixos/configuration.nix",
|
|
|
|
)
|
|
|
|
|
|
|
|
with subtest("Switch to the base system"):
|
|
|
|
machine.succeed("nixos-rebuild switch")
|
|
|
|
machine.succeed("parent")
|
|
|
|
machine.fail("foo")
|
|
|
|
machine.fail("bar")
|
|
|
|
|
|
|
|
with subtest("Switch from base system into a specialization"):
|
|
|
|
machine.succeed("nixos-rebuild switch --specialisation foo")
|
|
|
|
machine.succeed("parent")
|
|
|
|
machine.succeed("foo")
|
|
|
|
machine.fail("bar")
|
|
|
|
|
|
|
|
with subtest("Switch from specialization into another specialization"):
|
|
|
|
machine.succeed("nixos-rebuild switch -c bar")
|
|
|
|
machine.succeed("parent")
|
|
|
|
machine.fail("foo")
|
|
|
|
machine.succeed("bar")
|
|
|
|
|
|
|
|
with subtest("Switch from specialization into the base system"):
|
|
|
|
machine.succeed("nixos-rebuild switch")
|
|
|
|
machine.succeed("parent")
|
|
|
|
machine.fail("foo")
|
|
|
|
machine.fail("bar")
|
|
|
|
|
|
|
|
with subtest("Switch into specialization using `nixos-rebuild test`"):
|
|
|
|
machine.succeed("nixos-rebuild test --specialisation foo")
|
|
|
|
machine.succeed("parent")
|
|
|
|
machine.succeed("foo")
|
|
|
|
machine.fail("bar")
|
|
|
|
|
|
|
|
with subtest("Make sure nonsense command combinations are forbidden"):
|
|
|
|
machine.fail("nixos-rebuild boot --specialisation foo")
|
|
|
|
machine.fail("nixos-rebuild boot -c foo")
|
|
|
|
'';
|
2024-09-25 09:37:57 +00:00
|
|
|
}
|