Right now, running `nixos-rebuild switch` in a remote system via SSH may
put the system in an unusable state by restarting services (e.g.:
network ones like systemd-networkd.service) during the update. This will
cause the SSH to lose access to the TTY, stopping the process entirely.
This commit wraps up the call to `switch-to-configuration` inside a
systemd-run call, making the switch resiliant against TTY loss, since it
will allocate its own TTY. For the user this should be entirely
transparent though, with the only visible change is that the
`switch-to-configuration` messages will be logged through journalctl
(e.g.: `journalctl -u nixos-rebuild-switch-to-configuration`).
Add new command `nixos-rebuild list-generations`. It will show an output
like
```
$ nixos-rebuild list-generations
Generation Build-date NixOS version Kernel Configuration Revision Specialisations
52 (current) Fri 2023-08-18 08:17:27 23.11.20230817.0f46300 6.4.10 448160aeccf6a7184bd8a84290d527819f1c552c *
51 Mon 2023-08-07 17:56:41 23.11.20230807.31b1eed 6.4.8 99ef480007ca51e3d440aa4fa6558178d63f9c42 *
```
This also mentions the change in the upcoming release notes
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
This is a followup of #148921, to allow local builds when
`--target-host` is used again. It also documents the change in
behavior, regarding the specialty of the `localhost` value.
By removing the special handling of an empty `buildHost` and non empty
`targetHost`, this change also slightly alters the behavior of
`nixos-rebuild`.
Originally by specifying `--target-host target --build-host ""`, the
now removed special case would transform those arguments to
`--target-host target --build-host target`.
Now the empty `--build-host` would result in a local build.
Multiple arguments make no sense but they are accepted, the last one
winning.
Found editing a previous run from shell history and adding a command
rather than replacing it; observe in verbose mode:
```
$ nixos-rebuild dry-run -v
building the system configuration...
Building in legacy (non-flake) mode.
No --build-host given, running nix-build locally
$ nix-build <nixpkgs/nixos> -A system -k -I nixpkgs=/home/kn/src/nixpkgs -v --dry-run
...
```
```
$ nixos-rebuild dry-run build -v
building Nix...
$ nix-instantiate <nixpkgs/nixos> --add-root /tmp/nixos-rebuild.jgEYqZ/nix.drv --indirect -A config.nix.package.out -I nixpkgs=/home/kn/src/nixpkgs -v
...
```
nixos-rebuild(8) already bails out on zero arguments, so do the same
when passing a second one.
When a NixOS system uses flakes, i.e., /etc/nixos/flake.nix exists, it
is impossible to use nixos-rebuild to build a pre-flake
configuration.nix. Of course, one can directly use nix command to
build the configuration, but not everybody remembers the correct nix
options to do that.
With the new option, it is possible to build a pre-flake configuration
with command like this:
nixos-rebuild build-vm -I nixos-config=./vm.nix --no-flake
The option might be useful for people following older pre-flake
tutorials on a flake-based system.
--quiet decreases the logging verbosity level (inverse of -v)
--print-build-logs prints build logs on stderr (same as -L)
Also reordered and grouped some options for consistency
When something changes in nixos-rebuild, we must make sure the
installers still work, otherwise it might break existing setups.
The installer tests check whether nixos-rebuild works, so they are a
good lithmus test.
nixos-rebuild would forward all verbose flags to nix, but not actually
increase its own verbosity.
Which would make it hard to see what’s going on without resorting to
tools like strace or adding `set -x` to the script.
We add a simple exec wrapper around the most “interesting” commands,
that is nix tool invocations. If any verbosity flag is given, it will
set the verbosity flag of the nixos-rebuild script all commands
wrapped into `runCmd` will start logging their invocation.
This is done via a `logVerbose` function, which can also be used to
print logging messages when in verbose mode, to aid debugging why
nixos-rebuild does what it does. A few messages are added, but
potentially we could log a lot more details.
Now, testing all of the changed code paths turns out to be rather
hard, so I am unsure how to verify that for all changed commands
behaviour stays indeed the same.
The removed lines converted the flake path passed by the command line
from `/some/path` to `git+file:///some/path`.
This technically shouldn't cause any issues, however running
`nixos-rebuild switch` inside a directory `/nix/store` will cause the
switch to fail and leave a partially construct generation (see issue #144811
for details).
By itself this shouldn't be too much of an issue, however thanks to
another issue in `systemd-boot-builder.py` this can leave the system
in a broken state for those using `boot.loader.systemd-boot` (AFAIK the
default), where future `nixos-rebuild switch` will fail
(see issue #93694 for details).
The issue can be fixed by running
`nix-env -p /nix/var/nix/profiles/system --delete-generations old`,
however this makes newbies very confused and it is showing in our
support threads in Matrix and Discourse (see
https://discourse.nixos.org/t/need-help-on-failure-of-building-my-configuration/16842).
Keep in mind this is a workaround. The actual issue seems to be in nix
itself (see: https://github.com/NixOS/nix/issues/5510).
See also #150065 for an alternative fix that caused other issues.
Kudos for @figsoda for figuring out this fix.
nixos-rebuild relies on setting an environment variable to change
behaviour during nixos-rebuild boot/switch between calling update or
install via systemd bootctl. Adding sudo -- as a prefix to various exec
calls does not preserve the environment breaking this mechanism.
This is a some what ugly fix that works.
Closes https://github.com/NixOS/nixpkgs/pull/144429
Previously when doing a nixos-rebuild build-vm we see a message saying how to
run the VM, but with nixos-rebuild build-vm-with-bootloader we did not. We
now show it in both cases.
Without this, failure of nixBuild() and nixFlakeBuild() was ignored
(since bash doesn't inherit 'set -e' in subshells by default), so the
script would proceed with a bogus ./result link, e.g.
++ readlink -f /tmp/nixos-rebuild.NfHKxx/result
+ pathToConfig='/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix
/tmp/nixos-rebuild.NfHKxx/result'
+ '[' test = switch -o test = boot ']'
+ copyToTarget '/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix
/tmp/nixos-rebuild.NfHKxx/result'
+ '[' '' = '' ']'
+ '[' test = switch -o test = boot -o test = test -o test = dry-activate ']'
+ targetHostCmd /nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix /tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration test
+ '[' -z '' ']'
+ sudo -- /nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix /tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration test
error: '/tmp/nixos-rebuild.NfHKxx/result/bin/switch-to-configuration' is not a recognised command
Try '/nix/store/m7dvk6an18cpr95qn5wnig2600qhv6w7-nix-2.4pre20210727_706777a/bin/nix --help' for more information.
+ echo 'warning: error(s) occurred while switching to the new configuration'
warning: error(s) occurred while switching to the new configuration
Currently fails with:
$ nixos-rebuild test --target-host myhost --use-remote-sudo
building Nix...
sudo: /run/current-system/sw/bin/sudo must be owned by uid 0 and have the setuid bit set
It seems setting an explicit PATH in the ssh command overrides the
remote setuid wrappers.
Prior to #119540, the toplevel output was built
locally then pushed to the remote host when using
the command:
nixos-rebuild --flake <flake> --target-host remote.host
However, buildHost would default to targetHost when
only --target-host was supplied. This caused the .drv
closure to always be transferred unless --build-host=localhost
is supplied.
This change restores the previous build local default behavior.
TargetHost can still build the outputs, if explicitly mentioned:
nixos-rebuild --flake <flake> \
--target-host remote.host \
--build-host remote.host
There is no logical reason for --fast to imply --show-trace, and this
seems to be a historical accident. Using --show-trace by default is
bad UX since it can give very long error messages (e.g. 550 lines for
a non-existent attribute in environment.systemPackages).
