probe_gpt_boot_disk_needs_loop() sets ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP
for any whole disk that holds the boot ESP/XBOOTLDR but whose partition table
the kernel cannot parse. Until now the udev rule turned that into a
systemd-loop@.service for every block device.
That is too broad: device-mapper devices also report kernel partition
scanning as disabled, but their partitions are managed in userspace by kpartx
(see 66-kpartx.rules). Setting up a loop device on top of them re-exposes the
same partition table a second time and only causes trouble.
Restrict the rule to optical drives, the one class that genuinely needs a
kernel-side loop device (El Torito GPT sector size mismatch, or drives that do
not support partition scanning) and that has no userspace partition manager of
its own.
Co-developed-by: Claude Fable 5 <noreply@anthropic.com>
When a device carries a SYSTEMD_MACHINE_TAG udev property, tag it for
systemd and pull in systemd-machine-tag@<tag>.service, which adds the
given tag to the host's machine tags. In other words, attaching the
property to a device makes the host auto-tag itself with the specified
machine tag.
Previously, probe_gpt_sector_size_mismatch() would bail out early when
the GPT sector size matched the device sector size. However, some
devices (e.g. certain CD-ROM drives) do not support kernel partition
scanning even when sector sizes match. In that case, the kernel still
cannot parse the partition table, and we need to set up a loop device to
expose the partitions — just as we do for the sector size mismatch case.
Check blockdev_partscan_enabled() when sector sizes match, and only skip
the boot partition check if partition scanning is actually supported.
Also rename the function, udev property, and log messages to reflect the
broader scope:
- probe_gpt_sector_size_mismatch() -> probe_gpt_boot_disk_needs_loop()
- ID_PART_GPT_AUTO_ROOT_DISK_SECTOR_SIZE_MISMATCH -> ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP
When the GPT partition table uses a different sector size than the
device's native block size (e.g. 512-byte GPT on a 2048-byte CD-ROM
booted via El Torito), the kernel cannot parse the partition table.
Probe the GPT sector size upfront and configure blkid with the correct
value so it always finds the partition table. If a sector size mismatch
is detected, trigger a loop device to re-expose the device with the
correct sector size and skip root partition discovery on the original
device — it will happen on the loop device instead.
Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
All other rules in 99-systemd.rules are pretty much concerned about
SYSTEMD_READY=1 and tagging devices the service manager shall track. But
the gpt-root symlink is different, and it makes sense independently of
the service manager. Hence give it a separate file.
This introduces indentation for inner sections skipped via GOTO=. The
rules parser supports that. In order to make this more readable, let's
maybe make use of this.
Strictly speaking we don't need to tag these devices, because tpm2-tss
already does so, but given we do this for /dev/tpmrm0, we should
probably do this comprehensively if we rely on this ourselves.
Fixes: #36653
In relevant factory reset situation the root disk itself is subject to
removal. This somewhat conflicts with automatic root disk discovery,
since the system first comes up with one candidate for the root disk,
which is then replaced by another.
Let's address this by determining at the moment of probing for the
gpt-root logic what the factory reset state currently is. This is then
used to maintain two distinct symlinks to the gpt auto root device: one
which is always available and one that is only available if factory
reset is off or complete.
The new symlinks is not used by anything yet. This will be added in a
later commit.
Allow systemd units to require/bind to MTD devices. One use case is for
using a systemd service to attach an MTD device to an UBI controller,
which cannot be done until the MTD device has been probed.
Fixes#33096
Device mapper devices are set up in multiple steps. The first step, which
generates the initial "add" event, only creates an empty container, which is
useless for higher layers. SYSTEMD_READY should be set to 0 on this event to
avoid premature device activation.
The event that matters is the "activation" event: the first "change" event on
which DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 is not set. When this event arrives,
the device is ready for being scanned by blkid and similar tools, and for being
activated by systemd.
Intermittent events with DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 should be ignored
as far as systemd or higher-level block layers are concerned. Previous device
properties and symlinks should be preserved: the device shouldn't be scanned or
activated, but shouldn't be deactivated, either. In particular, SYSTEM_READY
shouldn't be set to 0 if it wasn't set before, because that might cause mounted
file systems to be unmounted. Such intermittent events may occur any time,
before or after the "activation" event.
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 can have multiple reasons. One possible reason
is that the device is suspended. There are other reasons that depend on the
device-mapper subsystem (LVM, multipath, dm-crypt, etc.).
The current systemd rule set
1) sets SYSTEMD_READY=0 if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set in "add"
events;
2) imports SYSTEMD_READY from the udev db if DM_SUSPENDED is set, and jumps to systemd_end;
3) sets SYSTEMD_READY=1, otherwise.
This logic has several flaws:
* 1) can cause file systems to be unmounted if an coldplug event arrives while
a file system is suspended. This rule shouldn't be applied for coldplug events
or in general, "synthetic" add events;
* 2) evaluates DM_SUSPENDED=1, which is a device-mapper internal property.
It's wrong to infer that a device is accessible if DM_SUSPENDED=0.
The jump to systemd_end may cause properties and/or symlinks to be lost;
* 3) is superfluous, because SYSTEMD_READY=1 is equivalent with SYSTEMD_READY
being unset, and can create the wrong impression that the device was explicitly
activated.
This patch fixes the logic as follows:
- apply 1) only if DM_NAME is empty, which is only the case for the first
"genuine add" event;
- change 2) to use DM_UDEV_DISABLE_OTHER_RULES_FLAG instead of DM_SUSPENDED,
and remove the GOTO directive;
- remove 3).
Fixes: b7cf1b6 ("udev: use SYSTEMD_READY to mask uninitialized DM devices")
Fixes: 35a6750 ("rules: set SYSTEMD_READY=0 on DM_UDEV_DISABLE_OTHER_RULES_FLAG=1 only with ADD event (#2747)")
Signed-off-by: Martin Wilck <mwilck@suse.com>
If there are name collisions in the leds subsystem, the 2nd device node with the
colliding name gets automatically renamed by appending _1, the third by
appending _2 and so on.
This wildcard change makes sure that systemd-backlight also catches these
renamed nodes for kbd_backlight entries.
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
The previous patch 466266c does not make sense indeed, that is to say, if the SYSTEMD_READY is not recorded in the database, the GOTO="systemd_end" will not be applied.
The IMPORT{db} is actually a matching token, it returns false when there is no SYSTEMD_READY recorded in the database.
The previous patch 466266c tended to inherit the state of SYSTEMD_READY from the database and skip to the end of current rule file. But when the database does not contain SYSTEMD_READY, e.g., the dm-* is not set db_persistent during initrd and the database will be cleared after switching root, the following rules will still be applied not as expected.
Chronyd and similar time services, when using PTP devices, may need
the BindsTo/After directives to ensure the devices are available
before starting. Tag PTP devices with systemd to allow for wider
adoption.
Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
Linux kernel will, as documented in drivers/video/backlight/backlight.c,
report changes to a backlights brightness as a uevent (ACTION=change).
systemd-udev will consume the uevent, match on this rule and try to
activate the systemd-backlight service for the backlight. BUT when
systemd is not compiled with backlight support, this will lead to
failure that is reported in the journal.
Since the failure to activate systemd-backlight and subsequent failure
log entry happens on every backlight brightness change, we found the
resulting logspam during regular operation excessive and came up with
this patch to mitigate it.
The conditional is also extended to "*kbd_backlight" match, since
even though we did not investigate to see if the logspam would be
similar, the unconditional match to activate systemd-backlight here
would also not make sense when the feature is not compiled in.
Signed-off-by: Simon Braunschmidt <simon.braunschmidt@iba-group.com>
We can't get any FS meta-data from a suspended device. Hence defer
making any plugged/unplugged decisions, i.e. we just import whatever was
previous state and skip processing all other rules.
Thanks Lennart Poettering <lennart@poettering.net> for suggesting this
solution.
70-uaccess.rules sets the uaccess tag on devices with ID_SMARTCARD_READER
set, but it is set in 99-systemd.rules .
Move this to a 60-*.rules which already matches USB CCID class, factorising
the matching, so 70-uaccess.rules sets up these devices as expected.
The recent bug report indicated a race at device creation and the
sound.target dependencies, and the cause turned out to be the condition
of the sound.target trigger. Currently it's set for "card*", but this
is actually the parent object; i.e. the sound.target is triggered before
the sound devices are created.
For assuring the whole sound device creations beforehand, we need to use
"controlC*" instead of "card*"; as already described in
78-sound-card.rules, this is guaranteed to be the last device, and can
be used as a synchronization point.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1179363
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This change is only about the source tree. We have tmpfiles.d/, modprobe.d/,
sysctl.d/, and sysusers.d/, but for historical reasons, rules/ didn't fit this
pattern. We also *install* it as rules.d/. Let's rename to be consistent.
Lennart Poettering
Daan De Meyer
Lennart Poettering
Nick Rosbrook
Ian Abbott
Daan De Meyer
Martin Wilck
Werner Sembach
janana
Chris Patterson
Luca Boccassi
Simon Braunschmidt
Michal Sekletar
Zbigniew Jędrzejewski-Szmek
Vincent Pelletier
Yu Watanabe
Takashi Iwai