3
Short summary: when a driver is loaded it makes some information available
4
in /sys/ and a message is sent to udevd which reads them and creates the
8
- modules cannot be loaded on demand when applications open their device,
9
because the device is not yet there!
10
- since modules are not loaded on demand, if for some reason the drivers
11
cannot be automatically loaded at boot time you will have to add them
13
- some modules are not hardware drivers and cannot be loaded automatically
14
by udev, so they will have to be listed in /etc/modules as well.
15
- some modules for less usual bus types lack the sysfs data needed to be
16
automatically loaded and must be loaded manually.
17
(See #334238 and #337004 for details.)
19
udevd also manages the hotplug events and if needed dispatches them to
20
other programs using RUN rules, as a replacement of the old /sbin/hotplug.
25
If the system hangs at boot time or fails to boot properly, it may be
26
useful to examine in real time what is happening while "udevadm settle"
27
is running. A simple way to do this is:
29
* boot the system passing "init=/bin/bash" on the kernel command line
30
* start a getty on tty2 (or the serial console) with a command like
31
"/sbin/getty 38400 tty2 &"
32
* continue the boot process with "exec /sbin/init single"
34
The open console can be used to check which processes are running and
35
what they are waiting for.
37
Setting the kernel command line options documented in udevd(8) may also
38
help to identify system-wide troubles caused by specific kernel drivers.
41
Required kernel support
42
~~~~~~~~~~~~~~~~~~~~~~~
43
The required kernel version and features are documented in the README
49
You may configure in /etc/udev/udev.conf a directory other than /dev
50
or add UDEV_DISABLED=yes to the kernel command line.
53
Manually creating devices
54
~~~~~~~~~~~~~~~~~~~~~~~~~
55
Device nodes present in /lib/udev/devices/ will be copied to /dev/ at
59
The /etc/udev/rules.d/ directory
60
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61
The files are read and processed in alphabetical order, and the directives
62
of matching rules are applied in order.
63
If a file with the same name is present in more than one of the
64
/run/udev/rules.d/, /etc/udev/rules.d/ and /lib/udev/rules.d/ directories
65
then the latter(s) file will be ignored.
66
Since the order may be important, files have a specific name which
67
must be considered when adding custom rules. So far have been defined:
69
- 60: path_id and the other *_id programs are run. persistent links
72
- 70: network interfaces are renamed and generated rules for persistent
75
- 75: the rules generators are run if needed.
77
- 80: drivers are loaded.
79
- 91: the default permissions and owners are set.
81
- 95: $REMOVE_CMD is run, and then processing of tty devices
82
is stopped with last_rule.
84
The persistent-*.rules files are generated by the *-generator.rules files
85
using the /lib/udev/write_*_rules scripts when new devices are detected.
86
They set stable names for network interfaces and optical devices aliases.
89
How to know the attributes of a device
90
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
92
udevadm info --attribute-walk --path=/sys/class/sound/pcmC0D0c/
97
Most devices will be created at the beginning of the boot process, and will
98
have the creation time of the kernel clock at that moment.
99
On systems whose system clock is set on local time instead of UTC, the
100
kernel clock will be updated in a later phase of the boot process and for
101
a few hours the devices will have a timestamp in the future.
102
This is usually not a problem, but if it bothers you it can be fixed by
103
running touch(1) in an init script.
106
SCSI block and generic devices
107
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
108
When you create a custom rule which matches SCSI devices by some sysfs
109
attributes, do not forget that it will match not only the sdX device node
110
you are probably looking for but also the SCSI generic device node sgX.
111
To get the expected behaviour, you need to add KERNEL="sd*" to your rule.
112
A typical example for an USB pen drive is:
114
SUBSYSTEMS=="usb", KERNEL=="sd*", \
115
ATTRS{manufacturer}=="hardware vendor", ATTRS{product}=="model", \
116
SYMLINK+="pendrive%n"
118
If a device does not report media changes (like e.g. many SD card readers)
119
you will also need to add the OPTIONS+="all_partitions" attribute to the
120
rule. This is not needed if you are using HAL.
125
After receiving events about network interfaces, net.agent will call
126
ifupdown using the --allow=hotplug option. This makes the program act
127
only on interfaces marked with the "allow-hotplug" statement.
128
E.g: "allow-hotplug eth0" instead of the usual "auto eth0".
129
The loopback interface must always be configured with "auto lo".
131
The persistent names of network interfaces by default are automatically
132
written to /etc/udev/rules.d/70-persistent-net.rules .
133
Users can add their own rules there or at any other place before 70.
134
MAC addresses matching is literal, so they must be written in lower case.
135
To disable persistent naming of network interfaces, create an empty
136
/etc/udev/rules.d/75-persistent-net-generator.rules file to override
137
the one in /lib/udev/rules.d/ and delete
138
/etc/udev/rules.d/70-persistent-net.rules.
140
Beware: programs which rename network interfaces like ifrename and nameif
141
will let udev relay events for the old names and should not be used.
143
Usually network interfaces are renamed after the root file system has
144
been mounted, so if the root file system is mounted over the network
145
then the 70-persistent-net.rules file must be copied to the initramfs.
146
In most cases this is done automatically, but some setups may require
147
explicitly setting "export NEED_PERSISTENT_NET=yes" in a file in
148
/etc/initramfs-tools/conf.d/ .
149
If 70-persistent-net.rules is copied to the initramfs then it must be
150
updated every time a new interface is added.
153
Using udev with LDAP or NIS
154
~~~~~~~~~~~~~~~~~~~~~~~~~~~
155
If the rules files reference usernames or groups not present in the
156
/etc/{passwd,group} files and the system is configured to use a
157
network-based database like LDAP or NIS then udev may fail at boot time
158
because users and groups are looked up well before the network has been
160
A possible solution is to configure /etc/nsswitch.conf like this:
162
passwd: files ldap [UNAVAIL=return]
163
group: files ldap [UNAVAIL=return]
165
The nsswitch.conf syntax is documented in the glibc manual.
170
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
171
http://www.reactivated.net/udevrules.php
172
http://www.kroah.com/linux/talks/suse_2005_driver_model/