@k0kada thanks for the great work. I’m using it since several weeks without any issues remote building for different machines with different architectures. Especially just having to provide the sudo password once increases efficiency a lot.
3 Likes
Worth noting that while this was sub optimal in that scenario, it is quite optimal in the scenario where you have an admin machine able to (temporarily) access both builder and destination, but network segmentation means they cannot access one-another.
5 Likes
So a few weeks after release 25.05 the amount of bug reports was surprisingly small, so I think we should make nixos-rebuild-ng the default in release 25.11 as soon as possible so we can iron any last remaining issues: nixos-rebuild-ng: enable by default by thiagokokada · Pull Request #415640 · NixOS/nixpkgs · GitHub.
24 Likes
Thanks for seeing this through to the end @k0kada!
1 Like
I’ve been using this since the 25.05 release, both locally and with a remote target, and I haven’t noticed anything not working, FWIW.
1 Like
Feature request: could nixos-rebuild-ng implement auto-rollback for remote deployments? By that I mean: after a remote deployment, the remote machine becomes inaccessible from ssh, it should automatically rollback.
2 Likes
This looks more of a feature for switch-to-configuration than nixos-rebuild. And what I mean by that is by the time nixos-rebuild loses connection to the remote host there is nothing it can do, however since switch-to-configuration actually runs in the target host it could have a timeout parameter that rollbacks the configuration (you would need to have some test for network connectivity though).
2 Likes
That’s a valid point, although it would be impossible for switch-to-configuration to tell if it’s executed remotely. If it’s locally executed, it shouldn’t care if it breaks networking.
nixos-rebuild however do have this information, and even though by the time it loses connection to the remote host there is nothing it can do, I wonder if it makes sense for it to start a systemd unit that listens before it loses the connection, and make the deploying machine connects to it after activation has done. If that unit doesn’t get a connection after a certain amount of time, it should rollback automatically.
1 Like
It is not impossible for switch-to-configuration to know if it is executed remotely. We could just pass this via an environment variable or an additional argument to switch-to-configuration.
nixos-rebuildhowever do have this information, and even though by the time it loses connection to the remote host there is nothing it can do, I wonder if it makes sense for it to start a systemd unit that listens before it loses the connection, and make the deploying machine connects to it after activation has done. If that unit doesn’t get a connection after a certain amount of time, it should rollback automatically.
PRs are welcome, but I still think this functionality makes more sense in switch-to-configuration.
Howdy,
i have recently tried enabling nixos-rebuild-ng as it is going to be default in the next release, Though having an issue when adding and running nixos rebuild as it complains:
warning: Git not found: cannot figure out revision of '/nix/store/ng0wvv11id68mqf1cb2a3223gfyps4hf-nixos-25.05/nixos'
i am using a legacy configuration.nix build system with no global flakes.
here is a link to the configuration.nix i use: configuraation.nix - Pastebin.com
Wasn’t this already fixed in [Backport release-25.05] nixos-rebuild-ng: do not resolve Flake by nixpkgs-ci[bot] · Pull Request #423283 · NixOS/nixpkgs · GitHub (stable) / nixos-rebuild-ng: do not resolve Flake by thiagokokada · Pull Request #422971 · NixOS/nixpkgs · GitHub (unstable)? You sure you have your channels updated?
i have refreshed channels a few times since getting this error. how do i check what commit my channels are at?
EDIT: ran nix-info and i am on nixos-25.05.806427.32a4e80794210
EDIT2: also checked the revision of nixos-25.05 and the svn-revision is .806427.32a4e8794210
This warning is self describing, your current configuration has no git installed and legacy configurations use it to get the revision.
It is not hugely important though so you can ignore (this is why this is a warning), or just add git to your config.
alright, i thought git was only required if using a flake based system.
Is the plan for this to go live like this? I mean the point of nix/nixos is to not have to care about this kind of thing? Why doesn’t nixos-rebuild-ng depend on git if it depends on git?
It doesn’t depend on it, but it can use it if it’s available and the user is using a git repository to manage the nix config.
1 Like
No, that’s not the point of NixOS. The point is a distro based on nix’s concept of correct deployments.
nixos-rebuild has always behaved different in the presence of a git repo.
nixos-rebuild:
vs nixos-rebuild-ng:
There’s even an issue from 5 years ago from a user who was confused by the warning:
And we don’t bundle git by default because people complain about how big it is.
EDIT: discussion found - Feedback wanted: Enable git by default · Issue #325924 · NixOS/nixpkgs · GitHub
2 Likes
Silly me, I didn’t realise that correctly deployed software spits out warnings about missing dependencies. I’ll write that down to make sure I remember it.
I hadn’t noticed this. That’s fair.
If it doesn’t depend on it, and it isn’t necessary for it to function correctly imo, a warning log is the wrong log. Now, I will grant that I didn’t realise this was also the previous behaviour.
I’ll see if I can find some time this weekend to open an MR discussing removing the warning log. I’d personally demote it to debug, but info I could also see.
1 Like
We don’t have a good concept of optional dependencies in NixOS. If you want to improve the situation, do so.
Anyway, turns out there was an existing PR to try to get git into the installer ISOs but it stalled. So, here’s a followup to try to get this moving again.
1 Like
That’s true. We could do with some kind of a module system, with options.