If nixos-install is run on a machine with `nix.distributedBuilds = true`
the installation will fail at some point like this:
Died at /nix/store/4frhrl31cl7iahlz6vyvysy5dmr6xnh3-nix-1.10/libexec/nix/build-remote.pl line 115, <STDIN> line 1.
This is due to `nix.distributedBuilds` setting
NIX_BUILD_HOOK=/nix/store/.../build-remote.pl in the global environment,
which then gets confused in the minimal chroot created by nixos-install.
To avoid these kinds of issues with build hooks, just disable them in
the chroot.
Avoids this warning when running `nixos-rebuild switch`:
````
building Nix...
building the system configuration...
trace: Obsolete option `services.virtualboxGuest.enable' is used. It was renamed to `virtualisation.virtualbox.guest.enable'.
````
This option requests compatibility with older NixOS releases with
respect to stateful data, in cases where new releases have defaults
that might be incompatible with system state of existing NixOS
deployments. For instance, if we change the default version of
PostgreSQL, existing deployments will break if the new version can't
read databases created by the old version.
So for example, setting
system.stateVersion = "15.07";
requests that options like services.postgresql.package use defaults
corresponding to the 15.07 release branch. Note that
nixos-generate-config emits this option. (In the future, NixOps may
set system.stateVersion to the NixOS release in use when the machine
was created.)
See also #7939 for another motivating example.
Passing the chroot flag to nixos-install without arguments should now give you a
Bash shell as intended rather than try an empty path.
This was masked by the user's shell (usually /bin/bash) being defaulted to by
chroot, and being found since their paths used NixOS conventions.
When bootstrapping from other distributions, nixos-install is unable to find
various tools in the chroot since their paths aren't aware of NixOS conventions.
This makes a small change to existing code by specifying nixpkgs/nixos instead
of just nixos when running nix-instantiate in the chroot. I haven't tested this
outside of bootstrapping, but the same specification is used elsewhere in the
code so I don't see why it wouldn't work.
This partially reverts commit 3a4fd0bfc6.
Addresses another concern by @edolstra that users might not want to
update *all* channels. We're now reverting to the old behaviour but
after updating the "nixos" channel, we just check whether the channel
ships with a file called ".update-on-nixos-rebuild" and if it exists, we
update that channel as well.
Other channels than these are not touched anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Should make it even easier to use custom channels, because whenever the
user does a "nixos-rebuild --upgrade", it will also upgrade possibly
used ("used" as in referenced in configuration.nix) channels besides
"nixos". And if you also ship a channel tied to a particular version of
nixpkgs or even remove the "nixos" channels, you won't run into
unexpected situations where the system is not updating your custom
channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The nixbld group doesn't need read permission, it only needs write and
execute permission.
(cherry picked from commit 066758758e7c0768ff8da51d208cdae0f33b368c)
‘nixos-rebuild dry-activate’ builds the new configuration and then
prints what systemd services would be stopped, restarted etc. if the
configuration were actually activated. This could be extended later to
show other activation actions (like uids being deleted).
To prevent confusion, ‘nixos-rebuild dry-run’ has been renamed to
‘nixos-rebuild dry-build’.
Since we're using HTTPS for the binary cache (introduced in faf0797) by
default, the binary cache should also be available during installation.
The file that is defined in SSL_CERT_FILE outside of the chroot is
copied over to /tmp/ca-cert.crt inside the chroot, so we have an
absolute path we can reference during nixos-install. However, this might
end up with the file not being cleaned up properly from outside of the
store, but neither would be /tmp/root so the cleanup issue needs to be
solved in another place (or commit to be more exact).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Especially new users could be confused by this, so we're now marking
services.virtualbox.enable as obsolete and defaulting to
services.virtualboxGuest.enable instead. I believe this now makes it
clear, that this option is for guest additions only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
