using freeform is the new standard way of using modules and should replace
extraConfig.
In particular, this will allow us to place a condition on mails
* With the upgrade to waydroid to 1.2.0, dependencies that previously
were shipped in the service's path have been moved to the waydroid
package.
* Make sure /var/lib/misc exists when starting waydroid. As required
by dnsmasq
While doing kernel development with the nixos testing infrastructure, it
is useful to quickly compile the kernel on the side and boot it in the testing VM.
This patch allows overriding the kernel through the environment
variable. For example, the following:
$ NIXPKGS_QEMU_KERNEL_testvm=$LINUX_SRC/arch/x86/boot/bzImage $VM/bin/nixos-test-driver
runs testvm testing VM with the fresh kernel compiled in $LINUX_SRC.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
As a novice to using this module, I found the existing description to be
quite misleading. It does not at all disable pulling from the registry,
it just loads some image archive that may or may not be related to the
container you're specifying. I had thought there was extra magic behind
this option, but it's just a `docker load`. You need foreknowledge of
the contents of the archive so that whatever it contained is actually
used to run the container.
I've reworded the description to hopefully make this behavior clearer.
LXC containers like those used by VPSAdminOS might want to install a bootloader
so passing `true` to `system.build.installBootLoader` without any priority specified,
causes a conflict for such systems with the recent `system.build` changes:
4014fb6a64
Fixes: https://github.com/NixOS/nixpkgs/issues/155839
link to search.nixos.org instead of pulling package metadata out of pkgs. this
lets us cache docs of a few more modules and provides easier access to package
info from the HTML manual, but makes the manpage slightly less useful since
package description are no longer rendered.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
by default a ps/2 keyboard input is used which seems to cause issues
on aarch64-linux when the machine is used high load, causing the keymap
qwertz test to always fail and azerty to sometimes fail
See https://github.com/NixOS/nixpkgs/issues/147294
some options have default that are best described in prose, such as
defaults that depend on the system stateVersion, defaults that are
derivations specific to the surrounding context, or those where the
expression is much longer and harder to understand than a simple text
snippet.
the default hasn't been changed since 2009
this can improve our test performances
nixos/tests: remove explicit memorySize <1024
1024MiB is now the default
Since e791519f0f ("nixos/qemu-vm: use qemu_kvm"), VMs generated with
nixos-rebuild build-vm use the qemu_kvm package instead of the qemu
package. (The difference between them is that qemu_kvm is only built
with support for the host architecture, not all architectures.)
But with this change, nixos-rebuild build-vm would now depend on
_both_ QEMUs, because the guest agent module was still using the one
from the full QEMU package. There's no need for it to use this
instead of the lighter qemu_kvm, because the guest agent shouldn't be
affected by which platforms QEMU can emulate.
The default has been unchanged for a decade. Space is cheaper and
software catches up with that. Let's not make our testing harder
than necessary by default.
qemu_kvm is only built for one architecture, so it's smaller and takes
MUCH less time to build if it has to be built from source. And this
module doesn't support running a VM for one architecture from another
architecture, so the one architecture is all we'll need.
pathsInNixDB isn't a very accurate name when a Nix store image is
built (virtualisation.useNixStoreImage); rename it to additionalPaths,
which should be general enough to cover both cases.
Add the `useNixStoreImage` option, allowing a disk image with the
necessary contents from the Nix store to be built using
make-disk-image.nix. The image will be mounted at `/nix/store` and
acts as a drop-in replacement for the usual 9p mounting of the host's
Nix store.
This removes the performance penalty of 9p, drastically improving
execution speed of applications which do lots of reads from the Nix
store. The caveats are increased disk space usage and image build
time.
The headless option broke with 7d8b303e3f
because the path /bin/vmware-user-suid-wrapper does not exist in the
headless variant of the open-vm-tools package.
Since the vmblock fuse mount and vmware-user-suid-wrapper seem to only
be used for shared folders and drag and drop, they should not exist in
the vmware-guest module if it is configured as headless.
Move all `virtualisation.libvirtd.qemu*` options to a
`virtualisation.libvirtd.qemu` submodule.
Also for consistency, add `virtualisation.libvirtd.qemu.swtpm.package`
(only new option during this refactor.)
I realized quite recently that running a test VM - as documented in the
manual - like
QEMU_NET_OPTS='hostfwd=tcp::8080-:80' ./result/bin/nixos-run-vms
doesn't work anymore on `master`. After bisecting I realized that the
introduction of a forward-port option[1] is the problem since it adds a
trailing comma even if no forwarding options are specified via
`virtualisation.forwardPorts`. In that case, the networking options
would look like `-netdev user,id=user.0,,hostfwd=tcp::8080-:80' which
confused QEMU and thus the VM refused to start.
Now, the trailing comma is only added if additional port forwards are
specified declaratively.
[1] b8bfc81d5b
The current name is misleading: it doesn't contain cli arguments,
but several constants and utility functions related to qemu.
This commit also removes the use of `with import ...` for clarity.
Introduce an AWS EC2 AMI which supports aarch64 and x86_64 with a ZFS
root.
This uses `make-zfs-image` which implies two EBS volumes are needed
inside EC2, one for boot, one for root. It should not matter which
is identified `xvda` and which is `xvdb`, though I have always
uploaded `boot` as `xvda`.
iptables is currently defined in `all-packages.nix` to be
iptables-compat. That package does however not contain `ethertypes`.
Only `iptables-nftables-compat` contains this file so the symlink
dangles.
Both networking.nat.enable and virtualisation.docker.enable now want to
make sure that the IP forwarding sysctl is enabled, but the module
system dislikes that both modules contain this option.
Realistically this should be refactored a bit, so that the Docker module
automatically enables the NAT module instead, but this is a more obvious
fix.
Changed the startup timeout from 15 seconds to one minute as 15 seconds is really low.
Also it's currently not possible to change it without editing your system configuration.
This is analogous to #70447 and #76487.
These are all needed to attach a container to the default bridge
network, without which the final line of the following script fails with
the error for each respective kernel module listed below.
```sh
lxc storage create foo dir
lxc launch -s foo ubuntu:trusty bar
lxc network attach lxdbr0 bar
```
veth
----
> Error: Failed to start device 'lxdbr0': Failed to create the veth interfaces vethefbc3cd6 and vetha4abbcbc: Failed to run: ip link add dev vethefbc3cd6 type veth peer name vetha4abbcbc: RTNETLINK answers: Operation not supported
iptable_mangle
--------------
> lvl=eror msg="Failed to bring up network" err="Failed to list ipv4 rules for LXD network lxdbr0 (table mangle)" name=lxdbr0
xt_comment
----------
> lvl=error msg="Failed to bring up network" err="Failed to run: iptables -w -t filter -I INPUT -i lxdbr0 -p udp --dport 67 -j ACCEPT -m comment --comment generated for LXD network lxdbr0: iptables v1.8.4 (legacy): Couldn't load match `comment':No such file or directory\n\nTry `iptables -h' or 'iptables --help' for more information." name=lxdbr0
xt_MASQUERADE
-------------
> vl=eror msg="Failed to bring up network" err="Failed to run: iptables -w -t nat -I POSTROUTING -s 10.0.107.0/24 ! -d 10.0.107.0/24 -j MASQUERADE -m comment --comment generated for LXD network lxdbr0: iptables v1.8.4 (legacy): Couldn't load target `MASQUERADE':No such file or directory\n\nTry `iptables -h' or 'iptables --help' for more information." name=lxdbr0
systemd-nspawn can react to SIGTERM and send a shutdown signal to the container
init process. use that instead of going through dbus and machined to request
nspawn sending the signal, since during host shutdown machined or dbus may have
gone away by the point a container unit is stopped.
to solve the issue that a container that is still starting cannot be stopped
cleanly we must also handle this signal in containerInit/stage-2.
