udev is the device manager for the Linux kernel. It manages device nodes in /dev and handles all user space actions when adding or removing devices. Readers of this article should also look at eudev, a fork of udev.
- 1 What is udev?
- 2 Installation
- 3 Configuration
- 4 Advanced Configuration
- 5 Usage
- 6 Troubleshooting
- 7 See also
- 8 External resources
What is udev?
The /dev directory
When Linux users talk about the hardware on their system in the vicinity of people who believe Linux is some sort of virus or brand of coffee, the use of "slash dev slash foo" will return strange looks for sure. But for the fortunate user (and that includes the reader of this article) using /dev/sda1 is just a fast way of referring to the primary master SATA, first partition. That's pretty easy, right?
Most Linux users know what a device file is. Some even know why device files have special numbers. Take a close look at device list when ls -l is issued in the /dev folder. What users take for granted is that the primary SATA disk is referred to as /dev/sda Some users might not see it this way, but this is a flaw by design.
Think about hotpluggable devices like USB, IEEE1394, hot-swappable PCI, etc. What is the first device? And for how long? What will the other devices be named when the first one disappears? How will that affect ongoing transactions? Wouldn't it be fun that a printing job is suddenly moved from a super-new laser printer to an almost-dead matrix printer because someone's mom decided to pull the plug of the laser printer which just so happened to be the first printer?
Enter udev. The goals of the udev project are both interesting and needed. Udev:
- Runs in userspace;
- Dynamically creates and removes device files;
- Provides consistent naming;
- Provides a userspace application program interface (API).
Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as declared in the /etc/udev/rules.d, /run/udev/rules.d and /lib/udev/rules.d directories. Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions. These actions can be creating or deleting device files, but can also trigger the loading of particular firmware files into kernel memory.
When updating udev, check the upgrade sub-article.
udev requires the following kernel options:
General setup ---> [*] Configure standard kernel features (expert users) ---> [ ] Enable deprecated sysfs features to support old userspace tools [*] Enable signalfd() system call Enable the block layer ---> [*] Block layer SG support v4 Networking support ---> Networking options ---> <*> Unix domain sockets Device Drivers ---> Generic Driver Options ---> () path to uevent helper [*] Maintain a devtmpfs filesystem to mount at /dev < > ATA/ATAPI/MFM/RLL support (DEPRECATED) ---> File systems ---> [*] Inotify support for userspace Pseudo filesystems ---> [*] /proc file system support [*] sysfs file system support
USE="... udev ..."
|USE flag (what is that?)||Default||Recommended||Description|
||Yes||Add support for Access Control Lists|
||No||Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally|
||Yes||Enable userspace firmware loader (DEPRECATED, replaced by in-kernel loader in 3.8+)|
||Yes||Build the gobject interface library|
||Yes||Add support for GObject based introspection|
||Yes||Enable kernel module loading/unloading support using sys-apps/kmod|
||Yes||Install the OpenRC init scripts|
||No||No||!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur|
||No||No||Build static versions of dynamic libraries as well|
After setting this update the system so the changes take effect:
emerge --ask --changed-use --deep @world
To start udev at boot time, add it to the sysinit runlevel. This can be done by issuing the following command with root privileges:
rc-update add udev sysinit
udev provides a set of rules that match against exported values of uevents (events sent by the kernel) and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to setup and configure the device.
The rule definitions are stored in two locations: 1) /lib/udev/rules.d these rules are installed by certain packages and 2) /etc/udev/rules.d this folder is for end-user specified rules. In these directories, multiple rule files (with suffix .rules) are traversed in alphanumerical order. Inside the rules files, udev will find expressions that might match a uevent together with the state to match (is the uevent because a device is added or removed) and the command to execute.
The event matching is based on information such as:
- The SUBSYSTEM of the uevent (for which type of device is the uevent fired);
- The ACTION that is taken (add, change or remove);
- One or more attributes (through ATTR or ATTRS), such as the device class, vendor or other device information;
- The kernel-provided name (through KERNEL), such as sd* (for SCSI/SATA disks) or input* (for input devices such as mice and keyboards);
- One or more environment settings (through ENV), used to send information between multiple rules.
Based on this information, the rule can then state if
- Some information needs to be shared with later events (through environment variables)
- Links need to be created in /dev
- Commands need to be executed
Udev does this for every rule that matches (it does not stop after the first match) to allow a flexible device management approach.
Persistent device names
The kernel detects devices asynchronous, udev mirrors the kernel's sysfs filesystem and so the device are named and numbered in order of detection. So by default udev provides no persistent device names. However there are mechanisms for some device classes to provide these:
- Udev creates for storage devices additional symlinks based on the device's ID, label, UUID and path. See the /dev/disk/by-* directory. So instead of using e.g. the device file /dev/sda use the file /dev/disk/by-label/SOME_LABEL.
- The same for input devices in the /dev/input directory.
- Using custom rules enablers users to create their own device files.
Some useful commands are:
- Show all messages about a given device file:
udevadm info --query=all --name=/dev/DEVICE_FILE
- Monitor udev activities:
See the udevadm man page for more information.
Log monitor messages
To log all message when udevadm monitor is ran modify the following configuration file:
It will create the new log file located at /run/udev/udevmonitor.log
Enabling debug mode will output more log messages:
Set the logging priority:
The log file /run/udevdebug.log will be created but no messages will be logged to it. The most recent versions of udev will log all messages to dmesg.
Missing device files /dev/null and /dev/console
Some udev versions need the /dev/null and /dev/console files in order to work properly, but can not create them on their own. To manually create these files for udev run the following commands with root privileges:
mount --bind / test
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3
NIC assigned eth0, but is moved to eth1
Those having dual network cards on their motherboards may run into a situation where ifconfig may show no eth0 or eth1. dmesg may show their NIC detected as eth0, and later moved to eth1. Performing a ifconfig -a will also show the NIC as eth1. This is caused by using the kernel assigned names in the first place. Users should write custom rules like /etc/udev/rules.d/70-my-network.rules to use free names like lan0 or wireless0 or use predictable interface names (which have been enabled by default since udev version 197).
Remember to also remove old files from old versions of udev: