Age | Commit message (Collapse) | Author |
|
|
|
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
|
|
|
|
|
|
https://launchpad.net/bugs/922405
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
|
|
|
|
Udev does no longer automatically create udev rules in /etc from the
device hotplug path.
No device name reservation will happen anymore; this model creates
too many problems for setups with many device changes or media which
is booted on different hardware.
Enumerated device names which are based on device discovery order or
on persistent on-disk name reservation will in general not be supported
by udev in the future. It is a problem that can not be solved properly,
and it always creates new problems at the same time it tries to solve
the original one. Udev will no longer pretend it can solve these issues,
and people should switch to available alternatives which provide the
far better compromise.
From now on, udev will only create /dev/cdrom for the first optical
drive, and if the drive is capable /dev/dvd. No other devices will
get any compatibility symlinks or enumerated device names like cdrom1,
cdrom2, and so on. The /dev/cdrom and /dev/dvd links have by default
a negative link priority, which will cause them to be overwritten by
any other device which clains the same names with already existing
udev rules.
If stable device names are needed, the /dev/disk/by-id/ links, which
uniquely identify a specific piece of hardware should be used. The links
usually contain a device serial number and the link names will not depend
on device discovery order.
If completely identical devices with identical or no serial number
need to be handled at the same time, the /dev/disk/by-path/ links can
be used. These links depend on the physical port which is used to connect
the device. It will change when the same device is moved to a different
port or host adapter.
If custom names are needed, custom udev rules which match on specific
device properties need to be added by the administrator.
|
|
Device nodes might have been deleted again by the kernel before an
'add' or 'change' event is even started. We need to run all rules,
regardless of the state in /dev.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When we read the 'uevent' file we need to make sure, that we do not
read the relative DEVNAME= path provided by the kernel and overwrite
the absolute path udev expects here.
|
|
|
|
https://launchpad.net/bugs/901513
|
|
https://launchpad.net/bugs/902332
|
|
https://launchpad.net/bugs/902798
|
|
https://bugs.launchpad.net/bugs/914838
|
|
Some broken kernel drivers load firmware synchronously in the module init
path and block modprobe until the firmware request is fulfilled.
The modprobe-generated firmware request is a direct child device of the
device which caused modprobe to run. Child device event are blocked until
the parent device is handled. This dead-locks until the kernel firmware
loading timeout of 60 seconds is reached.
The hanging modprobe event should now time-out and allow the firmware
event to run before the 60 second kernel timeout.
|
|
<ridikulus_rat> 60-persistent-storage.rules gpt by-partlabel/by-partuuid
symlinks not created in udev-177 util-linux-2.20.1 kmod-3 in Archlinux x86_64.
<falconindy> ridikulus_rat: fix the rule, or fix the blkid builtin ;)
<kay> oh, i missed the ID_ stuff? :)
|
|
- Include exported package information
- Include C include information
- g_udev_device_get_parent & g_udev_device_get_parent_with_subsystem
transfer ownership of their return values
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|