There are a bunch of components such as incus or LXC that also use
`boot.isContainer`, so we'd have to differentiate between "OS container"
and "actually nspawn".
This became necessary for the file-systems part where nspawn takes care
of setting up special filesystems like `/proc`, `/dev` etc., but others
don't.
To allow for a `boot.isContainer` being less overloaded, this introduces
`boot.isNspawnContainer` that is exclusively used for nspawn-specific
things. When `true`, `boot.isContainer = true;` is implied.
The commit 01e8f570c6 unpinned the
LLVM version, which led to the following warnings whenever Scudo
is loaded (basically whenever a command is started when used
system-wide):
Scudo WARNING: found 3 unrecognized flag(s):
DeleteSizeMismatch=0:DeallocationTypeMismatch=0
DeallocationTypeMismatch=0
ZeroContents=1
According to the current Scudo documentation [1] the options are
now spelled differently. This commit keeps all existing options
and only updates the spelling.
[1] https://llvm.org/docs/ScudoHardenedAllocator.html
Reported-by: CUB3D <callumthom11@gmail.com>
A basic NixOS system shouldn’t require `stdenv` to install, and
it adds something like 45 MiB of build tools to the installer
closure. This doesn’t really help much at present since
WebKitGTK(?!) has a dodgy reference to GCC, but it’s a step in the
right direction.
With networkmanager we can provide a much more welcoming network setup
experience in the installer and it costs us less than 10 MB with this
configuration on the minimal ISO.
By default, for new profiles it will enable DHCP and RA and allow
interactive reconfiguration through `nmtui` or `nmcli`. Especially the
TUI interface is very easy to pick up and removes the need for typing in
manual commands when setting up the WLAN connection.
Resolution still fails when on VPN with no IPv6 DNS servers. We'll need
to investigate further why the fix doesn't help in this case.
This reverts commit f90236a8f2.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
Consider a user wanting to set up the Linux builder for the first time,
but with a slightly more generous allocation of resources compared to
the default. They'll do something like this:
```
{
virtualisation.cores = 3;
virtualisation.darwin-builder = {
diskSize = 40 * 1024;
memorySize = 4 * 1024;
};
}
```
This will fail with an error like this:
```
error: a 'aarch64-linux' with features {} is required to build '/nix/store/3acpgmwqwnk8g2gc5r05ar2lvmn01b8a-builder.pl.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}
```
But why would they have to rebuild the NixOS system?! All they did was
change the arguments passed to QEMU, and nothing those options control
would affect the NixOS configuration itself... right?
`config.system.build.toplevel` is defined with `allowSubstitutes` set to
`false` by default, which makes it so that the toplevel can't be
substituted if Nix is trying to use it "directly." So because the above
example would have to rebuild the VM runner, which references toplevel
directly, Nix refuses to substitute it, unless `always-allow-substitutes
= true` is set as a Nix option. (In the case where the QEMU options
aren't changed at all, Nix just substitutes the runner, which sidesteps
this issue as the runner itself doesn't use toplevel as an input.)
The current workflow for starting the `linux-builder` on macOS is to run
`nix run nixpkgs#darwin.linux-builder`, which adds keys to the store and
then starts the builder.
Adding the keys requires user input (due to `sudo`) but the actual
builder should just stay running in the background somewhere.
I'd like to automate this process, but it's currently rather complex:
the first part of the script needs user input for `sudo`, and then
there's no signal when the process has finished starting up. The user
will need to see stdout/stderr during the first part, which makes it
challenging to capture it for the second part to determine when startup
has finished.
To fix this, I've split the `create-builder` script into an `add-keys`
script (interactive) and a `run-builder` script (background). These new
scripts are exposed in the `passthru` attributes for external users. The
`create-builder` script is now a simple call of `add-keys` and then
`run-builder`.
See: https://nixos.org/manual/nixpkgs/unstable/#sec-darwin-builder
libslirp DNS issues on MacOS are now fixed. The override to use 8.8.8.8
as DNS server for linux-builder is not needed anymore.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
