This reverts commit 1e534e234b.
We already should have a .git directory if it is managed via Git,
otherwise there is no way to get the Git revision if neither
.git-revision or .git is present.
But having .git-revision _and_ .git present seems very much redundant to
me.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @bennofs, @Profpatsch
Issue: #17218
This command was useful when NixOS was spread across multiple
repositories, but now it's pretty pointless (and obfuscates what
happens, i.e. "git clone git://github.com/NixOS/nixpkgs.git").
- Enforce that an option declaration has a "defaultText" if and only if the
type of the option derives from "package", "packageSet" or "nixpkgsConfig"
and if a "default" attribute is defined.
- Enforce that the value of the "example" attribute is wrapped with "literalExample"
if the type of the option derives from "package", "packageSet" or "nixpkgsConfig".
- Warn if a "defaultText" is defined in an option declaration if the type of
the option does not derive from "package", "packageSet" or "nixpkgsConfig".
- Warn if no "type" is defined in an option declaration.
Allow usage of list of strings instead of a comma-separated string
for filesystem options. Deprecate the comma-separated string style
with a warning message; convert this to a hard error after 16.09.
15.09 was just released, so this provides a deprecation period during
the 16.03 release.
closes#10518
Signed-off-by: Robin Gloster <mail@glob.in>
This commit adds the options --build-host and --target-host to nixos-rebuild.
--build-host instructs nixos-rebuild to perform all nix builds on the
specified host (via ssh). Build results are then copied back to the
local machine and used when activating the system.
--build-target instructs nixos-rebuild to activate the configuration
not on the local machine but on the specified remote host. Build
results are copied to the target machine and then activated there (via ssh).
It is possible to combine the usage of --build-host and --target-host,
in which case you can perform the build on one remote machine and deploy
the configuration to another remote machine. The only requirement is that
the build host has a working ssh connection to the target host (if the
target is not local), and that the local machine can connect to both
the target and the build host. Also, your user must be allowed to copy
nix closures between the local machine and the target and host machines.
At no point in time are the configuration sources (the nix files) copied
anywhere. Instead, nix evaluation always happens locally
(with nix-instantiate). The drv-file is then copied and realised remotely
(with nix-store).
As a convenience, if only --target-host is specified, --build-host is
implicitly set to that host too. So if you want to build locally and deploy
remotely you have to explicitly set "--build-host localhost".
To activate (test, boot or switch) you need to have root access to the
target host. You can specify this by "--target-host root@myhost".
I have tested the obvious scenarios and they are working. Some of the
combinations of --build-host and --target-host and the various actions might
not make much sense, and should maybe be forbidden (like setting a remote
target host when building a VM), and some combinations might not work at all.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
I needed to add sdhci_acpi and mmc_block to my initrd modules in order to boot
my Chromebook. Looking under /sys/class/mmc_host/*/device/driver/module will
give us the sdhci_acpi dependency.
This makes the firmware available (or would, if someone switched off
enableAllFirmware). Corresponding kernel module should get auto-loaded.
See #9948. Close#9971.
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>
‘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>
The NixOS manual says modules have the following signature:
{ config, lib, pkgs, ... }:
But our generated configuration.nix file lacks the 'lib' part. Add it.
The host id value gets generated by reading a 32-bit value from
/dev/urandom.
This makes programs that rely on a correct host id more reliable.
It also makes using ZFS more seamless, as you don't need to configure
the hostId manually; instead, it becomes part of your config from the
moment you install NixOS.
This reverts commit 469f22d717, reversing
changes made to 0078bc5d8f.
Conflicts:
nixos/modules/installer/tools/nixos-generate-config.pl
nixos/modules/system/boot/loader/grub/install-grub.pl
nixos/release.nix
nixos/tests/installer.nix
I tried to keep apparently-safe code in conflicts.
On some non-NixOS systems (for example those using "resolvconf"),
/etc/resolv.conf is a symlink. So let's dereference when copying hasts
and resolv.conf.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
An escape char is needed to prevent "$ nix" from being evaluated and
expanded to an empty string. With this change the resulting text is
$ nix-env -qaP | grep wget
instead of
-env -qaP | grep wget
"nixos-install --chroot" runs a command (by default a login shell) in
a chroot inside the NixOS installation in /mnt. This might useful for
poking around a new installation.
Dmidecode fails in our EFI test with the error "SMBIOS entry point
missing". But we don't need dmidecode because we have already have
systemd-detect-virt.
Fixes#2379.
The new name was a misnomer because the values really are X11 video
drivers (e.g. ‘cirrus’ or ‘nvidia’), not OpenGL implementations. That
it's also used to set an OpenGL implementation for kmscon is just
confusing overloading.
Previously, if the currently installed Nix is too old to evaluate
Nixpkgs, then nixos-rebuild would fail and the user had to upgrade Nix
manually. Now, as a fallback, we run ‘nix-store -r’ to obtain a binary
Nix directly from the binary cache.
This allows doing any necessary actions that were not in the installed
nixos-rebuild (such as downloading a new version of Nix). This does
require us to be careful that nixos-rebuild is backwards-compatible
(i.e. can run in any old installation).
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
We don't want to hardcode configuration options that the current kernel chose
for us when mounting the filesystem, since the defaults can change in the
future.
IIUC, <nixos> is going to be deprecated someday in the future, and as
most of those references are already replaced I guess it's safe to
replace it here as well, as it is only relevant on new/updated
installations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's already set in hardware-configuration.nix so this just confuses
people.
Also get rid of boot.initrd.kernelModules, since
hardware-configuration.nix is supposed to figure that out as well.
Commit 31203732b3 dropped the reference to
<nixos> from NIX_PATH (nixos/modules/programs/environment.nix) and thus
prevents systems that are not using channels from rebuilding.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So, we get the old behaviour of nixos-hardware-scane if we run the
following command:
nixos-generate-config --no-filesystems --show-hardware-config
This allows to use scripts in order to fetch NixOS specific hardware
information, without the need to duplicate code elsewhere.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The attributes swapDevices and imports add a space character after the
eqals sign, which is unnecessary. I know, I'm a pedantic douche bag but
it hurts my eyes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is to get back the old behavior of nixos-hardware-scan, which
didn't include fileSystems and swapDevices.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If this option is given, nixos-generate-config will write the
configuration to /etc/nixos under the given root, and only emit
fileSystems attributes for filesystems under the given root directory.
The typically use case is at installation time, where you can say:
$ nixos-generate-config --root /mnt
which will create /mnt/etc/nixos/{configuration.nix,hardware-configuration.nix}.
Also add a --force flag to force overwriting configuration.nix.
Having configuration.nix generation hidden underneath nixos-option
never made sense, also given that there was another command to
generate part of the configuration (nixos-hardware-scan). Now
nixos-generate-config produces both configuration.nix and
hardware-configuration.nix. The latter is overwritten while the
former is not.
