This moves the creation of the bind mount inside the `nixos-enter`
invocation. The command are executed in an unshared mount namespace, so
they can be run as an unprivileged user.
Although we don't really need HTML documentation in the minimal installer,
not including it may cause annoying cache misses in the case of the NixOS manual.
When installing NixOS in the target filesystem /mnt, paths relative to
configuration.nix in `initrd.secrets` are turned by Nix into absolute
paths that reference /mnt. While building the system derivation works,
installing the bootloader fails because the latter process takes place
inside the chroot environment where /mnt does not exist.
Ideally, we would also build the system within chroot, but this greatly
complicates the matter as it requires manually copying over Nix, its
runtime dependencies and all channels. Possibly, this would also break
several assumptions users have about how nixos-install works.
A simpler and safer (but less neat) solution is to temporarily bind
mount all mount points in /mnt under /mnt/mnt to keep the paths
functional while the bootloader is being installed.
This is essentially the workaround described in issue #73404.
Due to missing `/etc/machine-id` in the new root, systemd-tmpfiles
outputs a bunch of scary warnings like "Failed to replace specifiers in
'/run/log/journal/%m'". We only care about /tmp, so hide them.
`-E` is an alias for `--exclude-prefix=/dev --exclude-prefix=/proc
--exclude-prefix=/run --exclude-prefix=/sys`.
Support for ZFS, while desirable, is problematic with newer kernel
releases. The stable ZFS release seldom supports the current newest
kernel version, and this makes the new_kernel image basically useless as
it cannot be published, and is not often built with new kernel releases.
This uses a dirty workaround to work around the fact it is impossible to
remove a list item from a modules system list type. Since ZFS support is
conditional to being supported on the current platform, we can fake ZFS
not being supported *for the no-zfs build only*. This overlay is only
added when evaluating the image, nothing else.
Support for ZFS, while desirable, is problematic with newer kernel
releases. The stable ZFS release seldom supports the current newest
kernel version, and this makes the new_kernel iso basically useless as
it cannot be published, and is not often built with new kernel releases.
This uses a dirty workaround to work around the fact it is impossible to
remove a list item from a modules system list type. Since ZFS support is
conditional to being supported on the current platform, we can fake ZFS
not being supported *for the no-zfs build only*. This overlay is only
added when evaluating the iso, nothing else.
Pin the `nixpkgs` registry entry to the *filtered* nixpkgs source to
avoid copying the entire `.git` directory to the ISO when building
from a local checkout.
Also set `to` directly instead of the `flake.outPath` hack.
This is done for sd-images only here, but should probably also be done
for dvd-images.
The --invariant arg should be a better way of making mkfs.vfat deterministic.
The previous version of invoking faketime was building fine and reproducible
when I was compiling an sdimage for aarch64 under emulation.
It was however still logging errors:
ERROR: ld.so: object '/nix/store/1c2cp2709kmvby8ql2n9946v7l52nn50-libfaketime-0.9.9/lib/libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/nix/store/1c2cp2709kmvby8ql2n9946v7l52nn50-libfaketime-0.9.9/lib/libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
The logged errors were presumably inaccurate somehow as calling
faketime was required for reproducibility, even though the log makes it
looks like it failed.
Within #193485 (and the previous changes) the internal structure of the
testing driver was changed. Since then, `makeTest` returns the
attributes for the VM test(s) (including `driverInteractive`) inside a
sub-attribute called `test`, so without this change running
`nixos-build-vms` would fail like this:
error: attribute 'driverInteractive' missing
Move already implemented functionality to the upper level so
it could be used in a more generic way.
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>