Changes in chapter09/symlinks.xml [c34b4fb:8972a36]
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter09/symlinks.xml
rc34b4fb r8972a36 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 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 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 29 30 implemented.</para> 30 31 … … 32 33 <title>Disabling Persistent Naming on the Kernel Command Line</title> 33 34 34 <para>The traditional naming scheme using eth0, eth1, etc can be35 <para>The traditional naming scheme using eth0, eth1, etc. can be 35 36 restored by adding <userinput>net.ifnames=0</userinput> on the 36 kernel command line. This is most appropriate for thosesystems37 that have only one ethernet device of the sametype. Laptops38 often have multiple ethernet connections that arenamed eth0 and39 wlan0 and are also candidates forthis method. The command line40 is passedin the GRUB configuration file.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. 41 42 See <xref linkend="grub-cfg"/>.</para> 42 43 </sect3> … … 57 58 <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen> 58 59 59 <note><para>In some cases such as when MAC addresses have been assigned to60 a network card manually or in a virtual environment such as Qemu or Xen,61 the network rules file may not have beengenerated because addresses60 <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 62 63 are not consistently assigned. In these cases, this method cannot 63 64 be used.</para></note> 64 65 65 <para>The file begins with a comment block followed by two lines for each66 <para>The file begins with a comment block, followed by two lines for each 66 67 NIC. The first line for each NIC is a commented description showing its 67 68 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. Neither69 along with its driver (in parentheses, if the driver can be found). Neither 69 70 the hardware ID nor the driver is used to determine which name to give an 70 71 interface; this information is only for reference. The second line is the 71 72 udev rule that matches this NIC and actually assigns it a name.</para> 72 73 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> 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> 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 irparent devices.</para>92 </listitem> 93 <listitem> 94 <para><literal>ATTR{address}</literal> - The value of this key is the91 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 keyword 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 is the name that105 <para><literal>NAME</literal> - The value of this keyword 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 configuration files below.</para>113 creating your network configuration files.</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 the <filename class="symlink">/dev/cdrom</filename>124 media players) expects 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 to use143 will dependon what kinds of device changes may happen. If you expect the142 <para>There are advantages to each approach; the correct approach 143 depends 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 would149 replace it with a different device with the same capabilities and which150 is pluggedinto the same connectors, then you should use the148 identification to change, for example because it may die, and you intend 149 to replace it with a different device that 150 plugs 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 what you need.</para>201 file after booting, to make sure the assigned symlinks match your needs.</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 for custompersistent symlinks.217 fixable by creating udev rules to create 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.