[966b175] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
[b06ca36] | 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
---|
[966b175] | 4 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
[afcfd74] | 8 | <sect1 id="ch-config-symlinks">
|
---|
[966b175] | 9 | <?dbhtml filename="symlinks.html"?>
|
---|
| 10 |
|
---|
[bf58c1e] | 11 | <title>Managing Devices</title>
|
---|
| 12 |
|
---|
[efd5d1f] | 13 | <sect2 revision="sysv">
|
---|
[bf58c1e] | 14 |
|
---|
| 15 | <title>Network Devices</title>
|
---|
| 16 |
|
---|
| 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
|
---|
[8972a36] | 20 | named consistently, not based on when the network card was
|
---|
| 21 | discovered. In older versions of Linux—on a computer with two
|
---|
| 22 | network cards made by Intel and Realtek, for instance—the
|
---|
| 23 | network card manufactured by Intel might have become eth0
|
---|
| 24 | while the Realtek card became eth1. After a reboot, the cards
|
---|
| 25 | would sometimes get renumbered the other way around.</para>
|
---|
| 26 |
|
---|
| 27 | <para>In the new naming scheme, typical network device names are
|
---|
| 28 | something like enp5s0 or wlp3s0. If this naming convention is not
|
---|
| 29 | desired, the traditional naming scheme, or a custom scheme, can be
|
---|
[bf58c1e] | 30 | implemented.</para>
|
---|
| 31 |
|
---|
| 32 | <sect3>
|
---|
| 33 | <title>Disabling Persistent Naming on the Kernel Command Line</title>
|
---|
[c34b4fb] | 34 |
|
---|
[8972a36] | 35 | <para>The traditional naming scheme using eth0, eth1, etc. can be
|
---|
[c34b4fb] | 36 | restored by adding <userinput>net.ifnames=0</userinput> on the
|
---|
[8972a36] | 37 | kernel command line. This is most appropriate for systems
|
---|
| 38 | that have just one ethernet device of a particular type. Laptops
|
---|
| 39 | often have two ethernet connections named eth0 and
|
---|
| 40 | wlan0; such laptops can also use this method. The command line
|
---|
| 41 | is in the GRUB configuration file.
|
---|
[bf58c1e] | 42 | See <xref linkend="grub-cfg"/>.</para>
|
---|
| 43 | </sect3>
|
---|
| 44 |
|
---|
| 45 | <sect3>
|
---|
| 46 | <title>Creating Custom Udev Rules</title>
|
---|
[c34b4fb] | 47 |
|
---|
[a3d0817] | 48 | <para>The naming scheme can be customized by creating custom udev
|
---|
[bf58c1e] | 49 | rules. A script has been included that generates the initial rules.
|
---|
| 50 | Generate these rules by running:</para>
|
---|
| 51 |
|
---|
[d7a9421] | 52 | <screen role="install"><userinput>bash /usr/lib/udev/init-net-rules.sh</userinput></screen>
|
---|
[bf58c1e] | 53 |
|
---|
[8aa7fde] | 54 | <para> Now, inspect the
|
---|
[bf58c1e] | 55 | <filename>/etc/udev/rules.d/70-persistent-net.rules</filename> file, to
|
---|
| 56 | find out which name was assigned to which network device:</para>
|
---|
| 57 |
|
---|
| 58 | <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen>
|
---|
| 59 |
|
---|
[8972a36] | 60 | <note><para>In some cases, such as when MAC addresses have been assigned to
|
---|
| 61 | a network card manually, or in a virtual environment such as Qemu or Xen,
|
---|
| 62 | the network rules file may not be generated because addresses
|
---|
[bf58c1e] | 63 | are not consistently assigned. In these cases, this method cannot
|
---|
| 64 | be used.</para></note>
|
---|
[c34b4fb] | 65 |
|
---|
[8972a36] | 66 | <para>The file begins with a comment block, followed by two lines for each
|
---|
[bf58c1e] | 67 | NIC. The first line for each NIC is a commented description showing its
|
---|
| 68 | hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card),
|
---|
[8972a36] | 69 | along with its driver (in parentheses, if the driver can be found). Neither
|
---|
[bf58c1e] | 70 | the hardware ID nor the driver is used to determine which name to give an
|
---|
| 71 | interface; this information is only for reference. The second line is the
|
---|
[a3d0817] | 72 | udev rule that matches this NIC and actually assigns it a name.</para>
|
---|
[c34b4fb] | 73 |
|
---|
[8972a36] | 74 | <para>All udev rules are made up of several keywords, separated by commas and
|
---|
| 75 | optional whitespace. Here are the keywords, and an explanation of each one:</para>
|
---|
[c34b4fb] | 76 |
|
---|
[bf58c1e] | 77 | <itemizedlist>
|
---|
| 78 | <listitem>
|
---|
[a3d0817] | 79 | <para><literal>SUBSYSTEM=="net"</literal> - This tells udev to ignore
|
---|
[bf58c1e] | 80 | devices that are not network cards.</para>
|
---|
| 81 | </listitem>
|
---|
| 82 | <listitem>
|
---|
[a3d0817] | 83 | <para><literal>ACTION=="add"</literal> - This tells udev to ignore this
|
---|
[bf58c1e] | 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>
|
---|
[a3d0817] | 88 | <para><literal>DRIVERS=="?*"</literal> - This exists so that udev will
|
---|
[bf58c1e] | 89 | ignore VLAN or bridge sub-interfaces (because these sub-interfaces do
|
---|
| 90 | not have drivers). These sub-interfaces are skipped because the name
|
---|
[8972a36] | 91 | that would be assigned would collide with the parent devices.</para>
|
---|
[bf58c1e] | 92 | </listitem>
|
---|
| 93 | <listitem>
|
---|
[8972a36] | 94 | <para><literal>ATTR{address}</literal> - The value of this keyword is the
|
---|
[bf58c1e] | 95 | NIC's MAC address.</para>
|
---|
| 96 | </listitem>
|
---|
| 97 | <listitem>
|
---|
| 98 | <para><literal>ATTR{type}=="1"</literal> - This ensures the rule only
|
---|
[a3d0817] | 99 | matches the primary interface in the case of certain wireless drivers
|
---|
[bf58c1e] | 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>
|
---|
[8972a36] | 105 | <para><literal>NAME</literal> - The value of this keyword is the name that
|
---|
[a3d0817] | 106 | udev will assign to this interface.</para>
|
---|
[bf58c1e] | 107 | </listitem>
|
---|
| 108 | </itemizedlist>
|
---|
[c34b4fb] | 109 |
|
---|
[bf58c1e] | 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
|
---|
[8972a36] | 113 | creating your network configuration files.</para>
|
---|
[bf58c1e] | 114 |
|
---|
[3608380f] | 115 | <para>Even if the custom udev rule file is created, udev may still
|
---|
| 116 | assign one or more alternative names for a NIC based on physical
|
---|
| 117 | characteristics. If a custom udev rule would rename another NIC using
|
---|
| 118 | a name already assigned as an alternative name of another NIC, this
|
---|
| 119 | udev rule will fail. If this issue happens, you may create the
|
---|
| 120 | <filename>/etc/udev/network/99-default.link</filename> configuration
|
---|
| 121 | file with an empty alternative assignment policy, overriding the
|
---|
| 122 | default configuration file
|
---|
| 123 | <filename>/usr/lib/udev/network/99-default.link</filename>:</para>
|
---|
| 124 |
|
---|
| 125 | <screen role="nodump"><userinput>sed -e '/^AlternativeNamesPolicy/s/=.*$/=/' \
|
---|
| 126 | -i /usr/lib/udev/network/99-default.link \
|
---|
| 127 | > /etc/udev/network/99-default.link</userinput></screen>
|
---|
[bf58c1e] | 128 | </sect3>
|
---|
| 129 |
|
---|
| 130 | </sect2>
|
---|
[966b175] | 131 |
|
---|
[efd5d1f] | 132 | <sect2 revision="sysv">
|
---|
[966b175] | 133 |
|
---|
[8972a36] | 134 | <title>CD-ROM Symlinks</title>
|
---|
[966b175] | 135 |
|
---|
| 136 | <para>Some software that you may want to install later (e.g., various
|
---|
[8972a36] | 137 | media players) expects the <filename class="symlink">/dev/cdrom</filename>
|
---|
[84dbfdac] | 138 | and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and
|
---|
| 139 | to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put
|
---|
| 140 | references to those symlinks into <filename>/etc/fstab</filename>. Udev
|
---|
| 141 | comes with a script that will generate rules files to create these symlinks
|
---|
| 142 | for you, depending on the capabilities of each device, but you need to
|
---|
| 143 | decide which of two modes of operation you wish to have the script use.</para>
|
---|
| 144 |
|
---|
[8536c02] | 145 | <para>First, the script can operate in <quote>by-path</quote> mode (used by
|
---|
| 146 | default for USB and FireWire devices), where the rules it creates depend on
|
---|
| 147 | the physical path to the CD or DVD device. Second, it can operate in
|
---|
| 148 | <quote>by-id</quote> mode (default for IDE and SCSI devices), where the
|
---|
[a3d0817] | 149 | rules it creates depend on identification strings stored on the CD or DVD
|
---|
| 150 | device itself. The path is determined by udev's <command>path_id</command>
|
---|
[8536c02] | 151 | script, and the identification strings are read from the hardware by its
|
---|
[84dbfdac] | 152 | <command>ata_id</command> or <command>scsi_id</command> programs, depending
|
---|
| 153 | on which type of device you have.</para>
|
---|
| 154 |
|
---|
[8972a36] | 155 | <para>There are advantages to each approach; the correct approach
|
---|
| 156 | depends on what kinds of device changes may happen. If you expect the
|
---|
[84dbfdac] | 157 | physical path to the device (that is, the ports and/or slots that it plugs
|
---|
| 158 | into) to change, for example because you plan on moving the drive to a
|
---|
| 159 | different IDE port or a different USB connector, then you should use the
|
---|
| 160 | <quote>by-id</quote> mode. On the other hand, if you expect the device's
|
---|
[8972a36] | 161 | identification to change, for example because it may die, and you intend
|
---|
| 162 | to replace it with a different device that
|
---|
| 163 | plugs into the same connectors, then you should use the
|
---|
[84dbfdac] | 164 | <quote>by-path</quote> mode.</para>
|
---|
| 165 |
|
---|
| 166 | <para>If either type of change is possible with your drive, then choose a
|
---|
| 167 | mode based on the type of change you expect to happen more often.</para>
|
---|
| 168 |
|
---|
| 169 | <!-- If you use by-id mode, the symlinks will survive even the transition
|
---|
| 170 | to libata for IDE drives, but that is not for the book. -->
|
---|
| 171 |
|
---|
[80640a49] | 172 | <important><para>External devices (for example, a USB-connected CD drive)
|
---|
| 173 | should not use by-path persistence, because each time the device is plugged
|
---|
| 174 | into a new external port, its physical path will change. All
|
---|
[a3d0817] | 175 | externally-connected devices will have this problem if you write udev rules
|
---|
[80640a49] | 176 | to recognize them by their physical path; the problem is not limited to CD
|
---|
| 177 | and DVD drives.</para></important>
|
---|
[84dbfdac] | 178 |
|
---|
[a3d0817] | 179 | <para>If you wish to see the values that the udev scripts will use, then
|
---|
[84dbfdac] | 180 | for the appropriate CD-ROM device, find the corresponding directory under
|
---|
[966b175] | 181 | <filename class="directory">/sys</filename> (e.g., this can be
|
---|
| 182 | <filename class="directory">/sys/block/hdd</filename>) and
|
---|
| 183 | run a command similar to the following:</para>
|
---|
| 184 |
|
---|
[61e63d3] | 185 | <screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
|
---|
[84dbfdac] | 186 |
|
---|
| 187 | <para>Look at the lines containing the output of various *_id programs.
|
---|
| 188 | The <quote>by-id</quote> mode will use the ID_SERIAL value if it exists and
|
---|
| 189 | is not empty, otherwise it will use a combination of ID_MODEL and
|
---|
| 190 | ID_REVISION. The <quote>by-path</quote> mode will use the ID_PATH value.</para>
|
---|
| 191 |
|
---|
[8536c02] | 192 | <para>If the default mode is not suitable for your situation, then the
|
---|
| 193 | following modification can be made to the
|
---|
[0a28f5f4] | 194 | <filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename> file,
|
---|
[8536c02] | 195 | as follows (where <replaceable>mode</replaceable> is one of
|
---|
| 196 | <quote>by-id</quote> or <quote>by-path</quote>):</para>
|
---|
[84dbfdac] | 197 |
|
---|
[a3d0817] | 198 | <screen role="nodump"><userinput>sed -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
|
---|
| 199 | -i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
|
---|
[966b175] | 200 |
|
---|
[84dbfdac] | 201 | <para>Note that it is not necessary to create the rules files or symlinks
|
---|
[a3d0817] | 202 | at this time because you have bind-mounted the host's
|
---|
| 203 | <filename class="directory">/dev</filename> directory into the LFS system
|
---|
[651719a] | 204 | and we assume the symlinks exist on the host. The rules and symlinks will
|
---|
| 205 | be created the first time you boot your LFS system.</para>
|
---|
[a3b689f] | 206 |
|
---|
[651719a] | 207 | <para>However, if you have multiple CD-ROM devices, then the symlinks
|
---|
| 208 | generated at that time may point to different devices than they point to on
|
---|
[a3d0817] | 209 | your host because devices are not discovered in a predictable order. The
|
---|
[651719a] | 210 | assignments created when you first boot the LFS system will be stable, so
|
---|
| 211 | this is only an issue if you need the symlinks on both systems to point to
|
---|
| 212 | the same device. If you need that, then inspect (and possibly edit) the
|
---|
| 213 | generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename>
|
---|
[8972a36] | 214 | file after booting, to make sure the assigned symlinks match your needs.</para>
|
---|
[966b175] | 215 |
|
---|
| 216 | </sect2>
|
---|
| 217 |
|
---|
| 218 | <sect2>
|
---|
| 219 |
|
---|
[8972a36] | 220 | <title>Dealing with Duplicate Devices</title>
|
---|
[966b175] | 221 |
|
---|
[afcfd74] | 222 | <para>As explained in <xref linkend="ch-config-udev"/>, the order in
|
---|
[966b175] | 223 | which devices with the same function appear in
|
---|
| 224 | <filename class="directory">/dev</filename> is essentially random.
|
---|
| 225 | E.g., if you have a USB web camera and a TV tuner, sometimes
|
---|
| 226 | <filename>/dev/video0</filename> refers to the camera and
|
---|
| 227 | <filename>/dev/video1</filename> refers to the tuner, and sometimes
|
---|
[a3d0817] | 228 | after a reboot the order changes.
|
---|
[966b175] | 229 | For all classes of hardware except sound cards and network cards, this is
|
---|
[8972a36] | 230 | fixable by creating udev rules to create persistent symlinks.
|
---|
[966b175] | 231 | The case of network cards is covered separately in
|
---|
[afcfd74] | 232 | <xref linkend="ch-config-network"/>, and sound card configuration can
|
---|
[0ee07e5] | 233 | be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para>
|
---|
[966b175] | 234 |
|
---|
| 235 | <para>For each of your devices that is likely to have this problem
|
---|
| 236 | (even if the problem doesn't exist in your current Linux distribution),
|
---|
| 237 | find the corresponding directory under
|
---|
| 238 | <filename class="directory">/sys/class</filename> or
|
---|
| 239 | <filename class="directory">/sys/block</filename>.
|
---|
| 240 | For video devices, this may be
|
---|
| 241 | <filename
|
---|
| 242 | class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
|
---|
| 243 | Figure out the attributes that identify the device uniquely (usually,
|
---|
| 244 | vendor and product IDs and/or serial numbers work):</para>
|
---|
| 245 |
|
---|
[61e63d3] | 246 | <screen role="nodump"><userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput></screen>
|
---|
[966b175] | 247 |
|
---|
| 248 | <para>Then write rules that create the symlinks, e.g.:</para>
|
---|
| 249 |
|
---|
[8857ace2] | 250 | <screen role="nodump"><userinput>cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
|
---|
[966b175] | 251 | <literal>
|
---|
| 252 | # Persistent symlinks for webcam and tuner
|
---|
[a3d0817] | 253 | KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
|
---|
| 254 | KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
|
---|
[966b175] | 255 | </literal>
|
---|
| 256 | EOF</userinput></screen>
|
---|
| 257 |
|
---|
| 258 | <para>The result is that <filename>/dev/video0</filename> and
|
---|
| 259 | <filename>/dev/video1</filename> devices still refer randomly to the tuner
|
---|
| 260 | and the web camera (and thus should never be used directly), but there are
|
---|
| 261 | symlinks <filename>/dev/tvtuner</filename> and
|
---|
| 262 | <filename>/dev/webcam</filename> that always point to the correct
|
---|
| 263 | device.</para>
|
---|
| 264 |
|
---|
| 265 | </sect2>
|
---|
| 266 |
|
---|
| 267 | </sect1>
|
---|