diff options
| -rw-r--r-- | chapter09/symlinks.xml | 74 |
1 files changed, 37 insertions, 37 deletions
diff --git a/chapter09/symlinks.xml b/chapter09/symlinks.xml index 24ebf537d..86528ba69 100644 --- a/chapter09/symlinks.xml +++ b/chapter09/symlinks.xml @@ -17,27 +17,28 @@ <para>Udev, by default, names network devices according to Firmware/BIOS data or physical characteristics like the bus, slot, or MAC address. The purpose of this naming convention is to ensure that network devices are - named consistently and not based on the time the network card was - discovered. For example, on a computer having two network cards made by - Intel and Realtek, the network card manufactured by Intel may become eth0 - and the Realtek card becomes eth1. In some cases, after a reboot the cards - could get renumbered the other way around.</para> - - <para>In the new naming scheme, typical network device names would then - be something like enp5s0 or wlp3s0. If this naming convention is not - desired, the traditional naming scheme or a custom scheme can be + named consistently, not based on when the network card was + discovered. In older versions of Linux—on a computer with two + network cards made by Intel and Realtek, for instance—the + network card manufactured by Intel might have become eth0 + while the Realtek card became eth1. After a reboot, the cards + would sometimes get renumbered the other way around.</para> + + <para>In the new naming scheme, typical network device names are + something like enp5s0 or wlp3s0. If this naming convention is not + desired, the traditional naming scheme, or a custom scheme, can be implemented.</para> <sect3> <title>Disabling Persistent Naming on the Kernel Command Line</title> - <para>The traditional naming scheme using eth0, eth1, etc can be + <para>The traditional naming scheme using eth0, eth1, etc. can be restored by adding <userinput>net.ifnames=0</userinput> on the - kernel command line. This is most appropriate for those systems - that have only one ethernet device of the same type. Laptops - often have multiple ethernet connections that are named eth0 and - wlan0 and are also candidates for this method. The command line - is passed in the GRUB configuration file. + kernel command line. This is most appropriate for systems + that have just one ethernet device of a particular type. Laptops + often have two ethernet connections named eth0 and + wlan0; such laptops can also use this method. The command line + is in the GRUB configuration file. See <xref linkend="grub-cfg"/>.</para> </sect3> @@ -56,23 +57,22 @@ <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen> - <note><para>In some cases such as when MAC addresses have been assigned to - a network card manually or in a virtual environment such as Qemu or Xen, - the network rules file may not have been generated because addresses + <note><para>In some cases, such as when MAC addresses have been assigned to + a network card manually, or in a virtual environment such as Qemu or Xen, + the network rules file may not be generated because addresses are not consistently assigned. In these cases, this method cannot be used.</para></note> - <para>The file begins with a comment block followed by two lines for each + <para>The file begins with a comment block, followed by two lines for each NIC. The first line for each NIC is a commented description showing its hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card), - along with its driver in parentheses, if the driver can be found. Neither + along with its driver (in parentheses, if the driver can be found). Neither the hardware ID nor the driver is used to determine which name to give an interface; this information is only for reference. The second line is the udev rule that matches this NIC and actually assigns it a name.</para> - <para>All udev rules are made up of several keys, separated by commas and - optional whitespace. This rule's keys and an explanation of each of them - are as follows:</para> + <para>All udev rules are made up of several keywords, separated by commas and + optional whitespace. Here are the keywords, and an explanation of each one:</para> <itemizedlist> <listitem> @@ -88,10 +88,10 @@ <para><literal>DRIVERS=="?*"</literal> - This exists so that udev will ignore VLAN or bridge sub-interfaces (because these sub-interfaces do not have drivers). These sub-interfaces are skipped because the name - that would be assigned would collide with their parent devices.</para> + that would be assigned would collide with the parent devices.</para> </listitem> <listitem> - <para><literal>ATTR{address}</literal> - The value of this key is the + <para><literal>ATTR{address}</literal> - The value of this keyword is the NIC's MAC address.</para> </listitem> <listitem> @@ -102,7 +102,7 @@ skipped: there would be a name collision otherwise.</para> </listitem> <listitem> - <para><literal>NAME</literal> - The value of this key is the name that + <para><literal>NAME</literal> - The value of this keyword is the name that udev will assign to this interface.</para> </listitem> </itemizedlist> @@ -110,7 +110,7 @@ <para>The value of <literal>NAME</literal> is the important part. Make sure you know which name has been assigned to each of your network cards before proceeding, and be sure to use that <literal>NAME</literal> value when - creating your configuration files below.</para> + creating your network configuration files.</para> </sect3> @@ -118,10 +118,10 @@ <sect2 revision="sysv"> - <title>CD-ROM symlinks</title> + <title>CD-ROM Symlinks</title> <para>Some software that you may want to install later (e.g., various - media players) expect the <filename class="symlink">/dev/cdrom</filename> + media players) expects the <filename class="symlink">/dev/cdrom</filename> and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put references to those symlinks into <filename>/etc/fstab</filename>. Udev @@ -139,15 +139,15 @@ <command>ata_id</command> or <command>scsi_id</command> programs, depending on which type of device you have.</para> - <para>There are advantages to each approach; the correct approach to use - will depend on what kinds of device changes may happen. If you expect the + <para>There are advantages to each approach; the correct approach + depends on what kinds of device changes may happen. If you expect the physical path to the device (that is, the ports and/or slots that it plugs into) to change, for example because you plan on moving the drive to a different IDE port or a different USB connector, then you should use the <quote>by-id</quote> mode. On the other hand, if you expect the device's - identification to change, for example because it may die, and you would - replace it with a different device with the same capabilities and which - is plugged into the same connectors, then you should use the + identification to change, for example because it may die, and you intend + to replace it with a different device that + plugs into the same connectors, then you should use the <quote>by-path</quote> mode.</para> <para>If either type of change is possible with your drive, then choose a @@ -198,13 +198,13 @@ this is only an issue if you need the symlinks on both systems to point to the same device. If you need that, then inspect (and possibly edit) the generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> - file after booting, to make sure the assigned symlinks match what you need.</para> + file after booting, to make sure the assigned symlinks match your needs.</para> </sect2> <sect2> - <title>Dealing with duplicate devices</title> + <title>Dealing with Duplicate Devices</title> <para>As explained in <xref linkend="ch-config-udev"/>, the order in which devices with the same function appear in @@ -214,7 +214,7 @@ <filename>/dev/video1</filename> refers to the tuner, and sometimes after a reboot the order changes. For all classes of hardware except sound cards and network cards, this is - fixable by creating udev rules for custom persistent symlinks. + fixable by creating udev rules to create persistent symlinks. The case of network cards is covered separately in <xref linkend="ch-config-network"/>, and sound card configuration can be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para> |