Clean up / clarify disccussion; correct capitalization of titles.

Clarify discussion of "eth0" vs "enp5s0". Remove superfluous verbiage.
Improve punctuation. Patch grammatical errors (subject / verb).
Improve English idiom in a few places.
This commit is contained in:
David Bryant 2022-12-22 14:46:52 -06:00
parent 6beb8ce055
commit 8972a361d0

View File

@ -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>
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 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
<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>