mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-18 21:17:38 +00:00
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:
parent
6beb8ce055
commit
8972a361d0
@ -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—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 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>
|
||||
|
Loading…
Reference in New Issue
Block a user