Ensure that systemd-random-seed.service has completed before marking
a first boot as completed to guarantee that a saved seed will only be
used after it has been initialized at least once.
Make sure systemd-firstboot completes before reaching first-boot-complete.target
and thus marking the first boot as completed. This way, it is
guaranteed that systemd-firstboot has a chance to complete provisioning
at least once, even in cases of the first boot getting aborted early.
Add a new target for synchronizing units that wish to run once during
the first boot of the system. The machine-id will be committed to disk
only after the target has been reached, thus ensuring that all units
ordered before it had a chance to complete.
sync() before committing a transient machine-id to disk. This will
ensure that any filesystem changes made by first-boot units will have
been persisted before the first boot is marked as completed.
Currently, a loss of power after the machine-id was written but before
all units with ConditionFirstBoot=yes ran would lead to the next boot
finding a valid machine-id, thus not being marked first boot and not
re-running these units.
To make the first boot mechanism more robust, instead of writing
/etc/machine-id very early, fill it with a marker value "uninitialized"
and overmount it with a transiently provisioned machine-id. Then, after
the first boots completes (when systemd-machine-id-commit.service runs),
write the real machine-id to disk.
This mechanism is of course only invoked on first boot. If a first boot
is not detected, the machine-id is handled as previously.
Fixes: #4511
If the first boot was aborted, /etc/machine-id might read as
"uninitialized" in some cases. Add a separate case for this
instead of printing a confusing error message.
When systemd-repart runs from initramfs, it reads out /etc/machine-id
from the rootfs as a seed for partition UUIDs. However, the machine-id
could be in an "uninitialized" state from a previous failed first boot.
In this situation the -ENOMEDIUM code-path (no machine-id set) should be
taken.
When nspawn starts an image, this image could be in any state, including
an aborted first boot. For this case, it needs to correctly handle the
situation like there was no machine-id at all.
Add a new ID128_PLAIN_OR_UNINIT format which treats the string
"uninitialized" like the file was empty and return -ENOMEDIUM. This
format should be used when reading an /etc/machine-id file from an image
that is not currently running.
When /etc/machine-id contains the string "uninitialized" instead of
a valid machine-id, treat this like the file was missing and mark this
boot as the first (-> units with ConditionFirstBoot=yes will run).
The proc-sys-fs-binfmt_misc.mount unit should not be enabled by
preset-all because it should only be used as fallback in case
proc-sys-fs-binfmt_misc.automount cannot be used on a system. In these
cases it should be enabled manually by an administrator.
Ubuntu CI's just got the dependencies require dto run this test added,
and it seems the build is different enough from other platforms
that it fails to create the required directories:
cp: cannot create regular file '/var/tmp/systemd-test.JJMOBY/minimal/usr/lib/os-release': No such file or directory
It looks like we need to do some whack-a-mole before it will fully pass,
so disable for now. It was skipped until today anyway due to missing
dependencies.
let's add informational logging about each client requested signal
sending. While we are at, let's beef up error handling/log messages in
this case quite a bit: let's log errors both to syslog and report errors
back to client.
Fixes: #17254
--kill-who=main-fail never worked correctly, due to a copy and paste
mistake in ac5e3a505e, where the same item
was listed twice. The mistake was
later noticed, but fixed incorrectly, in
201f0c916d.
Let's list all *-fail types correctly, finally.
And while we are at it, add a nice comment and generate a prettier D-Bus
error about this.
No functional change is intended.
The general pattern of changes:
-usb:v04F3p2B7C*
+usb:v04F3p2B7C:*
This is mostly a clarification, to make the part that makes the usb vXXXXpYYYY
part visually separated. It would only make a difference if we added further
keys with a different number of digits, which is unlikely.
-usb:v0627p0001:*QEMU USB Keyboard*
-usb:v0627p0001:*QEMU USB Mouse*
-usb:v0627p0001:*QEMU USB Tablet*
+usb:v0627p0001:*QEMU USB Keyboard*:*
+usb:v0627p0001:*QEMU USB Mouse*:*
+usb:v0627p0001:*QEMU USB Tablet*:*
Again, only a clarification. We know that ":" will appear somewhere later in
the match key, so anything that matches "…Keyboard*" will also match "…Keyboard*:*".
-evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV*
+evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV:*
This makes the match narrower. Previously we would match product "N53SV"
and "N53SV2", "N53SV3", and others. Here we are saying that the ':pn' part must
match exactly. Most of the changes in this patch match this pattern. I made a few
judgement calls and used "pn…*:*" when I wasn't sure if the full pn is included:
-evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*
+evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*:*
-evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:
+evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:*
This more like the "QEMU" example above, since all dmi strings end in ":", so
anything which matches the old version will also match the new version.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:*
I replaced trailing ":pvr*" by ":*". This makes no functional difference because
we expect "pvr" to always appear in the dmi string. This makes patterns shorter.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:*
OTOH, ":pn*" is kept. This is because almost patterns include ":pn*", and if we
skip it, we should make it clear that this is on purpose, that we really want to
match any product name.
The python script to generate autosuspend rules is updated to use ":*" too.
Inspired by https://github.com/systemd/systemd/pull/17281#discussion_r501489750.
Let's mark the whole /run/host hierarchy as something to ignore by PID 1
for generation of .mount units, i.e. consider it as "extrinsic".
By unifying container mgr supplied resources in one dir it's also easy
to exclude the whole lot from PID1's management inside the container.
This is the right thing to do, since from the payload's PoV these mounts
are just API and not manipulatable as they are established, managed and
owned by the container manager, not the payload.
(While we are it, also add the boot ID mount to the existing list, as
nspawn and other container managers overmount that too, typically, and
it is thus owned by the container manager and not the payload
typically.)
We want to compile the new code in CI without having to explicitly specify
-Doomd=true everywhere. Let's enable it by default, and rely on distros
setting -Dmode=release to not have it enabled by default.
I'm keeping this part separate because a function change is intended here.
Those patterns didn't match:
$ systemd-hwdb query 'evdev:atkbd:dmi:bvn_:bvr_:bd_:svnLENOVO:pn_:pvrThinkPadT430s'
KEYBOARD_LED_CAPSLOCK=0
$ systemd-hwdb query 'evdev:atkbd:dmi:bvn_:bvr_:bd_:svnLENOVO:pn_:pvrThinkPadT430s:'
(nil)
I can't think of any real vulnerability about this, but it still feels
better to check a variable with "secure" in its name with
secure_getenv() rather than plain getenv().
Paranoia FTW!
