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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
ubifs volumes have a UUID and the built-in blkid is able to determine
it. The disk/by-uuid symlink isn't created because ubifs volumes are
not on block devices but on SUBSYSTEM="ubi" devices. See #20071.
Allow ubi subsystem devices to be processed by the persistent storage
rules too. The kernel device name matching already allows ubi* to pass.
The existing rules are sufficient to create the link.
The links look like other by-uuid symlinks, for example:
/dev/disk/by-uuid/9a136158-585b-4ba4-9b70-cbaf2cf78a1c -> ../../ubi0_1
Add quotes around use of $env{MODALIAS} in rules.d/80-drivers.rules. The
modalias can contain whitespace, for example when it is dynamically generated
using device or vendor IDs.
Quoting Documentation/driver-api/vfio.rst in Linux:
> note that /dev/vfio/vfio provides no capabilities on its own and is therefore
> expected to be set to mode 0666 by the system
In IEC 61883-1:1998, we can see some values for AV/C device with vendor
unique command set in IEC 61883-1:1998. Current udev rule handles it
for video. However it brings an issue that the functions in AV/C device
are not distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Typical node of AV/C device has standard content of configuration ROM.
This is defined in documentation of 1394 Trading Association.
* Configuration ROM for AV/C Devices 1.0 (Dec. 12, 2000, 1394 Trading
Association, TA Document 1999027)
However, it brings an issue that the functions in AV/C device are not
distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Point Grey Research, inc. shipped cameras to support IIDC, however some
of them are necessarily compliant to IIDC specification in terms of the
value of software version field in unit directory of configuration ROM.
This commit adds entries for them.
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Instrumentation & Industrial Digital Camera (IIDC) specifications are
defined by 1394 Trading Association for camera device in IEEE 1394 bus.
IIDC2 specifications are defined by joint working group between Japan
Industrial Imaging Association (JIIA) and 1394 Trade Association as
bus-independent specification.
This commit adds entries for the specifications to remove existent udev
rules. Supported specifications are listed below:
* 1394-based Digital Camera Specification Version 1.04 (Aug. 9, 1996,
1394 Trading Association)
* 1394-based Digital Camera Specification Version 1.20 (Jul. 23, 1998,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.30 (Jul. 25, 2000,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.31 (Feb. 2, 2004,
1394 Trading Association, TA Document 2003017)
* IIDC Digital Camera Control Specification Ver.1.32 (Jul. 24, 2008,
1394 Trading Association, Document number 2007009)
* IIDC2 Digital Camera Control Specification Ver.1.0.0 (Jan 26th, 2012,
1394 Trading Association, TS2011001)
* IIDC2 Digital Camera Control Specification Ver.1.1.0 (May 19th, 2015,
1394 Trading Association, TS2015001)
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Some interfaces require that the DHCPOFFER message is sent via broadcast
if they can't receive unicast messages before they've been configured
with an IP address.
E.g., s390 ccwgroup network interfaces operating in layer3 mode face
this limitation. This can prevent the interfaces from receiving an
IP address via DHCP, if the have been configured for layer3.
To allow DHCP over such interfaces, we're introducing a new device
property ID_NET_DHCP_BROADCAST which can be set for those.
The networkd DHCP client will check whether this property is set
for an interface, and if so will set the broadcast flag, unless
the network configuration for the interface has an explicit
RequestBroadcast setting.
Besides that, we're adding a udev rule to set this device property
for ccwgroup devices operating in layer3 mode, which is the case
if the ID_NET_DRIVER property is qeth_l3.
Supercedes #18829
Current udev rules configures group owner of firewire character device
to video group, corresponding to nodes in IEEE 1394 in below cases:
1.the node with any unit for any minor version of IIDC version 1
specification defined by 1394 Trading Association
2.the node with any unit for specification defined by Point Grey Research
3.the node with any unit for AV/C device v1.0 defined by 1394 Trading
Association
4.the node with any unit for vendor-unique protocol defined by 1394
Trading Association
Nevertheless, case 3 and 4 can cover the node with any unit for audio
function as well. In the cases, it's convenient to assign audio group.
Additionally, some nodes are known to have layout different from
the specification defined by 1394 Trading Association. In the case,
it's required to add rules specific to them.
Furthermore, some nodes have no fields for vendor name and model name in
configuration ROM. In the case, it's required to add entries to hardware
database for users convenience.
For the above reasons, this commit adds rules to use information in
hardware database for known units in IEEE 1394. One database entry
corresponds to one unit. Two types of key are used to match the unit;
customized key from node context, kernel modalias of unit context.
The entry has the type of function, at least. Supplementally, it has
vendor and model names.
For your information, below statements with Python pyparsing module are
expected to parse all of the custom key and module alias in the list:
```
subsystem_prefix = pp.Literal('ieee1394:').suppress()
hex_to_int = lambda a: int(a[0], 16)
node_prefix = pp.Literal('node:').suppress()
prefixed_lower_hex = pp.Combine(pp.Literal('0x') + pp.Word(pp.srange('[a-z0-9]'), exact=6)).setParseAction(hex_to_int)
ven_in_node = pp.dictOf(pp.Literal('ven'), prefixed_lower_hex)
mo_in_node = pp.dictOf(pp.Literal('mo'), prefixed_lower_hex)
unit_in_node = pp.Group(prefixed_lower_hex + pp.Literal(':').suppress() + prefixed_lower_hex)
units_in_node = pp.Group(pp.Literal('units') + pp.ZeroOrMore(pp.Literal('*')).suppress() + unit_in_node + pp.ZeroOrMore(pp.Literal('*')).suppress())
node_parser = subsystem_prefix + node_prefix + ven_in_node + pp.Optional(mo_in_node) + units_in_node
higher_hex = pp.Word(pp.srange('[A-Z0-9]'), exact=8).setParseAction(hex_to_int)
ven_in_unit = pp.dictOf(pp.Literal('ven'), higher_hex)
mo_literal_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex)
mo_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex ^ pp.Literal('*'))
sp_in_unit = pp.dictOf(pp.Literal('sp'), higher_hex)
ver_in_unit = pp.dictOf(pp.Literal('ver'), higher_hex)
unit_parser = subsystem_prefix + ven_in_unit + mo_in_unit + sp_in_unit + ver_in_unit
key_parser = node_parser ^ unit_parser
```
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Closes#18669.
This creates a "well known" for sgx_enclave ownership. By doing this here we
avoid the risk that various projects making use of the device will provide
similar-but-slightly-incompatible installation instructions, in particular
using different group names.
ACLs are actually a better approach to grant access to users, but not in all
cases, so we want to provide a standard group anyway.
Mode is 0o660, not 0o666 because this is very new code and distributions are
likely to not want to give full access to all users. This might change in the
future, but being conservative is a good default in the beginning.
Rules for /dev/sgx_provision will be provided by libsg-ae-pce:
https://github.com/intel/linux-sgx/issues/678.
This reverts commit 876c75fe87.
The patch seems to cause usb devices to get some attributes set from the parent
PCI device. 'hwdb' builtin has support for breaking iteration upwards on usb
devices. But when '--subsystem=foo' is specified, iteration is continued. I'm
sure it *could* be figured out, but it seems hard to get all the combinations
correct. So let's revert to functional status quo ante, even if does the lookup
more than once unnecessarily.
Fixes#18125.
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.
Add the i2c subsystem to those that create by-path links.
i2c devices may not have IDs so we can't rely on the by-id links
but they (or some of them) should at least have a path that we can use.
/dev/vhost-net is a host accelerator for virtio net devices. It has been
long available and used, thus should be safe to all KVM users.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
/dev/vhost-vsock allows to setup a guest CID and running
state (VHOST_VSOCK_SET_GUEST_CID, VHOST_VSOCK_SET_RUNNING)
All this should be legitimate and safe for KVM users.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
/dev/vsock supports only ioctl (the only ioctl supported is
IOCTL_VM_SOCKETS_GET_LOCAL_CID), so 0666 should be okay, or 0664 if in
the future we will implement some kind of write support exposed only to
user/group.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The next libblkid v2.37 is going to support session offsets for
multi-session CD/DVDs. This feature is implemented by "hint offsets".
These offsets are optional and prober specific (e.g., iso, udf, ...).
For this purpose, the library provides a new function
blkid_probe_set_hint(), and blkid(8) provides a new command-line
option --hint <name>=<offset>. For CD/DVD, the offset name is
"session_offset".
The difference between classic --offset and the new --hint is that
--offset is very restrictive and defines the probing area and the rest
of the device is invisible to the library. The new --hint works
like a suggestion, it provides a hint where the user assumes the
filesystem, but the rest of the device is still readable for the
library (for example, to get some additional superblock information
etc.).
If the --hint is without a value then it defaults to zero.
The option --hint implementation in udev-builtin-blkid.c is backwardly
compatible. If compiled against old libblkid, then the option is used in
the same way as --offset.
Addresses: https://github.com/karelzak/util-linux/issues/1161
Addresses: https://github.com/systemd/systemd/pull/17424
Add memory_id program to set properties about the physical memory
devices in the system. This is useful on machines with removable memory
modules to show how the machine can be upgraded, and on all devices to
detect the actual RAM size, without relying on the OS accessible amount.
Closes: #16651
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>
Previous commit makes drop ID_NET_DRIVER=, ID_NET_LINK_FILE=, and
ID_NET_NAME= properties for network interfaces on 'move' uevent.
ID_NET_DRIVER= and ID_NET_LINK_FILE= properties are used by networkctl.
ID_NET_NAME= may be used by end-user rules or programs. So, let's
re-assign them on 'move' uevent. (Note that strictly speaking, this
makes them re-assigned on all but 'remove' uevent.)
Some cards have names consisting only of whitespace characters which
prevents the original rule from matching and assigning ID_SERIAL
properly. With the split rules ID_SERIAL and ID_NAME are assigned
independently and the symlink is created only if both are available the
same way it has worked for partitions.
Concatenating strings is not a very efficient approach. And in this case fully
unnecessary. We also need some rules to make use of those hwdb entries.
PCI needs to be 8 characters, not 4. And we need to use uppercase hexadecimal
for both. With udev rules this made no difference, but hwdb match is case
sensitive.
Fixes#16119.
Running the import more than once shouldn't matter, but it's a bit confusing
and causes a slowdown too. This patch reworks the rules to avoid duplicted runs,
but tries to keep the same imports. (E.g. import for pci devices without MODALIAS
is only done for tty devices.)
Note that this is only about hwdb import with argument, which uses MODALIAS as
the lookup key. There are other imports done with different lookup keys.
ATA devices should use the ATA ids like port number and (possibly)
master/slave or multiplier id, not the generic SCSI ID.
Currently only port number is included in the link. With this patch
the link would be able to support more cases, which are a) when the
device is behind a port multiplexer b) the distinction between master
and slave (distinguished by target id).
I tried to verify scenario a) with this patch, but I failed to find a
machine with PMP SATA devices attached. But the link below
https://github.com/systemd/systemd/issues/3943
could show what's the difference. Here is my test for scenario b)
Current version:
linux-ql21:~ # ll /sys/class/block/sd[ab]
lrwxrwxrwx 1 root root 0 May 8 20:46 /sys/class/block/sda ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:0/3:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 May 8 20:46 /sys/class/block/sdb ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:1/3:0:1:0/block/sdb
linux-ql21:~ # ll /dev/disk/by-path/pci-0000\:00\:01.1-ata-1
lrwxrwxrwx 1 root root 9 May 8 20:44
/dev/disk/by-path/pci-0000:00:01.1-ata-1 -> ../../sdb
linux-ql21:~ # udevadm info /sys/class/block/sda |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1
E: DEVLINKS=/dev/disk/by-id/ata-VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-path/pci-0000:00:01.1-ata-1
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
linux-ql21:~ # udevadm info /sys/class/block/sdb |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1
E: DEVLINKS=/dev/disk/by-id/ata-VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-path/pci-0000:00:01.1-ata-1
After patch applied:
linux-ql21:~ # ll /sys/class/block/sd[ab]
lrwxrwxrwx 1 root root 0 May 8 21:07 /sys/class/block/sda ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:0/3:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 May 8 21:07 /sys/class/block/sdb ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:1/3:0:1:0/block/sdb
linux-ql21:~ # ll /dev/disk/by-path/pci-0000\:00\:01.1-ata-*
lrwxrwxrwx 1 root root 9 May 8 21:07
/dev/disk/by-path/pci-0000:00:01.1-ata-1.0 -> ../../sda
lrwxrwxrwx 1 root root 9 May 8 21:07
/dev/disk/by-path/pci-0000:00:01.1-ata-1.1 -> ../../sdb
linux-ql21:~ # udevadm info /sys/class/block/sda |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1.0
E: DEVLINKS=/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/ata-VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-path/pci-0000:00:01.1-ata-1.0
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
linux-ql21:~ # udevadm info /sys/class/block/sdb |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1.1
E: DEVLINKS=/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/ata-VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-path/pci-0000:00:01.1-ata-1.1
Changelog:
v5: add another parameter compat_link in handle_scsi()
v4: comment for ID_PATH_ATA_COMPAT
get string length with pointer difference
(suggested by Franck Bui<fbui@suse.com>)
v3: creating compatible link from env
variables type change
v2: remove udev rules modification for compatible link
setup a test scenario of master/slave ATA devices
v1: initial patch
RUN seems to be used primarily for historical reasons over the more
immediate IMPORT command. As a side-effect, RUN also runs *after* all the
rules have been processed which is not really what we want here - we expect
the device to be updated immediately. Other rules that rely on accurate evdev
axes should be able to assume the axes are already present. So let's use
IMPORT here.
For consistency, the second two rules are split across multiple lines as well.
When probing partitions, we inherit important information from the parent
disk device such as ID_MODEL, and usage of such properties is seen to
be acceptable and well established.
However, we need to exclude filesystem information from the properties
that get inherited. Information about the device content should not be
passed on in this way.
For example, Linux distro install media commonly uses an ISO filesystem
plus a partition table. The ISO filesystem is detected on the main disk
device, but we should not pass down those details to the partitions,
some or all of which may be pointing at storage areas completely distinct
from the ISO filesystem.
This is particularly problematic when adding new partitions on media
set up in this way (since the new partitions are then reported to contain
the parent device's ISO filesystem), or when dealing with more unusual
hybrid ISO layouts. The inaccuracy of information here inversely affects
users of blkid and udev's persistent storage symlinks.
Exclude ID_FS_* properties from the inheritance chain to avoid these
problems.
Fixes: #14408
This adds a udev tag that is supposed to be attached to all devices
that might potentially expose a PKCS#11 slot, i.e. CCID smartcards and
similar. We can then use the appearance of devices of this type as
trigger to rescan PKCS#11 slots.
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.
