In mkosi, we've been having CI failures caused by
systemd-machine-id-commit.service timing out. Let's bump the timeout
for it and systemd-rfkill.service to 90s which we also use for other
oneshot services to avoid transient failures on slower systems.
ProtectSystem=full remounts /boot and/or /efi read-only, but that
may trigger automount for the paths and delay the service being started.
===
systemd[1]: boot.automount: Got automount request for /boot, triggered by 720 ((networkd))
===
The service does not need to access the paths, so let's hide them.
Follow-up for f90eb08627.
Fixes#31742.
Then, this introduces systemd-networkd-persistent-storage.service.
systemd-networkd.service is an early starting service. So, at the time
it is started, the persistent storage for the service may not be ready,
and we cannot use StateDirectory=systemd/network in
systemd-networkd.service.
The newly added systemd-networkd-persistent-storage.service creates the
state directory for networkd, and notify systemd-networkd that the
directory is usable.
Most of our kernel cmdline options use underscores as word separators in
kernel cmdline options, but there were some exceptions. Let's fix those,
and also use underscores.
Since our /proc/cmdline parsers don't distinguish between the two
characters anyway this should not break anything, but makes sure our own
codebase (and in particular docs and log messages) are internally
consistent.
This ensures that a user-specific blob directory exists in
/var/cache/systemd/homed for as long as the user exists, and gets
deleted if the user gets deleted.
It also advertises this blob directory via the user record, so that
clients can find and use it.
This commit adds a new way of forwarding journal messages - forwarding
over a socket.
The socket can be any of AF_INET, AF_INET6, AF_UNIUX or AF_VSOCK.
The address to connect to is retrieved from the "journald.forward_address" credential.
It can also be specified in systemd-journald's unit file with ForwardAddress=
Before #30884, the user state is tied to user@.service (user service
manager). However, #30884 introduced sessions that need no manager,
and we can no longer rely on that.
Consider the following situation:
1. A 'background-light' session '1' is created (i.e. no user service manager
is needed)
2. Session '1' scope unit pulls in user-runtime-dir@.service
3. Session '1' exits. A stop job is enqueued for user-runtime-dir@.service
due to StopWhenUnneeded=yes
4. At the same time, another session '2' which requires user manager is started.
However, session scope units have JobMode=fail, therefore the start job
for user-runtime-dir@.service that was pulled in by session '2' scope job
is deleted as it conflicts with the stop job.
We want session scope units to continue using JobMode=fail, but we still need
the dependencies to be started correctly, i.e. explicitly requested by logind
beforehand. Therefore, let's stop using StopWhenUnneeded=yes for
user-runtime-dir@.service, and track users' `started` and `stopping` state
based on that when user@.service is not needed. Then, for every invocation
of user_start(), we'll recheck if we need the service manager and start it
if so.
Also, the dependency type on user-runtime-dir@.service from user@.service
is upgraded to `BindsTo=`, in order to ensure that when logind stops the
former, the latter is stopped as well.
Let's make sure that user's cannot DoS services for other users so
easily, and enable MaxConnectionsPerSocket= by default for all of them.
Note that this is mostly paranoia for systemd-pcrextend.socket and
systemd-sysext.socket: the socket is only accessible to root anyway,
hence the accounting shouldn#t change anything. But this is just a
safety net, in preparation that we open up some functionality of these
services sooner or later.
Also= lists units which should be enabled/disabled together with the first unit.
But userdbd is independent of homed, we shouldn't e.g. disable it even if homed
is disabled.
To me this is the last major basic functionality that couldn't be
configured via credentials: the network.
We do not invent any new format for this, but simply copy relevant creds
1:1 into /run/systemd/network/ to open up the full functionality of
networkd to VM hosts.
Distributions apparently only compile a subset of TPM2 drivers into the
kernel. For those not compiled it but provided as kmod we need a
synchronization point: we must wait before the first TPM2 interaction
until the driver is available and accessible.
This adds a tpm2.target unit as such a synchronization point. It's
ordered after /dev/tpmrm0, and is pulled in by a generator whenever we
detect that the kernel reported a TPM2 to exist but we have no device
for it yet.
This should solve the issue, but might create problems: if there are TPM
devices supported by firmware that we don't have Linux drivers for we'll
hang for a bit. Hence let's add a kernel cmdline switch to disable (or
alternatively force) this logic.
Fixes: #30164
This extends what systemd-firstboot does and runs on first boots only
and either processes user records passed in via credentials to create,
or asks the user interactively to create one (only if no regular user
exists yet).
The unit will be started or restarted a few times during boot, but but it has
StartLimitBurst = DefaultStartLimitBurst = 5, which means that the fifth
restart will already fail. On my laptop, I have exactly 4 restarts, so I don't
hit the limit, but on a slightly different system we will easily hit the limit.
In https://bugzilla.redhat.com/show_bug.cgi?id=2251394, there are five reloads
and we hit the limit.
Since 6ef512c0bb we propagate the start counter
over switch-root and daemon reloads, so it's easier to hit the limit during
boot.
In principle there might be systems with lots of vtcon devices, so let's just
allow the unit to be restarted without a limit.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2251394.
This implements a "storage target mode", similar to what MacOS provides
since a long time as "Target Disk Mode":
https://en.wikipedia.org/wiki/Target_Disk_Mode
This implementation is relatively simple:
1. a new generic target "storage-target-mode.target" is added, which
when booted into defines the target mode.
2. a small tool and service "systemd-storagetm.service" is added which
exposes a specific device or all devices as NVMe-TCP devices over the
network. NVMe-TCP appears to be hot shit right now how to expose
block devices over the network. And it's really simple to set up via
configs, hence our code is relatively short and neat.
The idea is that systemd-storagetm.target can be extended sooner or
later, for example to expose block devices also as USB mass storage
devices and similar, in case the system has "dual mode" USB controller
that can also work as device, not just as host. (And people could also
plug in sharing as NBD, iSCSI, whatever they want.)
How to use this? Boot into your system with a kernel cmdline of
"rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on
screen the precise "nvme connect" command line to make the relevant
block devices available locally on some other machine. This all requires
that the target mode stuff is included in the initrd of course. And the
system will the stay in the initrd forever.
Why bother? Primarily three use-cases:
1. Debug a broken system: with very few dependencies during boot get
access to the raw block device of a broken machine.
2. Migrate from system to another system, by dd'ing the old to the new
directly.
3. Installing an OS remotely on some device (for example via Thunderbolt
networking)
(And there might be more, for example the ability to boot from a
laptop's disk on another system)
Limitations:
1. There's no authentication/encryption. Hence: use this on local links
only.
2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd
have a read-only mode, for security reasons, and default to it.
Future love:
1. We should have another mode, where we simply expose the homed LUKS
home dirs like that.
2. Some lightweight hookup with plymouth, to display a (shortened)
version of the info we write to the console.
To test all this, just run:
mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
