IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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>
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).
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.
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>
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.
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.
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.
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.
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.
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.
In 5118e8e71dda211d20e34ec8d3012186ba27d3d3, the rules were changed to add
OPTIONS="string_escape=replace" to creation of
ENV{ID_SERIAL}="$env{ID_MODEL}_$env{ID_SERIAL_SHORT}", so that "/" would be
escaped. But this also changes how the symlink looks for devices that do not
have "/". This adds back the old symlink for compat, except when a slash
is present.
In the meantime, we changed the symlink format to include ${ND_NSID}. Since
the symlink with unescaped characters are older than that, for compat we
only need to cover the older type. (Symlinks without escaping and with ${ND_NSID}
were never created.) This makes it slightly easier on users: the non-deprecated
symlinks are with "_${ND_NSID}", so they are easier to distinguish.
Fixes#27155.
Mostly untested :( I only have a boring nvme device with no special characters
in the id, and the symlinks are unchanged for it by this patch.
The nvme by-id symlink changes to the latest namespace when a new namespace gets
added, for example by connecting multiple NVMe/TCP host controllers via nvme
connect-all.
That is incorrect for persistent device links.
The persistent symbolic device link should continue to point to the same NVMe
namespace throughout the lifetime of the current boot.
Therefore the namespace id needs to be added to the link name.
This adds symlinks that allow accessing loopback block devices via stable
names that reference their backing block devices, make the unpredictable
naming of loopback devices less of an issue.
Example:
1. Create a loopback block device for a file $F
losetup --find $F
2. Reference the backing block device via its inode:
L="$(stat -c '/dev/loop/by-inode/%Hd:%Ld-%i' $F)"
fdisk $L
In the above the loop device name (which might be /dev/loop47 or any
other name) is not used at all.
When built without blkid, then udev-builtin-blkid is not built,
and the verifier warns about the unknown builtin:
60-persistent-storage.rules:114 Unknown builtin command: blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}
60-persistent-storage.rules:117 Unknown builtin command: blkid --noraid
60-persistent-storage.rules:120 Unknown builtin command: blkid
60-persistent-storage.rules: udev rules check failed
