Most nixos-rebuild commands support a relative flake path, however
`repl` uses `builtins.getFlake` and that requires an absolute path. So
ensure we pass an absolute path to it, providing UX consistency. Only do
so when the path exists in order to passthrough URLs as-is.
pkgs.lib and lib need not match, so prefer the one that the modules get.
For example:
```nix
nix-repl> :lf nixpkgs
nix-repl> (lib.nixosSystem { modules = [ ({ lib, ... }: assert lib?nixosSystem; { nixpkgs.hostPlatform = "x86_64-linux"; }) ]; }).pkgs.lib?nixosSystem
false
```
The code is backwards compatible, for the case where you evaluate a
config whose nixpkgs doesn't have the preceding commit yet.
This solves again the problem solved by 09fd207cb8.
To quote:
> We always want to use `ssh -t` to force PTY allocation as there may be
> interactive SSH prompts like trusting unknown hosts.
However, the creation of a pseudoterminal causes the remote stdout and stderr
to point to the same tty, resulting in a single stream in the ssh client,
which breaks other usages of ssh, such as `--build-host`.
Hence, this commit only sets the flag for invocations that need it -
or would need it if sudo were disabled. That should help with development
and gives a somewhat more consistent user experience.
Apologies to the non-flake users; your repl isn't quite as fancy,
but at least evaluates your config exactly as you would expect,
unlike flakes which are only evaluated impurely for now.
This is a hint that mentions the feature #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
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.
