With 'set 3 boot on' the error 'file system "/boot" is not a FAT EFI
system partition (ESP) file system' occurs when running
"nixos-install" during the basic installation (tested in in a
VirtualBox VM).
Keeping the VM state test across several run sometimes lead to subtle
and hard to spot errors in practice. We delete the VM state which
contains (among other things) the qcow volume.
We also introduce a -K (--keep-vm-state) flag making VM state to
persist after the test run. This flag makes test-driver.py to match
its previous behaviour.
Enhance the heuristics to make sure that a user doesn't accidentally
upgrade across two major versions of Nextcloud (e.g. from v17 to v19).
The original idea/discussion has been documented in the nixpkgs manual[1].
This includes the following changes:
* `nextcloud19` will be selected automatically when having a stateVersion
greater or equal than 20.09. For existing setups, the package has to
be selected manually to avoid accidental upgrades.
* When using `nextcloud18` or older, a warning will be thrown which recommends
upgrading to `nextcloud19`.
* Added a brief paragraph about `nextcloud19` in the NixOS 19.09 release
notes.
* Restart `phpfpm` if the Nextcloud-package (`cfg.package`) changes[2].
[1] https://nixos.org/nixos/manual/index.html#module-services-nextcloud-maintainer-info
[2] https://github.com/NixOS/nixpkgs/pull/89427#issuecomment-638885727
Specifying mailboxes as a list isn't a good approach since this makes it
impossible to override values. For backwards-compatibility, it's still
possible to declare a list of mailboxes, but a deprecation warning will
be shown.
Since cd1dedac67 systemd-networkd has it's
netlink socket created via a systemd.socket unit. One might think that
this doesn't make much sense since networkd is just going to create it's
own socket on startup anyway. The difference here is that we have
configuration-time control over things like socket buffer sizes vs
compile-time constants.
For larger setups where networkd has to create a lot of (virtual)
devices the default buffer size of currently 128MB is not enough.
A good example is a machine with >100 virtual interfaces (e.g.,
wireguard tunnels, VLANs, …) that all have to be brought up during
startup. The receive buffer size will spike due to all the generated
message from the new interfaces. Eventually some of the message will be
dropped since there is not enough (permitted) buffer space available.
By having networkd start through / with a netlink socket created by
systemd we can configure the `ReceiveBufferSize` parameter in the socket
options without recompiling networkd.
Since the actual memory requirements depend on hardware, timing, exact
configurations etc. it isn't currently possible to infer a good default
from within the NixOS module system. Administrators are advised to
monitor the logs of systemd-networkd for `rtnl: kernel receive buffer
overrun` spam and increase the memory as required.
Note: Increasing the ReceiveBufferSize doesn't allocate any memory. It
just increases the upper bound on the kernel side. The memory allocation
depends on the amount of messages that are queued on the kernel side of
the netlink socket.
udev gained native support to handle FIDO security tokens, so we don't
need a module which only added the now obsolete udev rules.
Fixes: https://github.com/NixOS/nixpkgs/issues/76482
This fixes the output of "hostname --fqdn" (previously the domain name
was not appended). Additionally it's now possible to use the FQDN.
This works by unconditionally adding two entries to /etc/hosts:
127.0.0.1 localhost
::1 localhost
These are the first two entries and therefore gethostbyaddr() will
always resolve "127.0.0.1" and "::1" back to "localhost" [0].
This works because nscd (or rather the nss-files module) returns the
first matching row from /etc/hosts (and ignores the rest).
The FQDN and hostname entries are appended later to /etc/hosts, e.g.:
127.0.0.2 nixos-unstable.test.tld nixos-unstable
::1 nixos-unstable.test.tld nixos-unstable
Note: We use 127.0.0.2 here to follow nss-myhostname (systemd) as close
as possible. This has the advantage that 127.0.0.2 can be resolved back
to the FQDN but also the drawback that applications that only listen to
127.0.0.1 (and not additionally ::1) cannot be reached via the FQDN.
If you would like this to work you can use the following configuration:
```nix
networking.hosts."127.0.0.1" = [
"${config.networking.hostName}.${config.networking.domain}"
config.networking.hostName
];
```
Therefore gethostbyname() resolves "nixos-unstable" to the FQDN
(canonical name): "nixos-unstable.test.tld".
Advantages over the previous behaviour:
- The FQDN will now also be resolved correctly (the entry was missing).
- E.g. the command "hostname --fqdn" will now work as expected.
Drawbacks:
- Overrides entries form the DNS (an issue if e.g. $FQDN should resolve
to the public IP address instead of 127.0.0.1)
- Note: This was already partly an issue as there's an entry for
$HOSTNAME (without the domain part) that resolves to
127.0.1.1 (!= 127.0.0.1).
- Unknown (could potentially cause other unexpected issues, but special
care was taken).
[0]: Some applications do apparently depend on this behaviour (see
c578924) and this is typically the expected behaviour.
Co-authored-by: Florian Klink <flokli@flokli.de>
