nixos: add --specialisation to nixos-rebuild#207466
nixos: add --specialisation to nixos-rebuild#207466RaitoBezarius merged 1 commit intoNixOS:masterfrom
Conversation
|
Could you provide with the failed NixOS test so we can maybe help to fix it together? |
I've gotten stuck with the basic idea of the test, since it looks like I can't just run So I guess something very basic could be: import ./make-test-python.nix {
name = "nixos-rebuild";
nodes = {
machine = { ... }: {
#
};
};
testScript = ''
machine.wait_for_unit("default.target")
# TODO create /etc/configuration.nix (+ hardward-configuration.nix?) with
# multiple specializations; make following work:
machine.succeed("nixos-rebuild switch --specialisation-name foo")
'';
} |
If I provide you with a working baseline for the test, can you write the Python script? You can check |
|
I know how those tests work in general (and I've written a few before), I'm just having a problem with this particular setup - so if you manage to provide some foundation, I should be able to work on that 🙂 |
I think the magic you're looking for is nixpkgs/nixos/tests/installer.nix Lines 286 to 287 in ead8d4e |
|
Okie, thanks, I'll look into it 🙂 |
|
Okie, I've changed The test still needs a minor clean-up (I've just copy-pasted |
|
kk, test minimized 🙂 |
|
@ofborg test nixos-rebuild-specialisations |
|
The aarch64 failure seems unrelated to this PR. |
|
@Patryk27 I think this PR is good to go, there's some style changes to be done on it (trailing whitespace), can I let you take care of them? |
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 NixOS#174065
|
Oh my, fixed! 😇 |
|
Would it be possible to make |
|
On the top of my head, I think it should be possible; I myself have no time to prepare such change now, though 😢 |
|
When passing a specialisation that doesn't exist, there is a lack of error message: |
Hi, I'd like to nominate myself - I've been submitting pull requests since 2020, started by packaging [netris](NixOS/nixpkgs#85382) and then went on to improving [LXD](NixOS/nixpkgs#89540), [packaging](NixOS/nixpkgs#91182) and [maintaining](https://github.com/NixOS/nixpkgs/pulls?q=author%3APatryk27+pcloud) pCloud (which, amazingly enough, required fixing a bug in [patchelf](NixOS/patchelf#544) itself!), and overall I've been implementing various quality of live improvements [here](NixOS/nixpkgs#207466) and [there](NixOS/nixpkgs#354755). I've given [a talk about my Nix-driven blog](https://www.youtube.com/watch?v=_7wqXN-7ebw&t=6695s) during NixCon 2024 in Berlin, so it's possible we've already met irl! Outside of Nix, I'm the maintainer of Rust's [AVR backend](rust-lang/rust#131651), with commits and merging rights to [LLVM](https://github.com/llvm/llvm-project/pulls?q=author%3APatryk27) - just adding as an extra "in case it helps" mention 😇 Couple of weeks ago I decided to shift my priorities from working on custom projects to helping the communities I'm a part of more - having committer access to nixpkgs would allow me to make a greater impact as I intend to focus on reviewing and merging both ongoing and stale pull requests, since it seems there's always not enough people willing to review stuff! Thanks, Patryk :-)
Description of changes
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:
foo,nixos-rebuild switch,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-systemcontaining the specialisation's name (whichnixos-rebuildcould 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 #174065
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes