aboutsummaryrefslogtreecommitdiffstats
path: root/chapter09/symlinks.xml
diff options
context:
space:
mode:
Diffstat (limited to 'chapter09/symlinks.xml')
-rw-r--r--chapter09/symlinks.xml74
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&mdash;on a computer with two
+ network cards made by Intel and Realtek, for instance&mdash;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>