The submodule of the "docker-containers" option isn't recognized as a
proper submodule and thus neither properly type-checks nor are its
options included in the manual.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by a02bb00156.
The fix is done by disabling writableStore, because the latter will set
up an overlayfs on the Nix store within the VM, which in turn will
discard all the outputs of the resulting output path.
However in runInMachine we actually *want* the contents of the generated
path and also don't want a writable store within the VM (except of
course for $out, which is writable anyway).
I've added a small regression test to verifify the output in
nixos/tests/run-in-machine.nix to make sure this won't break again in
the future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 801c920e95.
Since then, the btrfsSimple subtest of the installer VM test fails with:
Btrfs did not return a path for the subvolume at /
The reason for this is that the output for "btrfs subvol show" has
changed between version 4.8.2 and 4.13.1.
For example the output of "btrfs subvol show /" in version 4.8.2 was:
/ is toplevel subvolume
In version 4.13.1, the output now is the following and thus the regular
expressions used in nixos-generate-config.pl and install-grub.pl now
match (which results in the error mentioned above):
/
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 287270
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
In order to fix this I've changed nixos-generate-config.pl and
install-grub.pl, because both use "btrfs subvol show" in a similar vein,
so the regex for parsing the output now doesn't match anymore whenever
the volume path is "/", which should result in the same behaviour as we
had with btrfs-progs version 4.8.2.
Tested against the btrfsSimple, btrfsSubvols and btrfsSubvolDefault
subtests of the installer VM test and they all succeed now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The output of ./configure shows all modules/plugins, both enabled and
disabled. With this info we can finally build the _complete_ list of
modules. We were missing these:
mod_authn_gssapi
mod_authn_ldap
mod_geoip
(I hit this as I was building lighttpd with ldap support and the NixOS
module said ldap was unsupported, due to these missing entries in
allKnownModules.)