summaryrefslogtreecommitdiffstats
path: root/rules.d (follow)
Commit message (Collapse)AuthorAgeFilesLines
* udev: consider serial ports as unconfigured only if both port and iomem_base ↵Lennart Poettering2024-10-171-1/+1
| | | | | | | | | sysattr is zero Various archs do not know the "io port" concept, hence check for the "iomem" configuration, too. Fixes: #34800
* Merge pull request #34482 from bgurney-rh/alt-nvme-multins-symlink-fixYu Watanabe2024-10-161-2/+2
|\ | | | | Pin obsolete NVMe symlinks to namespace 1
| * Pin obsolete NVMe symlinks to namespace 1Bryan Gurney2024-09-181-2/+2
| | | | | | | | | | | | | | | | In order to preserve backwards compatibility with legacy NVMe devices, create the obsolete symlinks, but only if they are associated with namespace ID 1. Signed-off-by: Bryan Gurney <bgurney@redhat.com>
* | udev: allow persistent storage rules for ublk devicesUday Shankar2024-10-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tools such as lsblk which query the udev database instead of probing devices directly fail when run on ublk devices. For instance, in the following commands, the partition type is missing, despite the fact that /dev/ublkb0 was just partitioned with a single Linux filesystem type partition. $ lsblk /dev/ublkb0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS ublkb0 259:0 0 31.3G 0 disk └─ublkb0p1 259:1 0 31.2G 0 part $ lsblk -o pkname,parttype /dev/ublkb0 PKNAME PARTTYPE ublkb0 This happens because ublk devices are missing from a couple of whitelists in the udev rules which are responsible for populating the database with the data lsblk is looking for. Add the ublk devices to these whitelists.
* | logind: add support for hidraw devicesPeter Hutterer2024-10-031-0/+1
| | | | | | | | | | | | Add support for opening /dev/hidraw devices via logind's TakeDevice(). Same semantics as our support for evdev devices, but it requires the HIDIOCREVOKE ioctl in the kernel.
* | udev: allow persistent storage rules for zram devicesKarel Zak2024-09-112-2/+2
|/ | | | | | | The /dev/zramN devices can be used as regular block devices. They are typically used for swap areas, but it would be beneficial to have LABEL and UUID in the udev database to make it more user-friendly for tools such as lsblk or mount (if used with other filesystems).
* udev: allow persistent storage rules for rbd devicesPeter Rajnoha2024-09-062-2/+2
| | | | | | The RADOS Block Device (rbd) can be used as any other block device with further layers on top of it, hence allow the common persistent storage rules to apply, including watching for changes.
* udev: Handle PTP device symlink properly on udev action 'change'Chengen Du2024-08-151-3/+3
| | | | | | | | | PTP device symlink creation rules are currently executed only when the udev action is 'add'. If a user reloads the rules and runs the udevadm trigger command to reapply changes, the symlink may be deleted, which can prevent the chronyd service from restarting properly. Signed-off-by: Chengen Du <chengen.du@canonical.com>
* add udev rules for trezor hw wallet devicesvdovhanych2024-07-241-0/+4
|
* rules: Add uaccess tag to /dev/udmabufHans de Goede2024-07-171-0/+2
| | | | | | | | | | | | | | | | | | In some cases userspace may need to create dmabuffers from userspace on such example is the software ISP part of libcamera which needs to allocate dma-buffers for the output of the software ISP. At first the plan was to allow console users access to /dev/dma_heap/*, this was discussed with various kernel folks here: https://lore.kernel.org/all/bb372250-e8b8-4458-bc99-dd8365b06991@redhat.com/ Giving console users access to the dma_heap's was deemed a bad idea because memory allocated this way is not accounted in cgroup limits. Giving access to /dev/udmabuf OTOH was deemed acceptable so that is what this patch adds. Resolves: #32662
* udev: tag MTD devices for systemdIan Abbott2024-06-121-0/+2
| | | | | | | | 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
* rules: Limit the number of device units generated for serial ttysDaan De Meyer2024-06-121-0/+2
| | | | | | | As per the suggestion in https://github.com/systemd/systemd/issues/33242. This reduces the number of /dev/ttySXX device units generated in mkosi from 32 to 4.
* udev: permanent symlinks with USB revision for /dev/media*Max Staudt2024-04-181-1/+2
| | | | | | | | | | | | | | | | | | | As a follow-up in the style of: 873be895ed ("udev: add USB revision in ID_PATH") this patch adds a second symlink for media controllers, this time including the USB revision. This means that in addition to persistent symlinks like: pci-0000:04:00.3-usb-0:1:1.0-media-controller -> ../../media0 We now also get: pci-0000:04:00.3-usbv2-0:1:1.0-media-controller -> ../../media0 ...which helps distinguish media devices plugged into different USB root hubs provided by the same PCI card, at least as long as they are for different USB revisions. Fixes: 04f19d6735 ("udev: Add /dev/media/by-path symlinks for media controllers")
* 99-systemd.rules: rework SYSTEMD_READY logic for device mapperMartin Wilck2024-04-031-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* udev: Add /dev/media/by-path symlinks for media controllersMax Staudt2024-02-221-0/+12
| | | | | | | | | | | | | | | | | | | Add persistent symlinks for media controller ("mediaX") devices, based on their ID_PATH udev properties. For example, if the uvcvideo driver creates /dev/media0, a persistent name may be: /dev/media/by-path/pci-0000:04:00.3-usb-0:1:1.0-media-controller Persistent links are a handy tool to make scripts self-documenting during development or in tests, as well as less error prone in case of devices changing enumeration order. For media controllers, one can alternatively scan through all of them and look for a matching bus_info in their struct media_device_info, but the links are much handier when drafting something by hand. A similar pattern already exists for Video4Linux /dev/videoX devices, see 60-persistent-v4l.rules for those.
* Fix systemd-backlight ignoring numbered kbd_backlight entriesWerner Sembach2024-01-221-1/+1
| | | | | | | | | 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.
* udev: even if a device is a zac device, scsi-$ID_SERIAL will be reserved for ↵我超厉害2024-01-161-0/+2
| | | | | it (#30459) Co-authored-by: wangyuhang <wangyuhang27@huawei.com>
* units: add a tpm2.target synchronization point and small generator that pulls inLennart Poettering2024-01-031-0/+3
| | | | | | | | | | | | | | | | | | | 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
* udev: add hwdb execution for hidraw subsystem devicesdjantti2023-12-241-0/+2
| | | | 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.
* rules: set up tty permissions and group for /dev/hvc* nodesFranck Bui2023-12-201-4/+1
| | | | | Before b4bf9007cbe, the permissions and group of the hypervisor consoles were set by agetty(8).
* udev: allow/denylist for reading sysfs attributes when composing a NIC nameLukas Nykryn2023-12-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* udev: generate system-unique storage symlinks using device pathRoland Hieber2023-12-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rules: go to the end of rules indeed when dm is suspendedjanana2023-11-291-1/+3
| | | | | | | | 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.
* rules: don't condition usb-gadget.target target on 'add' actionLennart Poettering2023-11-251-1/+1
| | | | | The dependency should exist continously, like all our similar deps do. Hence drop the "add" conditionalization.
* udev: add new builtin net_driverLukas Nykryn2023-11-011-0/+2
| | | | | | | | | | 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.
* udev: revert workarounds for issues caused by the devlink creation optimizationYu Watanabe2023-11-011-11/+0
| | | | | | | | | | | | | | This reverts the following two commits: - "udev: decrease devlink priority for encrypted partitions" c4521fc17bb33d10bf5aca3f87f6a394dfecf423. - "udev: decrease devlink priority for iso disks" df1dccd25547b430258bd42ec60428fc9aff1370. These commits are workarounds for issues caused by 331aa7aa15ee5dd12b369b276f575d521435eb52. 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.
* hwdb,rules: mark host-to-host network devices as only requiring link local ↵Lennart Poettering2023-10-301-0/+15
| | | | | | | | | | | | | | addressing This is a generalization of this logic: https://github.com/NetworkManager/NetworkManager/blob/main/data/90-nm-thunderbolt.rules It applies not just to thunderbolt, but to any kind of device, even matched by vendor/product, via hwdb. I added two entries for Prolific PC-to-PC devices (of which I have one lying around).
* rules: add mtd/by-name symlinksMatthias Schiffer2023-10-172-0/+13
| | | | | | | | 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.
* 99-systemd.rules.in: tag PTP devices with systemdChris Patterson2023-08-281-0/+2
| | | | | | | | | 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>
* udev: re-introduce symlinks for loopback block deviceYu Watanabe2023-08-101-0/+9
| | | | | | | | | | | 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 9915cc60868c77e7e8cecb669ddb90516dffc7df, 5022fab15fc16204d163883ca818fd6092dc919c, and c0d998248e10e1dcf18108fdbb70f259acd452eb.
* udev: set ID_NAME and ID_SERIAL to MMC/memstick devices againYu Watanabe2023-08-081-4/+6
| | | | | | Fixes a bug introduced by 998db5871fea331ec00b26a3a3f5271df040a905. Fixes #28671.
* meson: introduce HAVE_DMI flagYu Watanabe2023-08-031-1/+1
| | | | | The condition is used at several places. Let's introduce a simple flag for that.
* udev: decrease devlink priority for encrypted partitionsYu Watanabe2023-08-021-0/+5
| | | | | | 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.
* Drop split-usr and unmerged-usr supportLuca Boccassi2023-07-283-4/+4
| | | | | | | | | | As previously announced, execute order 66: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html The meson options split-usr, rootlibdir and rootprefix become no-ops that print a warning if they are set to anything other than the default values. We can remove them in a future release.
* udev: set ID_PATH properties for all pci, usb, and platform devicesYu Watanabe2023-07-251-0/+9
| | | | | | | | | | | | Before c43ff248f94266cfc93e300a2d3d163ed805e55b, 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.
* udev: decrease devlink priority for iso disksYu Watanabe2023-07-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if the priority is same, devlinks are always replaced by newer events. The commit 331aa7aa15ee5dd12b369b276f575d521435eb52 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, 331aa7aa15ee5dd12b369b276f575d521435eb52 makes the symlink point to the whole disk. The change by 331aa7aa15ee5dd12b369b276f575d521435eb52 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.
* Revert "udev: add /dev/loop/ symlinks"Luca Boccassi2023-07-201-9/+0
| | | | | | | | | Turns out this causes a regression and breaks losetup. It will need to be reworked in conjunction with util-linux changes. Fixes https://github.com/systemd/systemd/issues/28475 This reverts commit 5ac52d1f7b7cd11cad8b5c2e9812d7ee7560a517.
* rules: drop weird spacesLennart Poettering2023-06-201-3/+2
|
* rules: split out DMI related rules from udev-default.rulesLennart Poettering2023-06-203-10/+15
| | | | | | | | | | | | 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.
* 99-systemd.rules.in: guard systemd-backlight udev rules by ENABLE_BACKLIGHTSimon Braunschmidt2023-06-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* udev: introduce .PART_SUFFIX internal propertyYu Watanabe2023-05-261-63/+48
| | | | To make unify rules for disk and partition.
* rules: add rule for accel devicesStanislaw Gruszka2023-05-251-0/+1
| | | | | | | | | | | | Accel (Compute Acceleration) are new devices for AI/ML computation: https://docs.kernel.org/accel/introduction.html They are part of DRM subsystem. Add them to 'render' group since no other appropriate group in standard linux systems exist. This can be changed when proper common user-space components will emerge, and new group for acceleration devices access will be established. Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
* Merge pull request #27483 from yuwata/udev-id-path-usb-revisionZbigniew Jędrzejewski-Szmek2023-05-257-27/+52
|\ | | | | udev: include USB revision in ID_PATH
| * udev: add USB revision in ID_PATHYu Watanabe2023-05-207-22/+41
| | | | | | | | | | | | | | | | | | xHCI host controller may register two (or more?) USB root hubs for USB 2.0 and USB 3.0, and devices under the hubs may have same ID_PATH. So, to avoid the conflict, let's introduce ID_PATH_WITH_USB_REVISION that includes the USB revision. Closes #19406.
| * udev: check existence of property before useYu Watanabe2023-05-201-6/+12
| |
* | rules: start systemd-vconsole-setup via unitZbigniew Jędrzejewski-Szmek2023-05-191-1/+1
|/ | | | | | | | | | | We started systemd-vconsole-setup in two ways: via a dbus call from localed to do systemd-vconsole-setup.service/restart, and from udev, calling the binary directly. This patch makes udev call systemctl restart systemd-vconsole-setup.service effectively implementing the same method as localed. Ordering is implemented at the unit level, so we can use --no-block to not block here.
* udev/iocost: invert DEVTYPE matchYu Watanabe2023-04-261-3/+1
| | | | | No functional change, just refactoring. Addresses https://github.com/systemd/systemd/pull/23325#discussion_r1171006967.
* udev/iocost: use ID_MODEL_FROM_DATABASE if existsYu Watanabe2023-04-261-1/+5
| | | | To make the rule consistent with 'iocost query'.
* Merge pull request #27349 from mrc0mmand/codespellLuca Boccassi2023-04-201-2/+2
|\ | | | | tree-wide: code spelling fixes
| * tree-wide: code spelling fixesFrantisek Sumsal2023-04-201-2/+2
| | | | | | | | As reported by Fossies.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 12:43:30 +0100