New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos:nixos-rebuild: allow switching to a specific generation number #105910
base: master
Are you sure you want to change the base?
Conversation
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
I am not sure about having Any opinions @edolstra or others? |
Many ideas for the |
Maybe this should be its own subcommand? I.e. Or alternatively, |
I totally agree with your suggestions and I was a bit unhappy with the doubling of the "switch" as well. The reason I chose it nevertheless is that I took the same flag as |
Any opinions about the |
I think it's okay to add it to |
I prepared a branch with two clean commits instead of this mess and I could use those instead. I guess it would be easier to read that way |
5e37822
to
dc528f0
Compare
dc528f0
to
3073ca2
Compare
Anyone wants to take a look and review this? |
1ab9cab
to
a0e6d87
Compare
a0e6d87
to
84f3e1f
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/2687 |
i thought that switching to specific generation is acheived by: Is this thread about adding a more convenient syntax, for example to switch to generation 5: |
Yes, I think so. This PR is equivalent to sudo nix-env --switch-generation N -p /nix/var/nix/profiles/system
sudo /nix/var/nix/profiles/system/bin/switch-to-configuration switch because that is also the way it was implemented for
Yes, I think having an easier syntax would be better than the current way (and also more discoverable, especially as soon as you add things like different profiles/specialisations).
I considered your suggested syntax, but I think it is a bit ambiguous if you want to rollback to a specific generation (as is the intention here) or a relative amount (so in your case e.g. from generation 100 to 95). That is why I thought a different syntax is more precise and it is also the one Eelco suggested: #105910 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything here makes sense/looks good to me. I too would be interested in helping @miallo pushing this forward.
ac807ee
to
c3ddde6
Compare
That would be nice! I just pushed a rebase where the only change I made was the update of the |
I'd love to see this merged, the current manpage mentions |
Oh damn... -.- That one is totally on me. I extracted the |
This is a hint that mentions the feature NixOS#105910 but that is not yet merged. This is very confusing and since it there is no progress with that merge we should remove the reference
Run `nixos-rebuild switch --generation 12345` to roll back to generation `12345`. This makes rolling back to an older generation easier Also updated the release notes.
f096884
to
8414cdd
Compare
8414cdd
to
7f9cef9
Compare
I just added some tests. This was the first time I wrote any nixos tests and so this is just an adaptation of tests/nixos-rebuild-specialisations.nix - but I don't really know if this can be simplified any more... @Mic92 @SuperSandro2000 What else do you think is necessary for this PR? @SuperSandro2000 you mentioned a few things you wanted to do in #105910 (review) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets only use one style of test at least in the changed code
Previously there was a mixture of `[` and `[[`. That is a bit unnecessary and even if there is a mixture in the rest of the code, this PR should stick to one of the versions... Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
--generation) | ||
if [ $# -eq 0 ]; then | ||
log "Must provide a generation number" | ||
log "Usage: \`$(basename "$0") ${action:-switch} --generation <NUMBER>'" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do I need to give an action when I just want to switch to a generation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't know if you want to switch, boot or test said generation, so you have to tell us what you want to do with it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but if I want to switch to an older generation, why does it start to build the current config file from disk which might be newer than the current generation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is interesting - I don't think this happened to me before 🤔 Where did you see this behavior? If it is in the tests: the first three tests don't actually do the --generation
, but they create the generations, so there it is expected that they build the config files...
I know it isn't a good answer, but: I don't really know what I am doing (at least not 3 years after I first wrote this patch). I just adapted the code for the --rollback
since I thought they would be more or less identical... I have forgotten the few things I knew about the nix-env stuff and the rest on how this is activated 🙈 If we just wanted to activate the generation and don't care about the action I guess we could also just run /nix/var/nix/profiles/system-$generation-link/activate
...
I tried to add a test for the boot --generation
, but something is strange (maybe the QEMU runs some kind of tempfs - at least after the machine.reboot()
and it doesn't have nix-channels or actually the old generations any more on the disk) and so I could only check that the current generation was still active...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not reproduce the building of the current configuration.nix in the tests, as this passes, which I think is what you mean:
diff --git a/nixos/tests/nixos-rebuild-switch.nix b/nixos/tests/nixos-rebuild-switch.nix
index b9ed2954299a..e5f3e378ad73 100644
--- a/nixos/tests/nixos-rebuild-switch.nix
+++ b/nixos/tests/nixos-rebuild-switch.nix
@@ -84,12 +84,15 @@ import ./make-test-python.nix ({ pkgs, ... }: {
with subtest("Create generation 3"):
${createConfig "3"}
- machine.succeed("nixos-rebuild switch")
+ out = machine.succeed("nixos-rebuild switch 2>&1")
+ assert "building the system configuration..." in out
${testForBootGeneration "3"}
${testForActiveGeneration "3"}
with subtest("must switch to `--generation 1`"):
- machine.succeed("nixos-rebuild switch --generation 1")
+ ${createConfig "4"}
+ out = machine.succeed("nixos-rebuild switch --generation 1 2>&1")
+ assert "building the system configuration..." not in out
${testForBootGeneration "1"}
${testForActiveGeneration "1"}
Did I misunderstand you or do you have a reproduction by any chance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well the script (re)executes itself https://github.com/NixOS/nixpkgs/blob/1860f2ab371659d417f30e9f32e242c6ce5928a5/pkgs/os-specific/linux/nixos-rebuild/nixos-rebuild.sh#L405C68-L405C75, so maybe that is why it starts building?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we just wanted to activate the generation and don't care about the action I guess we could also just run
/nix/var/nix/profiles/system-$generation-link/activate
...
Yes, this is basically what I wanted to do.
Did I misunderstand you or do you have a reproduction by any chance?
I think this is what I did, yes.
well the script (re)executes itself
I am usually passing --fast to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we just wanted to activate the generation and don't care about the action I guess we could also just run
/nix/var/nix/profiles/system-$generation-link/activate
...Yes, this is basically what I wanted to do.
I just implemented it with "feature parity" to the --rollback
. I personally mostly use switch
as an action, but maybe e.g. someone could want to set a "known good generation" as a default after a reboot when testing a server update and on error they can just do a reboot and everything should be back to normal. Could something like this be a use case (and if not, just out of curiosity: why would it be one for rollback)?
Did I misunderstand you or do you have a reproduction by any chance?
I think this is what I did, yes.
Very interesting... This should not happen (https://github.com/NixOS/nixpkgs/pull/105910/files#diff-fc23c722779993fcffc932965cd143b265aa196d577ca10173b63e5bdcbc0001R608-R609) and also the test that I wrote above passes... 🤔 I really don't have a clue how this could have happened... Anyone has any idea (or even better can add a failing test case)?
Motivation for this change
If the user wants to
rollback
to any of the system generations but the last, this is currently not easily doable (see #24374).In order to unify the interface with
nix-env
a bit more, I propose to add a flag ``nixos-rebuild --generation` to easily go to a specific generation.I had an issue, where I didn't notice a package breaking ~10 generations ago and while fixing it, I had to go back and forth multiple times. Since I didn't know about
I repeated the rollback
n
times.This implementation would make it possible to run
Maintainers
@nbp added
--rollback
@worldofpeace did the last edits
And I guess @edolstra ?
Things done