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
Hwdb call for hidraw subsystem is missing and AV controller devices defined in hwdb.d/70-av-production.hwdb never get the proper permissions for /dev/hidraw*. This patch implements hwdb execution also for hidraw devices.
Users can currently pick specific versions of NIC naming, but that
does not guarantee that NIC names won't change after the kernel adds
a new sysfs attribute.
This patch allows for an allow/deny list of sysfs attributes
that could be used when composing the name.
These lists can be supplied as an hwdb entry in the form of
/etc/udev/hwdb.d/50-net-naming-allowlist.hwdb
net:naming:drvirtio_net
ID_NET_NAME_ALLOW=0
ID_NET_NAME_ALLOW_ACPI_INDEX=1
ID_NET_NAME_ALLOW_ADDR_ASSIGN_TYPE=1
ID_NET_NAME_ALLOW_ADDRESS=1
ID_NET_NAME_ALLOW_ARI_ENABLED=1
ID_NET_NAME_ALLOW_DEV_PORT=1
ID_NET_NAME_ALLOW_FUNCTION_ID=1
ID_NET_NAME_ALLOW_IFLINK=1
ID_NET_NAME_ALLOW_INDEX=1
ID_NET_NAME_ALLOW_LABEL=1
ID_NET_NAME_ALLOW_PHYS_PORT_NAME=1
ID_NET_NAME_ALLOW_TYPE=1
When the same disk image is written to multiple storage units, for
example an external SD card and an internal eMMC, the symlinks in
/dev/disk/by-{label,uuid,partlabel,partuuid}/ are no longer unique, and
will point to the device that is probed last.
Adressing partitions via labels and UUIDs is nice to work with, and
depending on the use case, it might also be more robust than using the
symlinks in /dev/disk/by-path/ containing the partition number. Combine
the two approaches to create unique symlinks containing both the device
path as well as the respective UUIDs or labels, and throw in a symlink
using the devpath and the partition number for the sake of completeness.
For an exemplary GPT-partitioned disk at "platform-2198000.mmc" with a
partition containing an ext4 file system, this might create symlinks of
the following form:
/dev/disk/by-path/platform-2198000.mmc-part/by-partnum/1
/dev/disk/by-path/platform-2198000.mmc-part/by-partuuid/e5a75233-3b90-4aec-8075-b4dd7132b48d
/dev/disk/by-path/platform-2198000.mmc-part/by-partlabel/rootfs
/dev/disk/by-path/platform-2198000.mmc-part/by-uuid/b2c92f24-8215-4680-b931-f423aae5f1c9
/dev/disk/by-path/platform-2198000.mmc-part/by-label/rootfs
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
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.
Currently the ID_NET_DRIVER is set in net_setup_link builtin.
But this is called pretty late in the udev processing chain.
Right now in some custom rules it was workarounded by calling ethtool
binary directly, which is ugly.
So let's split this code to a separate builtin.
This reverts the following two commits:
- "udev: decrease devlink priority for encrypted partitions"
c4521fc17b.
- "udev: decrease devlink priority for iso disks"
df1dccd255.
These commits are workarounds for issues caused by
331aa7aa15.
With the previous commit, these workarounds are not necessary anymore,
as partitions are always processed later than their whole disk, and
a decrypted volume is also processed later than its backing volume.
Add persistent symlinks for MTD devices like SPI-NOR flash, based on the
partition names specified on the cmdline, in a Device Tree, or by other
MTD partitioning parser drivers. Using the persistent name can be
preferable to using the numbered /dev/mtdX device, as the latter can
change depending on probe order or when partitioning has changed.
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>
But the directories are changed from /dev/loop/by-ref/ -> /dev/disk/by-loop-ref/
and /dev/loop/by-inode/ -> /dev/disk/by-loop-inode/.
As /dev/loop/ is used by losetup command for other purpose.
See issue #28475.
This effectively reverts commits 9915cc6086,
5022fab15f, and
c0d998248e.
Decrease devlink priority for encrypted partitions, and make the priority for
decrypted DM devices relatively higher. This is for the case that an encrypted
partition and its decrypted DM device have the same label.
Before c43ff248f9, the following line in
60-drm.rules also sets ID_PATH for all pci, usb, and platform devices:
===
ACTION!="remove", SUBSYSTEM=="drm", SUBSYSTEMS=="pci|usb|platform", IMPORT{builtin}="path_id"
===
Unfortunately, some existing rules rely on the unexpected behavior.
To keep the backward compatibility, let's set ID_PATH for them.
Fixes#28411.
Previously, if the priority is same, devlinks are always replaced by
newer events. The commit 331aa7aa15 changes
that to keep the existing devlink. That should not change any behavior
when the devices that request the same symlink do not have any
dependency, e.g. when /dev/sda1 and /dev/adb1 request the same
/dev/disk/by-label symlink, as there are no guarantee that which device
is processed first.
However, when devices has dependency, e.g. /dev/sda and /dev/sda1
request the same /dev/disk/by-label symlink, previously the symlink
always pointed to the partition, as the partition is always processed
later. But, 331aa7aa15 makes the symlink
point to the whole disk.
The change by 331aa7aa15 is crucial to
improve performance of devlink handling, especially when a system has
large number of disks with same label or so. Hence, cannot and should
not be reverted.
So, let's workaround the case, as such situation should happen only when
the disk is a hybrind ISO image, I guess.
Fixes#28468.
The DMI rules where so far guarded by an ACTION=="add" rule, but that
doesn't really make sense for setting properties (only for setting
access modes/ownership of nodes).
Hence let's move this into its own file, that guards properly on
ACTION!="remove".
Before this change the hardware vendor/model info would be dropped
whenever the device was retriggered.
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>
