source: chapter09/symlinks.xml@ 193913e

Last change on this file since 193913e was 193913e, checked in by Thomas Trepl (Moody) <thomas@…>, 10 months ago

First commit to add S6 as init system (like systemd)

  • Property mode set to 100644
File size: 12.6 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "" [
4 <!ENTITY % general-entities SYSTEM "../general.ent">
5 %general-entities;
8<sect1 id="ch-config-symlinks">
9 <?dbhtml filename="symlinks.html"?>
11 <title>Managing Devices</title>
13 <sect2 revision="sysv,s6">
15 <title>Network Devices</title>
17 <para>Udev, by default, names network devices according to Firmware/BIOS
18 data or physical characteristics like the bus, slot, or MAC address. The
19 purpose of this naming convention is to ensure that network devices are
20 named consistently and not based on the time the network card was
21 discovered. For example, on a computer having two network cards made by
22 Intel and Realtek, the network card manufactured by Intel may become eth0
23 and the Realtek card becomes eth1. In some cases, after a reboot the cards
24 could get renumbered the other way around.</para>
26 <para>In the new naming scheme, typical network device names would then
27 be something like enp5s0 or wlp3s0. If this naming convention is not
28 desired, the traditional naming scheme or a custom scheme can be
29 implemented.</para>
31 <sect3>
32 <title>Disabling Persistent Naming on the Kernel Command Line</title>
34 <para>The traditional naming scheme using eth0, eth1, etc can be
35 restored by adding <userinput>net.ifnames=0</userinput> on the
36 kernel command line. This is most appropriate for those systems
37 that have only one ethernet device of the same type. Laptops
38 often have multiple ethernet connections that are named eth0 and
39 wlan0 and are also candidates for this method. The command line
40 is passed in the GRUB configuration file.
41 See <xref linkend="grub-cfg"/>.</para>
42 </sect3>
44 <sect3>
45 <title>Creating Custom Udev Rules</title>
47 <para>The naming scheme can be customized by creating custom udev
48 rules. A script has been included that generates the initial rules.
49 Generate these rules by running:</para>
51<screen role="install"><userinput>bash /usr/lib/udev/</userinput></screen>
53 <para> Now, inspect the
54 <filename>/etc/udev/rules.d/70-persistent-net.rules</filename> file, to
55 find out which name was assigned to which network device:</para>
57<screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen>
59 <note><para>In some cases such as when MAC addresses have been assigned to
60 a network card manually or in a virtual environment such as Qemu or Xen,
61 the network rules file may not have been generated because addresses
62 are not consistently assigned. In these cases, this method cannot
63 be used.</para></note>
65 <para>The file begins with a comment block followed by two lines for each
66 NIC. The first line for each NIC is a commented description showing its
67 hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card),
68 along with its driver in parentheses, if the driver can be found. Neither
69 the hardware ID nor the driver is used to determine which name to give an
70 interface; this information is only for reference. The second line is the
71 udev rule that matches this NIC and actually assigns it a name.</para>
73 <para>All udev rules are made up of several keys, separated by commas and
74 optional whitespace. This rule's keys and an explanation of each of them
75 are as follows:</para>
77 <itemizedlist>
78 <listitem>
79 <para><literal>SUBSYSTEM=="net"</literal> - This tells udev to ignore
80 devices that are not network cards.</para>
81 </listitem>
82 <listitem>
83 <para><literal>ACTION=="add"</literal> - This tells udev to ignore this
84 rule for a uevent that isn't an add ("remove" and "change" uevents also
85 happen, but don't need to rename network interfaces).</para>
86 </listitem>
87 <listitem>
88 <para><literal>DRIVERS=="?*"</literal> - This exists so that udev will
89 ignore VLAN or bridge sub-interfaces (because these sub-interfaces do
90 not have drivers). These sub-interfaces are skipped because the name
91 that would be assigned would collide with their parent devices.</para>
92 </listitem>
93 <listitem>
94 <para><literal>ATTR{address}</literal> - The value of this key is the
95 NIC's MAC address.</para>
96 </listitem>
97 <listitem>
98 <para><literal>ATTR{type}=="1"</literal> - This ensures the rule only
99 matches the primary interface in the case of certain wireless drivers
100 which create multiple virtual interfaces. The secondary interfaces are
101 skipped for the same reason that VLAN and bridge sub-interfaces are
102 skipped: there would be a name collision otherwise.</para>
103 </listitem>
104 <listitem>
105 <para><literal>NAME</literal> - The value of this key is the name that
106 udev will assign to this interface.</para>
107 </listitem>
108 </itemizedlist>
110 <para>The value of <literal>NAME</literal> is the important part. Make sure
111 you know which name has been assigned to each of your network cards before
112 proceeding, and be sure to use that <literal>NAME</literal> value when
113 creating your configuration files below.</para>
115 </sect3>
117 </sect2>
119 <sect2 revision="sysv,s6">
121 <title>CD-ROM symlinks</title>
123 <para>Some software that you may want to install later (e.g., various
124 media players) expect the <filename class="symlink">/dev/cdrom</filename>
125 and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and
126 to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put
127 references to those symlinks into <filename>/etc/fstab</filename>. Udev
128 comes with a script that will generate rules files to create these symlinks
129 for you, depending on the capabilities of each device, but you need to
130 decide which of two modes of operation you wish to have the script use.</para>
132 <para>First, the script can operate in <quote>by-path</quote> mode (used by
133 default for USB and FireWire devices), where the rules it creates depend on
134 the physical path to the CD or DVD device. Second, it can operate in
135 <quote>by-id</quote> mode (default for IDE and SCSI devices), where the
136 rules it creates depend on identification strings stored on the CD or DVD
137 device itself. The path is determined by udev's <command>path_id</command>
138 script, and the identification strings are read from the hardware by its
139 <command>ata_id</command> or <command>scsi_id</command> programs, depending
140 on which type of device you have.</para>
142 <para>There are advantages to each approach; the correct approach to use
143 will depend on what kinds of device changes may happen. If you expect the
144 physical path to the device (that is, the ports and/or slots that it plugs
145 into) to change, for example because you plan on moving the drive to a
146 different IDE port or a different USB connector, then you should use the
147 <quote>by-id</quote> mode. On the other hand, if you expect the device's
148 identification to change, for example because it may die, and you would
149 replace it with a different device with the same capabilities and which
150 is plugged into the same connectors, then you should use the
151 <quote>by-path</quote> mode.</para>
153 <para>If either type of change is possible with your drive, then choose a
154 mode based on the type of change you expect to happen more often.</para>
156<!-- If you use by-id mode, the symlinks will survive even the transition
157 to libata for IDE drives, but that is not for the book. -->
159 <important><para>External devices (for example, a USB-connected CD drive)
160 should not use by-path persistence, because each time the device is plugged
161 into a new external port, its physical path will change. All
162 externally-connected devices will have this problem if you write udev rules
163 to recognize them by their physical path; the problem is not limited to CD
164 and DVD drives.</para></important>
166 <para>If you wish to see the values that the udev scripts will use, then
167 for the appropriate CD-ROM device, find the corresponding directory under
168 <filename class="directory">/sys</filename> (e.g., this can be
169 <filename class="directory">/sys/block/hdd</filename>) and
170 run a command similar to the following:</para>
172<screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
174 <para>Look at the lines containing the output of various *_id programs.
175 The <quote>by-id</quote> mode will use the ID_SERIAL value if it exists and
176 is not empty, otherwise it will use a combination of ID_MODEL and
177 ID_REVISION. The <quote>by-path</quote> mode will use the ID_PATH value.</para>
179 <para>If the default mode is not suitable for your situation, then the
180 following modification can be made to the
181 <filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename> file,
182 as follows (where <replaceable>mode</replaceable> is one of
183 <quote>by-id</quote> or <quote>by-path</quote>):</para>
185<screen role="nodump"><userinput>sed -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
186 -i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
188 <para>Note that it is not necessary to create the rules files or symlinks
189 at this time because you have bind-mounted the host's
190 <filename class="directory">/dev</filename> directory into the LFS system
191 and we assume the symlinks exist on the host. The rules and symlinks will
192 be created the first time you boot your LFS system.</para>
194 <para>However, if you have multiple CD-ROM devices, then the symlinks
195 generated at that time may point to different devices than they point to on
196 your host because devices are not discovered in a predictable order. The
197 assignments created when you first boot the LFS system will be stable, so
198 this is only an issue if you need the symlinks on both systems to point to
199 the same device. If you need that, then inspect (and possibly edit) the
200 generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename>
201 file after booting, to make sure the assigned symlinks match what you need.</para>
203 </sect2>
205 <sect2>
207 <title>Dealing with duplicate devices</title>
209 <para>As explained in <xref linkend="ch-config-udev"/>, the order in
210 which devices with the same function appear in
211 <filename class="directory">/dev</filename> is essentially random.
212 E.g., if you have a USB web camera and a TV tuner, sometimes
213 <filename>/dev/video0</filename> refers to the camera and
214 <filename>/dev/video1</filename> refers to the tuner, and sometimes
215 after a reboot the order changes.
216 For all classes of hardware except sound cards and network cards, this is
217 fixable by creating udev rules for custom persistent symlinks.
218 The case of network cards is covered separately in
219 <xref linkend="ch-config-network"/>, and sound card configuration can
220 be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para>
222 <para>For each of your devices that is likely to have this problem
223 (even if the problem doesn't exist in your current Linux distribution),
224 find the corresponding directory under
225 <filename class="directory">/sys/class</filename> or
226 <filename class="directory">/sys/block</filename>.
227 For video devices, this may be
228 <filename
229 class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
230 Figure out the attributes that identify the device uniquely (usually,
231 vendor and product IDs and/or serial numbers work):</para>
233<screen role="nodump"><userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput></screen>
235 <para>Then write rules that create the symlinks, e.g.:</para>
237<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/83-duplicate_devs.rules &lt;&lt; "EOF"
239# Persistent symlinks for webcam and tuner
240KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
241KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
245 <para>The result is that <filename>/dev/video0</filename> and
246 <filename>/dev/video1</filename> devices still refer randomly to the tuner
247 and the web camera (and thus should never be used directly), but there are
248 symlinks <filename>/dev/tvtuner</filename> and
249 <filename>/dev/webcam</filename> that always point to the correct
250 device.</para>
252 </sect2>
Note: See TracBrowser for help on using the repository browser.