| Age | Commit message (Collapse) | Author |
|---|
|
Sometimes, the persistent storage rules should be skipped for a subset
of devices. For example, the Qubes operating system prevents dom0 from
parsing untrusted block device content (such as filesystem metadata) by
shipping a custom 60-persistent-storage.rules, patched to bail out early
if the device name matches a hardcoded pattern.
As a less brittle and more flexible alternative, this commit adds a line
to the two relevant .rules files which makes them test the value of the
UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG device property, modeled
after the various DM_UDEV_DISABLE_*_RULES_FLAG properties.
|
|
Persistent memory devices can be exposed as block devices as /dev/pmemN
and /dev/pmemNs. pmemN is the raw device and is byte-addressable from
within the kernel and when mmapped by applications from a DAX-mounted
file system. pmemNs has the block translation table (BTT) layered on top,
offering atomic sector/block access. Both pmemN and pmemNs are expected
to contain file systems.
blkid(8) and lsblk(8) seem to correctly report on pmemN and pmemNs.
systemd v219 will populate /dev/disk/by-uuid/ when, for example, mkfs is
used on pmem, but systemd v228 does not.
Add pmem to the whitelist.
|
|
Add a new key ID_INPUT_TOUCHPAD_INTEGRATION=internal|external so we have a
single source for figuring out which touchpads are built-in.
Fairly simple approach: bluetooth is external, usb is external unless it's an
Apple touchpad. Everything else is internal.
|
|
Something has to so we can have udev rules rely on this. Right now the ID_BUS
setting is inconsistent: usb is set, ata and pci are set, bluetooth is not
set, rmi is too new to be featured.
70-mouse even relied on bluetooth even though it was never set
|
|
Since the introduction of the whitelist in 60-persistent-storage.rules
block device symlinks are no longer created for scm block devices.
Add scm to the whitelist.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
|
|
blkid reports PARTUUID values also for partitions that are defined by a
dos partitioning scheme. Instead of limiting the partitioning scheme to
"gpt or dos" just drop the test for the partitioning scheme and trust
blkid to do the right thing.
|
|
Add NVMe rules using the "wwid" attribute.
root@target:~# cat /sys/block/nvme0n1/wwid
eui.3825004235000591
root@target:~# ls /dev/disk/by-id/ -l |grep nvme
lrwxrwxrwx 1 root root 13 Apr 27 16:08 nvme-eui.3825004235000591 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Apr 27 16:08 nvme-eui.3825004235000591-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Apr 27 16:08 nvme-eui.3825004235000591-part2 -> ../../nvme0n1p2
|
|
Currently, 99-systemd.rules.in contains a line for network block
devices, which mark them as inactive until the first change event, and
as active from then on forward. This is not correct. A network block
device can be connected or disconnected; this state is signalled by the
presence or absense of a "pid" file, which contains the PID of the
nbd client userspace process that started the connection.
Update the rules file so that it checks for the presence of that file to
decide what to set SYSTEMD_READY to.
Note that current kernels do issue a change event upon connecting the
device, but not yet upon disconnecting. While it's possible to wait
until that's been fixed, the behaviour of the rule with TEST!="pid" in
the absence of a proper uevent is exactly the same as the behaviour of
the old rule; so it should be safe to apply now.
Signed-off-by: Wouter Verhelst <w@uter.be>
|
|
ADD event (#2747)
The "SYSTEMD_READY=0" will cause automatic unmount
of mountpoint that is on top of such DM device
if this is used with multipath which sets
DM_UDEV_DISABLE_OTHER_RULES_FLAG in case
we have a CHANGE event thatcomes after DM multipath
device reload when one of the paths is down or up.
See https://bugzilla.redhat.com/show_bug.cgi?id=1312011
|
|
With this rework we introduce systemd-rfkill.service as singleton that
is activated via systemd-rfkill.socket that listens on /dev/rfkill. That
way, we get notified each time a new rfkill device shows up or changes
state, in which case we restore and save its current setting to disk.
This is nicer than the previous logic, as this means we save/restore
state even of rfkill devices that are around only intermittently, and
save/restore the state even if the system is shutdown abruptly instead
of cleanly.
This implements what I suggested in #1019 and obsoletes it.
|
|
User mode linux block devices start with ubd, e.g. ubda, ubdb, etc..
|
|
|
|
udev: Remove accelerometer helper
|
|
Do not skip the persistent storage rules for cciss devices
|
|
It's moved to the iio-sensor-proxy D-Bus service.
|
|
rules: remove all power management from udev
|
|
The main purpose of this hwdb was to tag touchpads that have the physical
trackstick buttons wired to the touchpad (Lenovo Carbon X1 3rd, Lenovo *50
series). This hwdb is not required on kernels 4.0 and above, the kernel now
re-routes button presses through the trackstick's device node. Userspace does
not need to do anything.
See kernel commit cdd9dc195916ef5644cfac079094c3c1d1616e4c.
This reverts commit 001a247324b44c0e0b8fdba41a6fc66e7465b8b6.
|
|
It is not udev's task to apply any of these setting that way, or
from udev rules files. Things need to be sortet out in the kernel,
or explicit whitelist can possibly be added to the hardware database.
Until that is sorted out, and general agreement, udev is not
willing to maintain any such lists or power management settings
in general.
"Thanks for digging this out! I thought my Kinesis keyboard got broken
and ordered a new one, only to find out that the new one doesn't work
as well. I'm not sure whether we should start collecting a blacklist
of keyboards which don't work with USB autosuspend, or rather a
whitelist? Or revert this wholesale?"
https://github.com/systemd/systemd/issues/340
|
|
The original commit (1aff206) doesn't explain why these were removed.
This adds them back since they are in fact needed.
|
|
Xen disks need to be whitelisted as well.
|
|
Without this, systemd-udevd does not create persistent storage symlinks
for xen block devices.
|
|
https://bugs.debian.org/787367
|
|
When processing an event, the watch is disabled, make sure it is restorted after
a CHANGE event has been processed.
|
|
The intention was to turn this rule from using a blacklist to a whitelist, but
there was a stray '!'.
|
|
USB and PCI soundcards have a nice set of ID_* properties. It would
be handy for firewire soundcards to have the same.
Note that this removes the explicit setting of ID_ID in the firewire
conditional. Because we are now setting ID_SERIAL, ID_ID will come
from later in the file.
|
|
The ALSA id sysattr is generated by the sound subsystem and is not
a stable identifier. It is generated though some string manipulation
then made unique if there is a conflict. This means that it is
enumeration-dependent and shouldn't be used for ID_ID.
If ID_ID is supposed to be system-unique, it is not already since
for firewire it is generated from the guid and there are broken
firewire devices that have duplicate guids across devices.
This is tracked for PulseAudio at
https://bugs.freedesktop.org/show_bug.cgi?id=90129.
This is essentially a revert of systemd
ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e.
|
|
Fixup for 51c0c2869845a058268d54c3111d55d0dd485704.
|
|
We only care about whether our direct parent is removable, not whether any
further points up the tree are - the kernel will take care of policy for
those itself. This enables autosuspend on devices where the root hub reports
that its removable state is unknown.
|
|
Parse properties in the form
EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>"
and apply them to the kernel device. Future processes that open that device
will see the updated EV_ABS range.
This is particularly useful for touchpads that don't provide a resolution in
the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).
All values in the property are optional, e.g. a string of "::45" is valid to
set the resolution to 45.
The order intentionally orders resolution before fuzz and flat despite it
being the last element in the absinfo struct. The use-case for setting
fuzz/flat is almost non-existent, resolution is probably the most common case
we'll need.
To avoid multiple hwdb invocations for the same device, replace the
hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules
file. The new 60-evdev.rules is called for all event nodes
anyway, we don't need a separate rules file and second callout to the hwdb
builtin.
|
|
we don't want to run usb_id and input_id on ACTION=="remove"
|
|
These are handled by a different driver than MemoryStick Pro.
|
|
On Mon, Mar 23, 2015 at 8:55 AM, Mantas Mikulėnas <grawity@gmail.com> wrote:
> On Tue, Mar 17, 2015 at 11:50 PM, Kay Sievers <kay@vrfy.org> wrote:
>> On Tue, Mar 17, 2015 at 5:00 PM, Mantas Mikulėnas <grawity@gmail.com>
>> wrote:
>> > Accidentally dropped in 1aff20687f4868575.
>> > ---
>> > rules/60-persistent-storage.rules | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> > +KERNEL!="loop*|mmcblk[0-9]*|mspblk[0-9]*|nvme*|sd*|sr*|vd*",
>> > GOTO="persistent_storage_end"
>>
>> We can't do that, we need to ignore the mmc*rpmb devices:
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01cf83947f467f3c46d9831cd67955fc46b9
>>
>> Maybe "mmcblk*[0-9]" will work?
>
> Yeah, that would probably work (the names are like mmcblk0p1 etc.)
|
|
This line was accidentally lost in 52346b5f5424.
|
|
We should never access parents, as the sysfs hierarchy is in no way
stable. Use KERNELS== etc. to match on a parent, then access it via
$attr{} (which accesses the matching device, not the current device).
|
|
We match on the evdev node, but only the parent has a "name" attribute.
Use $attr{device/name} to access it.
This is borked since 2013, I wonder how that ever worked? Maybe this will
suddenly fix all the DMI-based key detections.
Thanks to Peter Hutterer for catching this!
|
|
|
|
|
|
This reverts commit ba76ee29bc02879fb42c048132af8889b00220d5. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
|
|
|
|
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
|
|
The 60-keyboard rules are already guared by KERNEL!="event*" bail-outs,
therefore, KERNELS="input*" is always true. Drop it!
|
|
Drop the restriction not to match on bluetooth devices. They are supported
just fine!
|
|
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
|
|
|
|
|
|
|
|
|
|
|
|
Newly added kernel drivers repeatedly pass our blacklist and
cause trouble for the devices, because they do not expect to
be examined by udev's default rules which include blkid.
This turns the blacklist into a whitelist. Device type which
need support for additional symlinks need to be added to the
whitelist now.
Note, that the by-id, by-path symlinks are only intended for
hotpluggable devices. There is no reason for exotic, or for
statically configured devices to provide them.
|
|
We don't actually want a by-path/ symlink for MMC RPMB devices, so just add
them to the blacklist. This will prevent creating wrong by-path links and
blkid'ing those.
|
