mirrors/lfs
2
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2026-07-16 07:42:03 -04:00
Code Issues Packages Projects Releases Wiki Activity

Text updated for cross2 chapter 9

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross2@11928 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Bruce Dubbs
2020-06-12 20:42:32 +00:00
parent 96f04d7906
commit a3d0817020
8 changed files with 61 additions and 251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
chapter09/symlinks.xml
View File

@@ -21,7 +21,7 @@
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
get renumbered the other way around.</para>
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
@@ -44,7 +44,7 @@
<sect3>
<title>Creating Custom Udev Rules</title>
<para>The naming scheme can be customized by creating custom Udev
<para>The naming scheme can be customized by creating custom udev
rules. A script has been included that generates the initial rules.
Generate these rules by running:</para>
@@ -68,24 +68,24 @@
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>
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
<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>
<itemizedlist>
<listitem>
<para><literal>SUBSYSTEM=="net"</literal> - This tells Udev to ignore
<para><literal>SUBSYSTEM=="net"</literal> - This tells udev to ignore
devices that are not network cards.</para>
</listitem>
<listitem>
<para><literal>ACTION=="add"</literal> - This tells Udev to ignore this
<para><literal>ACTION=="add"</literal> - This tells udev to ignore this
rule for a uevent that isn't an add ("remove" and "change" uevents also
happen, but don't need to rename network interfaces).</para>
</listitem>
<listitem>
<para><literal>DRIVERS=="?*"</literal> - This exists so that Udev will
<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>
@@ -96,14 +96,14 @@
</listitem>
<listitem>
<para><literal>ATTR{type}=="1"</literal> - This ensures the rule only
matches the primary interface in the case of certain wireless drivers,
matches the primary interface in the case of certain wireless drivers
which create multiple virtual interfaces. The secondary interfaces are
skipped for the same reason that VLAN and bridge sub-interfaces are
skipped: there would be a name collision otherwise.</para>
</listitem>
<listitem>
<para><literal>NAME</literal> - The value of this key is the name that
Udev will assign to this interface.</para>
udev will assign to this interface.</para>
</listitem>
</itemizedlist>
@@ -133,8 +133,8 @@
default for USB and FireWire devices), where the rules it creates depend on
the physical path to the CD or DVD device. Second, it can operate in
<quote>by-id</quote> mode (default for IDE and SCSI devices), where the
rules it creates depend on identification strings stored in the CD or DVD
device itself. The path is determined by Udev's <command>path_id</command>
rules it creates depend on identification strings stored on the CD or DVD
device itself. The path is determined by udev's <command>path_id</command>
script, and the identification strings are read from the hardware by its
<command>ata_id</command> or <command>scsi_id</command> programs, depending
on which type of device you have.</para>
@@ -159,11 +159,11 @@
<important><para>External devices (for example, a USB-connected CD drive)
should not use by-path persistence, because each time the device is plugged
into a new external port, its physical path will change. All
externally-connected devices will have this problem if you write Udev rules
externally-connected devices will have this problem if you write udev rules
to recognize them by their physical path; the problem is not limited to CD
and DVD drives.</para></important>
<para>If you wish to see the values that the Udev scripts will use, then
<para>If you wish to see the values that the udev scripts will use, then
for the appropriate CD-ROM device, find the corresponding directory under
<filename class="directory">/sys</filename> (e.g., this can be
<filename class="directory">/sys/block/hdd</filename>) and
@@ -182,18 +182,18 @@
as follows (where <replaceable>mode</replaceable> is one of
<quote>by-id</quote> or <quote>by-path</quote>):</para>
<screen role="nodump"><userinput>sed -i -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
/etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
<screen role="nodump"><userinput>sed -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
-i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
<para>Note that it is not necessary to create the rules files or symlinks
at this time, because you have bind-mounted the host's
<filename class="directory">/dev</filename> directory into the LFS system,
at this time because you have bind-mounted the host's
<filename class="directory">/dev</filename> directory into the LFS system
and we assume the symlinks exist on the host. The rules and symlinks will
be created the first time you boot your LFS system.</para>
<para>However, if you have multiple CD-ROM devices, then the symlinks
generated at that time may point to different devices than they point to on
your host, because devices are not discovered in a predictable order. The
your host because devices are not discovered in a predictable order. The
assignments created when you first boot the LFS system will be stable, so
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
@@ -212,9 +212,9 @@
E.g., if you have a USB web camera and a TV tuner, sometimes
<filename>/dev/video0</filename> refers to the camera and
<filename>/dev/video1</filename> refers to the tuner, and sometimes
after a reboot the order changes to the opposite one.
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 for custom 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>
@@ -237,10 +237,8 @@
<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/83-duplicate_devs.rules &lt;&lt; "EOF"
<literal>
# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
SYMLINK+="tvtuner"
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"
</literal>
EOF</userinput></screen>