Changes in chapter09/symlinks.xml [8972a36:c34b4fb]
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter09/symlinks.xml
r8972a36 rc34b4fb 18 18 data or physical characteristics like the bus, slot, or MAC address. The 19 19 purpose of this naming convention is to ensure that network devices are 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 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> 25 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 30 29 implemented.</para> 31 30 … … 33 32 <title>Disabling Persistent Naming on the Kernel Command Line</title> 34 33 35 <para>The traditional naming scheme using eth0, eth1, etc .can be34 <para>The traditional naming scheme using eth0, eth1, etc can be 36 35 restored by adding <userinput>net.ifnames=0</userinput> on the 37 kernel command line. This is most appropriate for systems38 that have just one ethernet device of a particulartype. Laptops39 often have two ethernet connectionsnamed eth0 and40 wlan0 ; such laptops can also usethis method. The command line41 is in the GRUB configuration file.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. 42 41 See <xref linkend="grub-cfg"/>.</para> 43 42 </sect3> … … 58 57 <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen> 59 58 60 <note><para>In some cases ,such as when MAC addresses have been assigned to61 a network card manually ,or in a virtual environment such as Qemu or Xen,62 the network rules file may not begenerated because addresses59 <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 63 62 are not consistently assigned. In these cases, this method cannot 64 63 be used.</para></note> 65 64 66 <para>The file begins with a comment block ,followed by two lines for each65 <para>The file begins with a comment block followed by two lines for each 67 66 NIC. The first line for each NIC is a commented description showing its 68 67 hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card), 69 along with its driver (in parentheses, if the driver can be found). Neither68 along with its driver in parentheses, if the driver can be found. Neither 70 69 the hardware ID nor the driver is used to determine which name to give an 71 70 interface; this information is only for reference. The second line is the 72 71 udev rule that matches this NIC and actually assigns it a name.</para> 73 72 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> 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> 76 76 77 77 <itemizedlist> … … 89 89 ignore VLAN or bridge sub-interfaces (because these sub-interfaces do 90 90 not have drivers). These sub-interfaces are skipped because the name 91 that would be assigned would collide with the parent devices.</para>92 </listitem> 93 <listitem> 94 <para><literal>ATTR{address}</literal> - The value of this key wordis the91 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 95 NIC's MAC address.</para> 96 96 </listitem> … … 103 103 </listitem> 104 104 <listitem> 105 <para><literal>NAME</literal> - The value of this key wordis the name that105 <para><literal>NAME</literal> - The value of this key is the name that 106 106 udev will assign to this interface.</para> 107 107 </listitem> … … 111 111 you know which name has been assigned to each of your network cards before 112 112 proceeding, and be sure to use that <literal>NAME</literal> value when 113 creating your network configuration files.</para>113 creating your configuration files below.</para> 114 114 115 115 </sect3> … … 119 119 <sect2 revision="sysv"> 120 120 121 <title>CD-ROM Symlinks</title>121 <title>CD-ROM symlinks</title> 122 122 123 123 <para>Some software that you may want to install later (e.g., various 124 media players) expect sthe <filename class="symlink">/dev/cdrom</filename>124 media players) expect the <filename class="symlink">/dev/cdrom</filename> 125 125 and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and 126 126 to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put … … 140 140 on which type of device you have.</para> 141 141 142 <para>There are advantages to each approach; the correct approach 143 dependson what kinds of device changes may happen. If you expect the142 <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 144 physical path to the device (that is, the ports and/or slots that it plugs 145 145 into) to change, for example because you plan on moving the drive to a 146 146 different IDE port or a different USB connector, then you should use the 147 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 intend149 to replace it with a different device that150 plugsinto the same connectors, then you should use the148 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 151 <quote>by-path</quote> mode.</para> 152 152 … … 199 199 the same device. If you need that, then inspect (and possibly edit) the 200 200 generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> 201 file after booting, to make sure the assigned symlinks match your needs.</para>201 file after booting, to make sure the assigned symlinks match what you need.</para> 202 202 203 203 </sect2> … … 205 205 <sect2> 206 206 207 <title>Dealing with Duplicate Devices</title>207 <title>Dealing with duplicate devices</title> 208 208 209 209 <para>As explained in <xref linkend="ch-config-udev"/>, the order in … … 215 215 after a reboot the order changes. 216 216 For all classes of hardware except sound cards and network cards, this is 217 fixable by creating udev rules to createpersistent symlinks.217 fixable by creating udev rules for custom persistent symlinks. 218 218 The case of network cards is covered separately in 219 219 <xref linkend="ch-config-network"/>, and sound card configuration can
Note:
See TracChangeset
for help on using the changeset viewer.