See https://www.redhat.com/sysadmin/fedora-31-control-group-v2 for
details on why this is desirable, and how it impacts containers.
Users that need to keep using the old cgroup hierarchy can re-enable it
by setting `systemd.unifiedCgroupHierarchy` to `false`.
Well-known candidates not supporting that hierarchy, like docker and
hidepid=… will disable it automatically.
Fixes#73800
This used to be done by udev, but that was removed in
systemd/systemd@6b2229c. The links are created by systemd at the end of
stage-2, but activation scripts might need them earlier.
These were broken since 2016:
f0367da7d1
since StartLimitIntervalSec got moved into [Unit] from [Service].
StartLimitBurst has also been moved accordingly, so let's fix that one
too.
NixOS systems have been producing logs such as:
/nix/store/wf98r55aszi1bkmln1lvdbp7znsfr70i-unit-caddy.service/caddy.service:31:
Unknown key name 'StartLimitIntervalSec' in section 'Service', ignoring.
I have also removed some unnecessary duplication in units disabling
rate limiting since setting either interval or burst to zero disables it
(ad16158c10/src/basic/ratelimit.c (L16))
When the stage-1 logs get imported in to the journal, they all get
loaded with the same timestamp. This makes it difficult to identify
what might be taking a long time in early boot.
It looks like the test sshd key can never be used, because of too open
permissions. My guess is that the current test script works fine once
the user defined ssh-key has been copied into initrd.
At "nixos-install" however, the user specified host key is not present
in initrd yet and validation fails.
fixes#91486
Otherwise, stage-2-init.sh will complain about not having access to
/dev/fd/62 as of systemd v246.
On IRC, flokli said:
15:14 <flokli> cole-h: hmmm... I could imagine some of the setup inside /dev has been moved into other parts of systemd
15:14 <flokli> And given we run systemd much later (outside initramfs only) it doesn't work properly here
15:17 <flokli> We probably don't invoke udev correctly
This is a temporary fix for #97433. A more proper fix has been
implemented upstream in systemd/systemd#17001, however until it gets
backported, we are stuck with ignoring the error.
After the backport lands, this commit should be reverted.
For UEFI setups, "device" will generally be the special value "nodev"
which represents not running grub-install at all. Using "nodev" for
boot mirrors should therefore be allowed.
The commit enforces buildPackages in the builder but neglects
the fact that the builder is intended to run on the target system.
Because of that, the builder will fail when remotely building a
configuration eg. with nixops or nix-copy-closure.
This reverts commit a6ac6d00f9.
The cyclic dependency of systemd → cryptsetup → lvm2 → udev=systemd
needs to be broken somewhere. The previous strategy of building
cryptsetup with an lvm2 built without udev (#66856) caused the
installer.luksroot test to fail. Instead, build lvm2 with a udev built
without cryptsetup.
Fixes#96479.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This allows the user to configure systemd tmpfiles.d via
`environment.etc."tmpfiles.d/X.conf".text = "..."`, which after #93073
causes permission denied (with new X.conf):
```
ln: failed to create symbolic link '/nix/store/...-etc/etc/tmpfiles.d/X.conf': Permission denied
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
or collision between environment.etc and systemd-default-tmpfiles
packages (with existing X.conf, such as tmp.conf):
```
duplicate entry tmpfiles.d/tmp.conf -> /nix/store/...-etc-tmp.conf
mismatched duplicate entry /nix/store/...-systemd-246/example/tmpfiles.d/tmp.conf <-> /nix/store/...-etc-tmp.conf
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
Fixes#96755
declare -a is not sufficient to make the array variable actually
exist, which resulted in the script failing when the target object did
not have any DT_NEEDED entries. This in turn resulted in some
initramfs libraries not having their rpaths patched to point to
extra-utils, which in turn broke the extra-utils tests.
symlinkJoin can break (silently) when the passed paths contain symlinks
to directories. This should work now.
Down-side: when lib/tmpfiles.d doesn't exist for some passed package,
the error message is a little less explicit, because we never get
to the postBuild phase (and symlinkJoin doesn't provide a better way):
/nix/store/HASH-NAME/lib/tmpfiles.d: No such file or directory
Also, it seemed pointless to create symlinks for whole package trees
and using only a part of the result (usually very small part).
These are now only installed by systemd if HAVE_SYSV_COMPAT is true,
which only is the case if you set sysvinit-path and sysvrcnd-path (which
we explicitly unset in the systemd derivation for quite some time)
From the systemd release notes:
nss-mymachines lost support for resolution of users and groups, and now
only does resolution of hostnames. This functionality is now provided by
nss-systemd. Thus, the 'mymachines' entry should be removed from the
'passwd:' and 'group:' lines in /etc/nsswitch.conf (and 'systemd' added
if it is not already there).
Since systemd 246, these are only installed by systemd if
HAVE_SYSV_COMPAT is true, which only is the case if you set
sysvinit-path and sysvrcnd-path (which we explicitly unset in the
systemd derivation for quite some time)
There's a circular dependency to systemd via cryptsetup and lvm2
(systemd -> cryptsetup -> lvm2 -> udev=systemd).
However, cryptsetup only really needs the devmapper component shipped
with lvm2. So build `pkgs.cryptsetup` with a lvm2 that doesn't come with
udev.
- Give a more accurate description of how fileSystems.<name/>.neededForBoot
works
- Give a more detailed description of how fileSystems.<name/>.encrypted.keyFile
works
This lets users do sneaky things before systemd starts, and
permanently affect the environment in which systemd runs. For example,
we could start systemd in a non-default network namespace by setting
the systemdExecutable to a wrapper script containing:
#!/bin/sh
ip netns add virtual
touch /var/run/netns/physical
mount -o bind /proc/self/ns/net /var/run/netns/physical
exec ip netns exec virtual systemd
_note: the above example does literally work, but there are unresolved
problems with udev and dhcp._
Fixes error
Can't use an undefined value as an ARRAY reference at /nix/store/...-install-grub.pl line 642, <FILE> line 5.
with `/boot/grub/state` being:
```
grub
2.04
no
/dev/sda
/boot
```
I am not sure where the trailing empty line can come from; the script does not
seem to write it. In any case, now we handle that situation as well.
Further, ensure that `extraGrubInstallArgs` defaults to the empty array
if its key is not present in the `jsonState`.
For example, turns the error
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot
into the more useful
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot: Read-only file system
Useful for when you need to build grub modules into your grub kernel
to get a working boot, as shown in the added example.
To store this new value, we switch to more structural JSON approach.
Using one line per value to store in `/boot/grub/state` gets really messy when
the values are arrays, or even worse, can contain newlines (escaping would be
needed). Further, removing a value from the file would get extra messy
(empty lines we'd have to keep for backwards compatibility).
Thus, from now on we use JSON to store all values we'll need in the future.
nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs
The module in this commit adds new options that allows the
integration of an OpenVPN client into the initrd.
This can be used e.g. to remotely unlock LUKS devices.
This commit also adds two tests for `boot.initrd.network.openvpn`.
The first one is a basic test to validate that a failing connection
does not prevent the machine from booting.
The second test validates that this module actually creates a valid
openvpn connection.
For this, it spawns three nodes:
- The client that uses boot.initrd.network.openvpn
- An OpenVPN server that acts as gateway and forwards a port
to the client
- A node that is external to the OpenVPN network
The client connects to the OpenVPN server and spawns a netcat instance
that echos a value to every client.
Afterwards, the external node checks if it receives this value over the
forwarded port on the OpenVPN gateway.
This can be used to explicitly specify a specific dtb file, relative to
the dtb base.
Update the generic-extlinux-compatible module to make use of this option.
Some bootloaders might not properly detect the model.
If the specific model is known by configuration, provide a way to
explicitly point to a specific dtb in the extlinux.conf.
This option exposes the builder command used to populate an image,
honoring all options except the -c <path-to-default-configuration>
argument.
Useful to have for sdImage.populateRootCommands.
Special care needs to be taken w.r.t cross - the populate command runs
on the host platform, the activation script on the build platform (so
the builders differ)
Turns out, #75510 was too restrictive.
We also need to allow str here, as some modules set this to
"/run/wrappers" to bring `/run/wrappers/bin` into $PATH of a unit.
Upstream has this alias too; so that dbus activation works.
What I don't fully understand is why this would ever be useful given
this unit is already started way in early boot; even before dbus is up.
But lets just keep behaviour similar to upstream and then ask these
questions to upstream.
With this systemd buffers netlink messages in early boot from the kernel
itself; and passes them on to networkd for processing once it's started.
Makes sure no routing messages are missed.
Also makes an alias so that dbus can activate this unit. Upstream has
this too.
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
The way this ends up being called with the raspberry pi 4 image builder
ends up not using the `-e` from the shebang.
In turn, the builds fails during cross-compilation. The wrong coreutils
ends up being used, but this is not made apparent.
The issue I faced is already fixed on master, but this ensures no one
ends up with a failed build "succeeding".
Also, remove the dangling systemd.services.systemd-binfmt.wants = [
"proc-sys-fs-binfmt_misc.mount" ]; in systemd.nix.
If boot.binfmt.registrations != {}, systemd will install
proc-sys-fs-binfmt_misc.automount, which will auto-mount
`/proc/sys/fs/binfmt_misc` as soon as systemd-binfmt tries to access it.
Fixes https://github.com/NixOS/nixpkgs/issues/87687
Fixes https://github.com/NixOS/nixops/issues/574
A disabled nscd breaks nss module loading on NixOS, and systemd without
its nss modules doesn't really work either - instead of silently
disabling its nss modules if nscd is disabled, let the assertion in
nsswitch handle this.
nixos/modules/config/nsswitch.nix uses `passwdArray` for both `passwd`
and `group`, but when moving this into the systemd module in
c0995d22ee, it didn't get split
appropriately.
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
This reverts commit 764c8203b8.
While this is desireable in principle, some of our modules and services
fail during service startup if no network is available don't currently
properly set Wants=network-online.target.
If nothing pulls in this target anymore, systemd won't try to reach it.
We have many VM tests waiting for `network-online.target`, and after
764c8203b8 fail with the following error
message:
```
error: unit "network-online.target" is inactive and there are no pending jobs
```
Most likely, test scripts shouldn't wait for `network-online.target` in
first place (as `network-online.target` says nothing about whether a
service has been started), but instead, the script should wait for the
network ports of the corresponding service to be open.
Let's revert this for now, and re-apply in a draft PR, fixing the tests
before merging it back in.
This follows upstreams change in documentation. While the `[DHCP]`
section might still work it is undocumented and we should probably not
be using it anymore. Users can just upgrade to the new option without
much hassle.
I had to create a bit of custom module deprecation code since the usual
approach doesn't support wildcards in the path.
You can now specify option for the `[DHCPv6]` section with
`systemd.network.<name>.dhcpV6Config.…`. Previously you could only use
the combined legacy DHCP configuration.
Systemd upstream has deprecated CriticalConnection with v244 in favor of
KeepConnection as that seems to be more flexible:
The CriticalConnection= setting in .network files is now deprecated,
and replaced by a new KeepConfiguration= setting which allows more
detailed configuration of the IP configuration to keep in place.
