A remote builder does not need to evaluate anything, so let's trim
it down to (eventually) save some space, and make the purpose of
the builder clear.
Users should evaluate on the host instead.
Yama is a LSM which restricts debugging. This prevents processes from
snooping on another. It can be easily disabled with sysctl.
This was initially included in #14392 and disabled by default by
86721a5f78.
This has been part of the hardened configuration, but many other distros
ship this for quite some time (Ubuntu for about ten years), so I'd say
it might make sense to enable this per default.
I chose not to do nixos.{config, options} because that would make it
look too much like a configuration object, which it is not.
A configuration object I would define as for example the result of
calling NixOS, an attrset with `_type = "configuration";`.
Recreating a configuration object without evalModules is quite
feasible but not guaranteed to be correct, and not maintainable.
For non-interactive installation it's quite handy to be able to nix copy additional dependencies to the system.
While this is possible for the root user, we cannot easily ssh into it, as we don't allow root login with a password.
By making nixos a trusted user, we can do "passwd && sudo systemctl start sshd" and than run nixos-anywhere
swraid support will now only be enabled by default if stateVersion is
older than 23.11. nixos-generate-config will now generate explicit
config for enabling support if needed.
This is a feature useful for nixos-remote and other installation tools
that try to identify if the remote machine has been successfully booted
into an installer.
This is preferable because it prevents things like disk corruption (requiring the user to delete the disk image when starting up) that I consistently ran into.
See the discussion starting here:
https://github.com/NixOS/nixpkgs/pull/206951#issuecomment-1364760917
The `darwin.builder` derivation had a gratuitous dependency
on the current Nixpkgs revision due to
`config.system.nixos.revision`. Setting the revision explicitly
to null fixes this problem and prevents the derivation from being
rebuilt on every change to Nixpkgs.
See: https://github.com/NixOS/nixpkgs/issues/108984#issuecomment-1364263324
Before this change the supported platforms were unspecified, so
it would default to being only built on `x86_64-linux`. This
fixes that so that hydra.nixos.org builds and caches the Darwin
build products instead
Considering that you most likely edit Nix code in the installer, that
seems like a useful thing.
The size of the ISO I got from
nix-build nixos/release.nix -A iso_minimal.x86_64-linux
is still at 877M.
The `boot.zfs.enabled` option is marked `readOnly`, so this is the only way to
successfully build a NixOS installer image for platforms that zfs does not build
for.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
This is image media, so use the override level designed for it. As
detailed in the definition for mkImageMediaOverride:
> image media profiles can be derived by inclusion into host config,
> hence needing to override host config, but do allow user to mkForce
