morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-15 00:47:10 +09:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
systemd/rules.d/60-block.rules

25 lines
1.4 KiB
Plaintext
Raw Permalink Normal View History

rules: move block device rules to its own rules file
2015-03-12 16:09:46 +01:00
# do not edit this file, it will be overwritten on update
# enable in-kernel media-presence polling
ACTION=="add", SUBSYSTEM=="module", KERNEL=="block", ATTR{parameters/events_dfl_poll_msecs}=="0", \
ATTR{parameters/events_dfl_poll_msecs}="2000"
# forward scsi device event to corresponding block device
ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change"
# watch metadata changes, caused by tools closing the device node which was opened for writing
udev: assume all devices which have persistent links also need to be watched We had two similar lists, but one was accepting many more device types. I assume that this is by mistake, simply because the lack of device links is easier to notice than the lack of synthesized event after the device is written to. This uses the same list in both places, effectively adding "watch" attribute to /dev/nbd*, /dev/zd*, etc.
2019-08-16 13:20:04 +02:00
ACTION!="remove", SUBSYSTEM=="block", \
udev: allow persistent storage rules for ublk devices 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.
2024-10-10 14:29:10 -06:00
KERNEL=="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*|ubi*|scm*|pmem*|nbd*|zd*|rbd*|zram*|ublkb*", \
udev: assume all devices which have persistent links also need to be watched We had two similar lists, but one was accepting many more device types. I assume that this is by mistake, simply because the lack of device links is easier to notice than the lack of synthesized event after the device is written to. This uses the same list in both places, effectively adding "watch" attribute to /dev/nbd*, /dev/zd*, etc.
2019-08-16 13:20:04 +02:00
OPTIONS+="watch"
udev: reset loopback block device ownership and mode on detach Loopback block devices are agressively reused, without being removed in between. This means various inode attributes on their device nodes will – so far – remain in effect between uses of the devices. Since there are applications which change access mode/ownership of such devices after attaching files to them, let's undo this again when we detect them to be unused again. Fixes: #37745
2025-06-19 17:18:11 +02:00
# Reset access rights to each loopback device once it gets detached.
rules: apply loopback block device rule only onto loopback block devices Fixes: #39426 Follow-up for: 9422ce83c201ab4154de832331f0b351fc5137f6
2025-10-24 17:03:02 +02:00
ACTION=="change", SUBSYSTEM=="block", KERNEL=="loop*", ENV{DISK_MEDIA_CHANGE}=="1", TEST!="loop/backing_file", GROUP="disk", MODE="660"
udev: introduce ID_BLOCK_SUBSYSTEM property Virtual block devices are a bit weird: they have no parent device, and thus cannot be related to the subsystem they belong to, except by pattern matching their name. This is OK to do if one knows what to look for. However for tools that do not want to carry a list of known subsystems with their appropriate matching patters this sucks. Let's introduce a new ID_BLOCK_SUBSYSTEM property we can set on block devices that carries an explicit string for this. Do so for a small number of key subsystems: DM, loopback and zram.
2025-10-24 17:13:12 +02:00
# Provide a somewhat cleaned up field indicating the subsystem various
rules.d/60-block.rules: fix typo
2025-11-02 10:56:31 +01:00
# 'virtual' block devices belong to, in order to avoid replicating name based
udev: introduce ID_BLOCK_SUBSYSTEM property Virtual block devices are a bit weird: they have no parent device, and thus cannot be related to the subsystem they belong to, except by pattern matching their name. This is OK to do if one knows what to look for. However for tools that do not want to carry a list of known subsystems with their appropriate matching patters this sucks. Let's introduce a new ID_BLOCK_SUBSYSTEM property we can set on block devices that carries an explicit string for this. Do so for a small number of key subsystems: DM, loopback and zram.
2025-10-24 17:13:12 +02:00
# pattern matching in every consumer
ACTION!="remove", SUBSYSTEM=="block", KERNEL=="dm-*", ENV{ID_BLOCK_SUBSYSTEM}="dm"
ACTION!="remove", SUBSYSTEM=="block", KERNEL=="loop*", ENV{ID_BLOCK_SUBSYSTEM}="loop"
ACTION!="remove", SUBSYSTEM=="block", KERNEL=="md*", ENV{ID_BLOCK_SUBSYSTEM}="md"
ACTION!="remove", SUBSYSTEM=="block", KERNEL=="zram*", ENV{ID_BLOCK_SUBSYSTEM}="zram"
Reference in New Issue Copy Permalink