Difference between revisions of "Udev"

From ArchWiki
Jump to: navigation, search
(Network device: I had to add ACTION=="add" for it to work)
m (Execute on VGA cable plug in: improve style)
 
(144 intermediate revisions by 51 users not shown)
Line 1: Line 1:
 +
{{Lowercase title}}
 
[[Category:Hardware detection and troubleshooting]]
 
[[Category:Hardware detection and troubleshooting]]
 
[[cs:Udev]]
 
[[cs:Udev]]
 
[[de:Udev]]
 
[[de:Udev]]
 
[[es:Udev]]
 
[[es:Udev]]
 +
[[fr:Udev]]
 
[[it:Udev]]
 
[[it:Udev]]
 +
[[ja:Udev]]
 
[[ru:Udev]]
 
[[ru:Udev]]
 
[[zh-CN:Udev]]
 
[[zh-CN:Udev]]
 
[[zh-TW:Udev]]
 
[[zh-TW:Udev]]
{{Lowercase title}}
+
{{Related articles start}}
{{ic|udev}} replaces the functionality of both {{ic|hotplug}} and {{ic|hwdetect}}.
+
{{Related|udisks}}
 +
{{Related articles end}}
  
''"Udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{ic|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{ic|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev|Wikipedia article]]
+
From [[Wikipedia:udev|Wikipedia article]]:
 +
 
 +
:udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the {{ic|/dev}} directory. At the same time, udev also handles all user space events raised while hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.
 +
 
 +
{{ic|udev}} replaces the functionality of both {{ic|hotplug}} and {{ic|hwdetect}}.
  
 
Udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.
 
Udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.
Line 16: Line 24:
 
== Installation ==
 
== Installation ==
  
Udev is now part of {{Pkg|systemd}} and is installed by default on Arch Linux systems.
+
Udev is now part of {{Pkg|systemd}} and is installed by default. See the {{ic|systemd-udevd.service(8)}} [[man page]] for information.
 +
 
 +
A standalone fork is available in AUR: [[eudev]].
  
 
== About udev rules ==
 
== About udev rules ==
  
Udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with {{ic|.rules}}. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.
+
Udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with ''.rules''. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.
  
If you want to learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].
+
=== Writing udev rules ===
 +
 
 +
{{Expansion|You can workaround the FUSE errors (caused by udev killing the mount process) by using a systemd service [https://github.com/Ferk/udev-media-automount] [http://jasonwryan.com/blog/2014/01/20/udev/]}}
 +
 
 +
{{Warning|To mount removable drives, do not call {{ic|mount}} from udev rules. In case of FUSE filesystems, you will get {{ic|Transport endpoint not connected}} errors. Instead, you could use [[udisks]] that handles automount correctly or to make mount work inside udev rules, copy {{ic|/usr/lib/systemd/system/systemd-udevd.service}} to {{ic|/etc/systemd/system/systemd-udevd.service}} and replace {{ic|1=MountFlags=slave}} to {{ic|1=MountFlags=shared}}.[http://unix.stackexchange.com/a/154318] Keep in mind though that udev is not intended to invoke long-running processes.}}
 +
 
 +
* To learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].
 +
* To see an example udev rule, follow the [http://www.reactivated.net/writing_udev_rules.html#example-printer Examples] section of the above guide.
 +
 
 +
This is an example of a rule that places a symlink {{ic|/dev/video-cam1}} when a webcamera is connected. First, we have found out that this camera is connected and has loaded with the device {{ic|/dev/video2}}. The reason for writing this rule is that at the next boot the device might just as well show up under a different name like {{ic|/dev/video0}}.
 +
 
 +
{{hc|# udevadm info -a -p $(udevadm info -q path -n /dev/video2)|<nowiki>
 +
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.
 +
 
 +
  looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
 +
    KERNEL=="video2"
 +
    SUBSYSTEM=="video4linux"
 +
    ...
 +
  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
 +
    KERNELS=="3-2:1.0"
 +
    SUBSYSTEMS=="usb"
 +
    ...
 +
  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
 +
    KERNELS=="3-2"
 +
    SUBSYSTEMS=="usb"
 +
    ...
 +
    ATTRS{idVendor}=="05a9"
 +
    ...
 +
    ATTRS{manufacturer}=="OmniVision Technologies, Inc."
 +
    ATTRS{removable}=="unknown"
 +
    ATTRS{idProduct}=="4519"
 +
    ATTRS{bDeviceClass}=="00"
 +
    ATTRS{product}=="USB Camera"
 +
    ...
 +
</nowiki>}}
 +
 
 +
From the video4linux device we use {{ic|<nowiki>KERNEL=="video2"</nowiki>}} and {{ic|<nowiki>SUBSYSTEM=="video4linux"</nowiki>}}, then we match the webcam using vendor and product ID's from the usb parent {{ic|<nowiki>SUBSYSTEMS=="usb"</nowiki>}}, {{ic|<nowiki>ATTRS{idVendor}=="05a9"</nowiki>}} and {{ic|<nowiki>ATTRS{idProduct}=="4519"</nowiki>}}.
 +
 
 +
{{hc|/etc/udev/rules.d/83-webcam.rules|<nowiki>
 +
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
 +
</nowiki>}}
 +
 
 +
In the example above we create a symlink using {{ic|<nowiki>SYMLINK+="video-cam1"</nowiki>}} but we could easily set user {{ic|<nowiki>OWNER="john"</nowiki>}} or group using {{ic|<nowiki>GROUP="video"</nowiki>}} or set the permissions using {{ic|<nowiki>MODE="0660"</nowiki>}}. However, if you intend to write a rule to do something when a device is being removed, be aware that device attributes may not be accessible. In this case, you will have to work with preset device [[environment variables]]. To monitor those environment variables, execute the following command while unplugging your device:
 +
 
 +
# udevadm monitor --environment --udev
 +
 
 +
In this command's output, you will see value pairs such as ID_VENDOR_ID and ID_MODEL_ID, which match your previously used attributes "idVendor" and "idProduct". A rule that uses device environment variables may look like this:
 +
 
 +
{{hc|/etc/udev/rules.d/83-webcam-removed.rules|<nowiki>
 +
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="/path/to/your/script"
 +
</nowiki>}}
 +
 
 +
=== List attributes of a device ===
  
 
To get a list of all of the attributes of a device you can use to write rules, run this command:
 
To get a list of all of the attributes of a device you can use to write rules, run this command:
 +
 
  # udevadm info -a -n [device name]
 
  # udevadm info -a -n [device name]
  
 
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.
 
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.
  
Udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.
+
If you do not know the device name you can also list all attributes of a specific system path:
  
== Udisks ==
+
# udevadm info -a -p /sys/class/backlight/acpi_video0
  
Simply [[pacman|install]] the {{Pkg|udisks}} package, and all of your media should be automatically mounted in [[GNOME]] and [[KDE]] SC 4.6. There is no need for any additional rules this way. Be aware that udisks2 is a compatibility-breaking rewrite of udisks and is the version currently [https://www.archlinux.org/packages/extra/x86_64/udisks2/ required] by GNOME, whereas XFCE and KDE seem to still [https://www.archlinux.org/packages/extra/x86_64/udisks/ require] udisks.
+
=== Testing rules before loading ===
+
As an extra bonus you can remove [[HAL]] if you were only using that for auto mounting purposes.
+
  
=== Automounting udisks wrappers ===
+
# udevadm test $(udevadm info -q path -n [device name]) 2>&1
  
A udisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.
+
This will not perform all actions in your new rules but it will however process symlink rules on existing devices which might come in handy if you are unable to load them otherwise. You can also directly provide the path to the device you want to test the udev rule for:
  
* [http://ignorantguru.github.com/udevil/ udevil] - {{pkg|udevil}} "''mounts and unmounts removable devices without a password, shows device info, and monitors device changes''". It is written in C and can replace UDisks and includes [http://igurublog.wordpress.com/downloads/script-devmon/ devmon], which can be installed separately from the AUR ({{AUR|devmon}}). It can also selectively automatically start applications or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives.
+
# udevadm test /sys/class/backlight/acpi_video0/
* {{AUR|ldm}} - A lightweight daemon that mounts usb drives, cds, dvds or floppys automagically. [https://bbs.archlinux.org/viewtopic.php?id=125918]
+
* [[udiskie]] - Written in Python. Enables automatic mounting and unmounting by any user.
+
* {{AUR|udisksevt}} - Written in Haskell. Enables automatic mounting by any user. Designed to be integrated with {{AUR|traydevice}}.
+
* {{AUR|udisksvm}} - A GUI UDisks wrapper which uses the udisks2 dbus interface. It calls a 'traydvm' script, included in the package. The 'traydvm' GUI utility is a script which displays a systray icon for a plugged-in device, with a right-click menu to perform simple actions on the device. As the automount function can be disabled, this tool should work with other automounting tools, to show system tray icons. It is independent of any file manager.
+
* You can easily automount and eject removable devices with the combination of {{pkg|pmount}}, {{pkg|udisks2}} and {{pkg|spacefm}}. Note you have to run spacefm in daemon mode with {{ic|spacefm -d &}} in your startup scripts, {{ic|~/.xinitrc}} or {{ic|~/.xsession}}, to get automounting. You can also mount internal disks by adding them to {{ic|/etc/pmount.allow}}.
+
  
=== Udisks shell functions ===
+
=== Loading new rules ===
  
While udisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.
+
Udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices. Hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect, or at least unloading and reloading the ohci-hcd and ehci-hcd kernel modules and thereby reloading all USB drivers.
  
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.
+
If rules fail to reload automatically
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - {{AUR|bashmount}} is a menu-driven Bash script with a configuration file that makes it easy to configure and extend.
+
 
 +
# udevadm control --reload
 +
 
 +
To manually force udev to trigger your rules
 +
 
 +
# udevadm trigger
 +
 
 +
== Udisks ==
 +
 
 +
See [[Udisks]].
  
 
== Tips and tricks ==
 
== Tips and tricks ==
  
 
=== Accessing firmware programmers and USB virtual comm devices ===
 
=== Accessing firmware programmers and USB virtual comm devices ===
 +
 +
{{Accuracy|Making a device world-writable is not secure.}}
 +
{{Style|One example is enough, others can surely be found with {{ic|lsusb}}.}}
  
 
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter, the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer, and the [http://www.atmel.com/tools/AVRISPMKII.aspx Atmel AVR ISP mkII]. Adjust the permissions accordingly. Verified as of 31-10-2012.
 
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter, the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer, and the [http://www.atmel.com/tools/AVRISPMKII.aspx Atmel AVR ISP mkII]. Adjust the permissions accordingly. Verified as of 31-10-2012.
Line 65: Line 133:
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"
 +
 
# USBasp Programmer rules http://www.fischl.de/usbasp/
 
# USBasp Programmer rules http://www.fischl.de/usbasp/
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"
 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"
Line 79: Line 148:
 
#Atmel Corp. AVR ISP mkII
 
#Atmel Corp. AVR ISP mkII
 
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0666"
 
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0666"
 +
 +
#Atmel Copr. JTAGICE3
 +
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2140", GROUP="users", MODE="0666"
 
</nowiki>}}
 
</nowiki>}}
  
Line 84: Line 156:
  
 
See the [[Execute on USB insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].
 
See the [[Execute on USB insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].
 +
 +
=== Execute on VGA cable plug in ===
 +
 +
Create the rule {{ic|/etc/udev/rules.d/95-monitor-hotplug.rules}} with the following content to launch {{Pkg|arandr}} on plug in of a VGA monitor cable:
 +
 +
KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/''username''/.Xauthority", RUN+="/usr/bin/arandr"
 +
 +
Some display managers store the .Xauthority outside the user home directory. You will need to update the ENV{XAUTHORITY} accordingly. As an example [[GDM|GNOME Display Manager]] looks as follows:
 +
 +
{{hc|$ printenv XAUTHORITY|/run/user/1000/gdm/Xauthority}}
 +
 +
=== Detect new eSATA drives ===
 +
 +
If your eSATA drive is not detected when you plug it in, there are a few things you can try. You can reboot with the eSATA plugged in. Or you could try
 +
 +
# echo 0 0 0 | tee /sys/class/scsi_host/host*/scan
 +
 +
Or you could install {{AUR|scsiadd}} (from the AUR) and try
 +
 +
# scsiadd -s
 +
 +
Hopefully, your drive is now in {{ic|/dev}}. If it is not, you could try the above commands while running
 +
 +
# udevadm monitor
 +
 +
to see if anything is actually happening.
  
 
=== Mark internal SATA ports as eSATA ===
 
=== Mark internal SATA ports as eSATA ===
  
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. GNOME and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal GNOME user can connect their eSATA drives to that port like a USB drive, without any root password and so on.
+
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. [[GNOME]] and [[KDE]] will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal GNOME user can connect their eSATA drives to that port like a USB drive, without any root password and so on.
  
 
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki>
 
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki>
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"
+
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
 
</nowiki>}}
 
</nowiki>}}
  
{{Note|The DEVPATH can be found after connection the eSATA drive with the following command (replace {{ic|sdb}} accordingly):
+
{{Note|The {{ic|DEVPATH}} can be found after connection the eSATA drive with the following commands (replace {{ic|sdb}} accordingly):
 +
 
 +
# udevadm info -q path -n /dev/sdb
 +
/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
  
 
  # find /sys/devices/ -name sdb
 
  # find /sys/devices/ -name sdb
 
  /sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
 
  /sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
 
 
}}
 
}}
  
 
=== Setting static device names ===
 
=== Setting static device names ===
  
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. A udev rule can be added to use static device names, but preferably names other than "ethX" and "wlanX".
+
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. A udev rule can be added to use static device names.
  
For block devices, see [[Persistent block device naming]].
+
See also [[Persistent block device naming]] for block devices and [[Network configuration#Device names]] for network devices.
  
==== Network device ====
+
==== Video devices ====
  
With multiple network interfaces, the names may change between {{Ic|eth0}} and {{Ic|eth1}} between reboots. To prevent this, it is recommended to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:
+
For setting up the webcam in the first place, refer to [[Webcam setup#Webcam configuration|Webcam configuration]].
  
{{hc|/etc/udev/rules.d/10-network.rules|2=
+
Using multiple webcams, useful for example with {{pkg|motion}} (software motion detector which grabs images from video4linux devices and/or from webcams), will assign video devices as /dev/video0..n randomly on boot. The recommended solution is to create symlinks using an ''udev'' rule (as in the example in [[#Writing udev rules]]):
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"
+
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"
+
}}
+
  
A couple things to note:
+
{{hc|/etc/udev/rules.d/83-webcam.rules|<nowiki>
 +
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
 +
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"
 +
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0840", SYMLINK+="video-cam3"
 +
</nowiki>}}
  
* To get the MAC address of each card, use this command: {{ic|cat /sys/class/net/'''device-name'''/address}}<!-- {{ic|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}} -->
+
{{Note|Using names other than {{ic|/dev/video*}} will break preloading of {{ic|v4l1compat.so}} and perhaps {{ic|v4l2convert.so}}}}
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.
+
* When choosing the static names it should be avoided to use "ethX" and "wlanX", because this may lead to race conditions between the kernel and udev during boot. Instead, it is better to use interface names that are not used by the kernel as default, e.g. "net0, net1, wifi0, wifi1".
+
  
Don't forget to update your other configuration files using the old ethX notation!
+
==== Printers ====
  
See also: [[Rename network interfaces]].
+
If you use multiple printers, {{ic|/dev/lp[0-9]}} devices will be assigned randomly on boot, which will break e.g. [[CUPS]] configuration.  
  
==== iscsi device ====
+
You can create following rule, which will create symlinks under {{ic|/dev/lp/by-id}} and {{ic|/dev/lp/by-path}}, similar to [[Persistent block device naming]] scheme:
  
Test the output from scsi_id:
+
{{hc|/etc/udev/rules.d/60-persistent-printer.rules|<nowiki>
 +
ACTION=="remove", GOTO="persistent_printer_end"
  
/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb
+
# This should not be necessary
3600601607db11e0013ab5a8e371ce111
+
#KERNEL!="lp*", GOTO="persistent_printer_end"
  
{{hc|/etc/udev/rules.d/75-iscsi.rules|2=
+
SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
#The iscsi device rules.
+
ENV{ID_TYPE}!="printer", GOTO="persistent_printer_end"
#This will create an iscsi device for each of the targets.
+
 
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600601607db11e0013ab5a8e371ce111",
+
ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
NAME="isda"}}
+
 
 +
IMPORT{builtin}="path_id"
 +
ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"
 +
 
 +
LABEL="persistent_printer_end"
 +
</nowiki>}}
 +
 
 +
==== USB flash device ====
 +
 
 +
USB flash devices usually contain partitions, and partition labels are one way to have a static naming for a device. Another way is to create a udev rule for it.
 +
 +
Get the serial number and USB ids from the USB flash drive (if you use multiple of the same make, you might have to check the serial is indeed unique):
 +
lsusb -v | grep -A 5 Vendor
 +
 
 +
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:
 +
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", ATTRS{idVendor}=="$VENDOR", ATTRS{idProduct}=="$PRODUCT" SYMLINK+="$SYMLINK%n"
 +
 
 +
Replace {{ic|$SERIAL}}, {{ic|$VENDOR}}, {{ic|$PRODUCT}} from above output accordingly and {{ic|$SYMLINK}} with the desired name. {{ic|%n}} will expand to the partition number. For example, if the device has two partitions, two symlinks will be created. You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).
 +
 
 +
Rescan sysfs:
 +
udevadm trigger
 +
Now check the contents of {{ic|/dev}}:
 +
ls /dev
 +
It should show the device with the desired name.
 +
 
 +
=== Waking from suspend with USB device ===
 +
 
 +
First, find vendor and product ID of your device, for example
 +
 
 +
{{hc|<nowiki># lsusb | grep Logitech</nowiki>|Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver}}
 +
 
 +
Now change the {{ic|power/wakeup}} attribute of the device and the USB controller it is connected to, which is in this case {{ic|driver/usb7/power/wakeup}}. Use the following rule:
 +
 
 +
{{hc|/etc/udev/rules.d/50-wake-on-device.rules|<nowiki>
 +
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled", ATTR{driver/usb7/power/wakeup}="enabled"
 +
</nowiki>}}
 +
 
 +
{{Note|Also make sure the USB controller is enabled in {{ic|/proc/acpi/wakeup}}.}}
 +
 
 +
=== Triggering events ===
 +
 
 +
{{Merge|#Testing rules before loading|similar trick}}
 +
 
 +
It can be useful to trigger various udev events. For example, you might want to simulate a USB device disconnect on a remote machine. In such cases, use {{ic|udevadm trigger}}:
 +
 
 +
# udevadm trigger -v -t subsystems -c remove -s usb -a "idVendor=abcd"
 +
 
 +
This command will trigger a USB remove event on all USB devices with vendor ID {{ic|abcd}}.
  
 
== Troubleshooting ==
 
== Troubleshooting ==
Line 143: Line 290:
  
 
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).
 
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).
 +
 +
=== Debug output ===
 +
 +
To get hardware debug info, use the [[kernel parameter]] {{ic|1=udev.log-priority=debug}}. Alternatively you can set
 +
 +
{{hc|/etc/udev/udev.conf|2=udev_log="debug"}}
 +
 +
This option can also be compiled into your initramfs by adding the config file to your {{ic|FILES}} array
 +
 +
{{hc|/etc/mkinitcpio.conf|2=FILES="... /etc/udev/udev.conf"}}
 +
 +
and then rebuilding the initramfs with
 +
 +
# mkinitcpio -p linux
  
 
=== udevd hangs at boot ===
 
=== udevd hangs at boot ===
Line 169: Line 330:
 
  ...
 
  ...
  
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:
+
In this case, the {{ic|pcscd}} group is for some reason not present in the system. [[Users and groups#Group management|Add the missing groups]]. Also, make sure that local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the following line:
  
  # groupadd pcscd
+
  group: files ldap
  
Also, make sure that local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the following line:
+
=== BusLogic devices can be broken and will cause a freeze during startup ===
  
group: files ldap
+
This is a kernel bug and no fix has been provided yet.
  
=== Known problems with hardware ===
+
=== Some devices, that should be treated as removable, are not ===
  
==== BusLogic devices can be broken and will cause a freeze during startup ====
+
You need to create a custom udev rule for that particular device. To get definitive information of the device you can use either {{ic|ID_SERIAL}} or {{ic|ID_SERIAL_SHORT}} (remember to change {{ic|/dev/sdb}} if needed):
  
This is a kernel bug and no fix has been provided yet.
+
$ udevadm info /dev/sdb | grep ID_SERIAL
  
==== Some devices, that should be treated as removable, are not ====
+
Then we create a rule in {{ic|/etc/udev/rules.d/}} and set variables for either udisks or udisks2.
  
Create a custom udev rule, setting {{ic|UDISKS_SYSTEM_INTERNAL<nowiki>=</nowiki>0}}. For more details, see the manpage of udisks.
+
For udisks, set {{ic|1=UDISKS_SYSTEM_INTERNAL="0"}}, which will mark the device as "removable" and thus "eligible for automounting". See [http://udisks.freedesktop.org/docs/1.0.5/udisks.7.html udisks(7)] for details.
  
=== Known problems with auto-loading ===
+
{{hc|/etc/udev/rules.d/50-external-myhomedisk.rules|2=
 +
ENV{ID_SERIAL_SHORT}=="''serial_number''", ENV{UDISKS_SYSTEM_INTERNAL}="0"
 +
}}
  
==== Sound problems with some modules not loaded automatically ====
+
For udisks2, set {{ic|1=UDISKS_AUTO="1"}} to mark the device for automounting and {{ic|1=UDISKS_SYSTEM="0"}} to mark the device as "removable". See [http://udisks.freedesktop.org/docs/1.93.0/udisks.8.html udisks(8)] for details.
  
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.
+
{{hc|/etc/udev/rules.d/99-removable.rules|2=
 +
ENV{ID_SERIAL_SHORT}=="''serial_number''", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
 +
}}
  
{{Note|Since {{ic|1=udev>=171}}, the OSS emulation modules ({{ic|snd_seq_oss}}, {{ic|snd_pcm_oss}}, {{ic|snd_mixer_oss}}) are not automatically loaded by default.}}
+
Remember to reload udev rules with {{ic|udevadm control --reload}}. Next time you plug your device in, it will be treated as an external drive.
  
=== Known problems for custom kernel users ===
+
=== Sound problems with some modules not loaded automatically ===
  
==== Udev doesn't start at all ====
+
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.
  
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.
+
{{Note|Since {{ic|1=udev>=171}}, the OSS emulation modules ({{ic|snd_seq_oss}}, {{ic|snd_pcm_oss}}, {{ic|snd_mixer_oss}}) are not automatically loaded by default.}}
  
 
=== IDE CD/DVD-drive support ===
 
=== IDE CD/DVD-drive support ===
  
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.
+
Starting with version 170, udev does not support CD-ROM/DVD-ROM drives that are loaded as traditional IDE drives with the {{ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like ''cdparanoia'', but is invisible for higher userspace programs, like KDE.
  
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.
+
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your [[initramfs]]. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.
  
 
=== Optical drives have group ID set to "disk" ===
 
=== Optical drives have group ID set to "disk" ===
Line 211: Line 376:
 
If the group ID of your optical drive is set to {{ic|disk}} and you want to have it set to {{ic|optical}}, you have to create a custom udev rule:
 
If the group ID of your optical drive is set to {{ic|disk}} and you want to have it set to {{ic|optical}}, you have to create a custom udev rule:
  
{{hc|/etc/udev/rules.d|2=
+
{{hc|/etc/udev/rules.d|2=<nowiki>
 
# permissions for IDE CD devices
 
# permissions for IDE CD devices
 
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"
 
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"
  
 
# permissions for SCSI CD devices
 
# permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"}}
+
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"</nowiki>}}
  
 
== See also ==
 
== See also ==
  
* [https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html Udev Homepage]
+
* [https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html udev home page]
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]
+
* [https://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to udev]
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]
+
* [http://vger.kernel.org/vger-lists.html#linux-hotplug udev mailing list information]
 +
* [http://jasonwryan.com/blog/2014/01/20/udev/ Scripting with udev]
 +
* [http://www.reactivated.net/writing_udev_rules.html Writing udev rules]

Latest revision as of 14:22, 19 May 2016

Related articles

From Wikipedia article:

udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised while hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.

udev replaces the functionality of both hotplug and hwdetect.

Udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.

Installation

Udev is now part of systemd and is installed by default. See the systemd-udevd.service(8) man page for information.

A standalone fork is available in AUR: eudev.

About udev rules

Udev rules written by the administrator go in /etc/udev/rules.d/, their file name has to end with .rules. The udev rules shipped with various packages are found in /usr/lib/udev/rules.d/. If there are two files by the same name under /usr/lib and /etc, the ones in /etc take precedence.

Writing udev rules

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: You can workaround the FUSE errors (caused by udev killing the mount process) by using a systemd service [1] [2] (Discuss in Talk:Udev#)
Warning: To mount removable drives, do not call mount from udev rules. In case of FUSE filesystems, you will get Transport endpoint not connected errors. Instead, you could use udisks that handles automount correctly or to make mount work inside udev rules, copy /usr/lib/systemd/system/systemd-udevd.service to /etc/systemd/system/systemd-udevd.service and replace MountFlags=slave to MountFlags=shared.[3] Keep in mind though that udev is not intended to invoke long-running processes.
  • To learn how to write udev rules, see Writing udev rules.
  • To see an example udev rule, follow the Examples section of the above guide.

This is an example of a rule that places a symlink /dev/video-cam1 when a webcamera is connected. First, we have found out that this camera is connected and has loaded with the device /dev/video2. The reason for writing this rule is that at the next boot the device might just as well show up under a different name like /dev/video0.

# udevadm info -a -p $(udevadm info -q path -n /dev/video2)
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
    KERNEL=="video2"
    SUBSYSTEM=="video4linux"
    ...
  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
    KERNELS=="3-2:1.0"
    SUBSYSTEMS=="usb"
    ...
  looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
    KERNELS=="3-2"
    SUBSYSTEMS=="usb"
    ...
    ATTRS{idVendor}=="05a9"
    ...
    ATTRS{manufacturer}=="OmniVision Technologies, Inc."
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="4519"
    ATTRS{bDeviceClass}=="00"
    ATTRS{product}=="USB Camera"
    ...

From the video4linux device we use KERNEL=="video2" and SUBSYSTEM=="video4linux", then we match the webcam using vendor and product ID's from the usb parent SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9" and ATTRS{idProduct}=="4519".

/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"

In the example above we create a symlink using SYMLINK+="video-cam1" but we could easily set user OWNER="john" or group using GROUP="video" or set the permissions using MODE="0660". However, if you intend to write a rule to do something when a device is being removed, be aware that device attributes may not be accessible. In this case, you will have to work with preset device environment variables. To monitor those environment variables, execute the following command while unplugging your device:

# udevadm monitor --environment --udev

In this command's output, you will see value pairs such as ID_VENDOR_ID and ID_MODEL_ID, which match your previously used attributes "idVendor" and "idProduct". A rule that uses device environment variables may look like this:

/etc/udev/rules.d/83-webcam-removed.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="/path/to/your/script"

List attributes of a device

To get a list of all of the attributes of a device you can use to write rules, run this command:

# udevadm info -a -n [device name]

Replace [device name] with the device present in the system, such as /dev/sda or /dev/ttyUSB0.

If you do not know the device name you can also list all attributes of a specific system path:

# udevadm info -a -p /sys/class/backlight/acpi_video0

Testing rules before loading

# udevadm test $(udevadm info -q path -n [device name]) 2>&1

This will not perform all actions in your new rules but it will however process symlink rules on existing devices which might come in handy if you are unable to load them otherwise. You can also directly provide the path to the device you want to test the udev rule for:

# udevadm test /sys/class/backlight/acpi_video0/

Loading new rules

Udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices. Hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect, or at least unloading and reloading the ohci-hcd and ehci-hcd kernel modules and thereby reloading all USB drivers.

If rules fail to reload automatically

# udevadm control --reload

To manually force udev to trigger your rules

# udevadm trigger

Udisks

See Udisks.

Tips and tricks

Accessing firmware programmers and USB virtual comm devices

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Making a device world-writable is not secure. (Discuss in Talk:Udev#)

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: One example is enough, others can surely be found with lsusb. (Discuss in Talk:Udev#)

The following ruleset will allow normal users (within the "users" group) the ability to access the USBtinyISP USB programmer for AVR microcontrollers and a generic (SiLabs CP2102) USB to UART adapter, the Atmel AVR Dragon programmer, and the Atmel AVR ISP mkII. Adjust the permissions accordingly. Verified as of 31-10-2012.

/etc/udev/rules.d/50-embedded_devices.rules
# USBtinyISP Programmer rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"

# USBasp Programmer rules http://www.fischl.de/usbasp/
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"

# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"

#Atmel AVR Dragon (dragon_isp) rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", GROUP="users", MODE="0666"

#Atmel AVR JTAGICEMKII rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2103", GROUP="users", MODE="0666"

#Atmel Corp. AVR ISP mkII
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0666"

#Atmel Copr. JTAGICE3
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2140", GROUP="users", MODE="0666"

Execute on USB insert

See the Execute on USB insert article or the devmon wrapper script.

Execute on VGA cable plug in

Create the rule /etc/udev/rules.d/95-monitor-hotplug.rules with the following content to launch arandr on plug in of a VGA monitor cable:

KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/arandr"

Some display managers store the .Xauthority outside the user home directory. You will need to update the ENV{XAUTHORITY} accordingly. As an example GNOME Display Manager looks as follows:

$ printenv XAUTHORITY
/run/user/1000/gdm/Xauthority

Detect new eSATA drives

If your eSATA drive is not detected when you plug it in, there are a few things you can try. You can reboot with the eSATA plugged in. Or you could try

# echo 0 0 0 | tee /sys/class/scsi_host/host*/scan

Or you could install scsiaddAUR (from the AUR) and try

# scsiadd -s

Hopefully, your drive is now in /dev. If it is not, you could try the above commands while running

# udevadm monitor

to see if anything is actually happening.

Mark internal SATA ports as eSATA

If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. GNOME and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal GNOME user can connect their eSATA drives to that port like a USB drive, without any root password and so on.

/etc/udev/rules.d/10-esata.rules
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
Note: The DEVPATH can be found after connection the eSATA drive with the following commands (replace sdb accordingly):
# udevadm info -q path -n /dev/sdb
/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
# find /sys/devices/ -name sdb
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb

Setting static device names

Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. A udev rule can be added to use static device names.

See also Persistent block device naming for block devices and Network configuration#Device names for network devices.

Video devices

For setting up the webcam in the first place, refer to Webcam configuration.

Using multiple webcams, useful for example with motion (software motion detector which grabs images from video4linux devices and/or from webcams), will assign video devices as /dev/video0..n randomly on boot. The recommended solution is to create symlinks using an udev rule (as in the example in #Writing udev rules):

/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0840", SYMLINK+="video-cam3"
Note: Using names other than /dev/video* will break preloading of v4l1compat.so and perhaps v4l2convert.so

Printers

If you use multiple printers, /dev/lp[0-9] devices will be assigned randomly on boot, which will break e.g. CUPS configuration.

You can create following rule, which will create symlinks under /dev/lp/by-id and /dev/lp/by-path, similar to Persistent block device naming scheme:

/etc/udev/rules.d/60-persistent-printer.rules
ACTION=="remove", GOTO="persistent_printer_end"

# This should not be necessary
#KERNEL!="lp*", GOTO="persistent_printer_end"

SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
ENV{ID_TYPE}!="printer", GOTO="persistent_printer_end"

ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"

IMPORT{builtin}="path_id"
ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"

LABEL="persistent_printer_end"

USB flash device

USB flash devices usually contain partitions, and partition labels are one way to have a static naming for a device. Another way is to create a udev rule for it.

Get the serial number and USB ids from the USB flash drive (if you use multiple of the same make, you might have to check the serial is indeed unique):

lsusb -v | grep -A 5 Vendor

Create a udev rule for it by adding the following to a file in /etc/udev/rules.d/, such as 8-usbstick.rules:

KERNEL=="sd*", ATTRS{serial}=="$SERIAL", ATTRS{idVendor}=="$VENDOR", ATTRS{idProduct}=="$PRODUCT" SYMLINK+="$SYMLINK%n"

Replace $SERIAL, $VENDOR, $PRODUCT from above output accordingly and $SYMLINK with the desired name. %n will expand to the partition number. For example, if the device has two partitions, two symlinks will be created. You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).

Rescan sysfs:

udevadm trigger

Now check the contents of /dev:

ls /dev

It should show the device with the desired name.

Waking from suspend with USB device

First, find vendor and product ID of your device, for example

# lsusb | grep Logitech
Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver

Now change the power/wakeup attribute of the device and the USB controller it is connected to, which is in this case driver/usb7/power/wakeup. Use the following rule:

/etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled", ATTR{driver/usb7/power/wakeup}="enabled"
Note: Also make sure the USB controller is enabled in /proc/acpi/wakeup.

Triggering events

Merge-arrows-2.pngThis article or section is a candidate for merging with #Testing rules before loading.Merge-arrows-2.png

Notes: similar trick (Discuss in Talk:Udev#)

It can be useful to trigger various udev events. For example, you might want to simulate a USB device disconnect on a remote machine. In such cases, use udevadm trigger:

# udevadm trigger -v -t subsystems -c remove -s usb -a "idVendor=abcd"

This command will trigger a USB remove event on all USB devices with vendor ID abcd.

Troubleshooting

Blacklisting modules

In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See blacklisting. Not at boot-time or later on when a hotplug event is received (eg, you plug in your USB flash drive).

Debug output

To get hardware debug info, use the kernel parameter udev.log-priority=debug. Alternatively you can set

/etc/udev/udev.conf
udev_log="debug"

This option can also be compiled into your initramfs by adding the config file to your FILES array

/etc/mkinitcpio.conf
FILES="... /etc/udev/udev.conf"

and then rebuilding the initramfs with

# mkinitcpio -p linux

udevd hangs at boot

After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.

Extract the group names referenced in udev rules and the group names actually present on the system:

# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups

To see the differences, do a side-by-side diff:

# diff -y present_groups udev_groups
...
network							      <
nobody							      <
ntp							      <
optical								optical
power							      |	pcscd
rfkill							      <
root								root
scanner								scanner
smmsp							      <
storage								storage
...

In this case, the pcscd group is for some reason not present in the system. Add the missing groups. Also, make sure that local resources are looked up before resorting to LDAP. /etc/nsswitch.conf should contain the following line:

group: files ldap

BusLogic devices can be broken and will cause a freeze during startup

This is a kernel bug and no fix has been provided yet.

Some devices, that should be treated as removable, are not

You need to create a custom udev rule for that particular device. To get definitive information of the device you can use either ID_SERIAL or ID_SERIAL_SHORT (remember to change /dev/sdb if needed):

$ udevadm info /dev/sdb | grep ID_SERIAL

Then we create a rule in /etc/udev/rules.d/ and set variables for either udisks or udisks2.

For udisks, set UDISKS_SYSTEM_INTERNAL="0", which will mark the device as "removable" and thus "eligible for automounting". See udisks(7) for details.

/etc/udev/rules.d/50-external-myhomedisk.rules
ENV{ID_SERIAL_SHORT}=="serial_number", ENV{UDISKS_SYSTEM_INTERNAL}="0"

For udisks2, set UDISKS_AUTO="1" to mark the device for automounting and UDISKS_SYSTEM="0" to mark the device as "removable". See udisks(8) for details.

/etc/udev/rules.d/99-removable.rules
ENV{ID_SERIAL_SHORT}=="serial_number", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"

Remember to reload udev rules with udevadm control --reload. Next time you plug your device in, it will be treated as an external drive.

Sound problems with some modules not loaded automatically

Some users have traced this problem to old entries in /etc/modprobe.d/sound.conf. Try cleaning that file out and trying again.

Note: Since udev>=171, the OSS emulation modules (snd_seq_oss, snd_pcm_oss, snd_mixer_oss) are not automatically loaded by default.

IDE CD/DVD-drive support

Starting with version 170, udev does not support CD-ROM/DVD-ROM drives that are loaded as traditional IDE drives with the ide_cd_mod module and show up as /dev/hd*. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.

A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your /etc/mkinitcpio.conf.

Optical drives have group ID set to "disk"

If the group ID of your optical drive is set to disk and you want to have it set to optical, you have to create a custom udev rule:

/etc/udev/rules.d
# permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"

See also