Various fixes and additions for examples of custom rules in Udev courtesy

of Alexander Patrakov. Includes guidelines for persistent CD-ROM symlinks.


git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7661 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

chapter01/changelog.xml

@@ -38,6 +38,15 @@
     <listitem>
       <para>July 12, 20006</para>
       <itemizedlist>
+        <listitem>
+          <para>[dnicholson] - Various fixes and additions for examples
+          of custom rules in Udev courtesy of Alexander Patrakov. Added
+          the "Creating custom symlinks" page which includes examples
+          of creating persistent device symlinks, including CD-ROMs. Added
+          a second set of guidelines for creating persistent symlinks for
+          network cards. Other text touch ups on the configuration pages
+          involving Udev. Closes ticket #1818.</para>
+        </listitem>
         <listitem>
           <para>[bdubbs] - Updated udev-config and bootscripts download
           location.</para>

chapter07/chapter07.xml

@@ -22,6 +22,7 @@
   <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="profile.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="hostname.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="hosts.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="symlinks.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="network.xml"/>
 
 </chapter>

chapter07/network.xml

@@ -37,9 +37,10 @@
     Realtek card becomes  <filename class="devicefile">eth1</filename>. In some
     cases, after a reboot the cards get renumbered the other way around. To
     avoid this, create Udev rules that assign stable names to network cards
-    based on their MAC addresses.</para>
+    based on their MAC addresses or bus positions.</para>
 
-    <para>First, find out the MAC addresses of your network cards:</para>
+    <para>If you are going to use MAC addresses to identify your network
+    cards, find the addresses with the following command:</para>
 
 <screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen>
 
@@ -48,21 +49,36 @@
     Udev rules similar to the following:</para>
 
 <screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/26-network.rules &lt;&lt; "EOF"
-<literal>ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>52:54:00:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>"
-ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
+<literal>ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="<replaceable>00:e0:4c:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>"
+ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
+EOF</userinput></screen>
+
+    <para>The DRIVER=="?*" key prevents Udev from attempting to rename 8021Q
+    VLAN interfaces (not available without the Vlan package from
+    <ulink url="http://www.candelatech.com/~greear/vlan/"/>).
+    This is necessary since VLANs have the same MAC address as
+    the real network card.</para>
+
+<!-- Yes, I know that VLANs are beyond BLFS. This is not the reason to get them
+     incorrect by default when every distro does this right. -->
+ 
+    <para>If you are going to use the bus position as a key, create
+    Udev rules similar to the following:</para>
+
+<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/26-network.rules &lt;&lt; "EOF"
+<literal>ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0c.0</replaceable>", NAME="<replaceable>realtek</replaceable>"
+ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0d.0</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
 EOF</userinput></screen>
 
     <para>These rules will always rename the network cards to
-    <quote>realtek</quote> and <quote>intel</quote>, independently of the
-    original numbering provided by the kernel. Use these names instead of
-    <quote>eth0</quote> in the network interface configuration files created
+    <quote>realtek</quote> and <quote>intel</quote>, independently
+    of the original numbering provided by the kernel (i.e.: the original
+    <quote>eth0</quote> and <quote>eth1</quote> interfaces will no longer
+    exist, unless you put such <quote>descriptive</quote> names in the NAME
+    key). Use the descriptive names from the Udev rules instead
+    of <quote>eth0</quote> in the network interface configuration files
     below.</para>
 
-    <note>
-      <para>Persistent names must be different from the default network
-      interface names assigned by the kernel.</para>
-    </note>
-
   </sect2>
 
   <sect2>

chapter07/symlinks.xml

@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../general.ent">
+  %general-entities;
+]>
+
+<sect1 id="ch-scripts-symlinks">
+  <?dbhtml filename="symlinks.html"?>
+
+  <title>Creating custom symlinks to devices</title>
+
+  <sect2>
+
+    <title>CD-ROM symlinks</title>
+
+    <para>Some software that you may want to install later (e.g., various
+    media players) expect the /dev/cdrom and /dev/dvd symlinks to exist.
+    Also, it may be convenient to put references to those symlinks into
+    <filename>/etc/fstab</filename>. For each of your CD-ROM devices,
+    find the corresponding directory under
+    <filename class="directory">/sys</filename> (e.g., this can be
+    <filename class="directory">/sys/block/hdd</filename>) and
+    run a command similar to the following:</para>
+
+<screen role="nodump"><userinput>udevtest /block/hdd</userinput></screen>
+
+    <para>Look at the lines containing the output of various *_id programs.</para>
+
+    <para>There are two approaches to creating symlinks. The first one is to
+    use the model name and the serial number, the second one is based on the
+    location of the device on the bus. If you are going to use the first
+    approach, create a file similar to the following:</para>
+
+<screen role="nodump"><userinput>cat &gt;/etc/udev/rules.d/82-cdrom.rules &lt;&lt;"EOF"
+<literal>
+# Custom CD-ROM symlinks
+SUBSYSTEM=="block", ENV{ID_MODEL}=="SAMSUNG_CD-ROM_SC-148F", ENV{ID_REVISION}=="PS05", SYMLINK+="cdrom"
+SUBSYSTEM=="block", ENV{ID_MODEL}=="PHILIPS_CDD5301", ENV{ID_SERIAL}=="5VO1306DM00190", SYMLINK+="cdrom1 dvd"
+</literal>
+EOF</userinput></screen>
+
+    <para>This way, the symlinks will stay correct even if you move the drives
+    to different positions on the IDE bus, but the
+    <filename>/dev/cdrom</filename> symlink won't be created if you replace
+    the old SAMSUNG CD-ROM with a new drive.</para>
+<!-- The symlinks in the first approach survive even the transition
+     to libata for IDE drives, but that is not for the book. -->
+
+    <para>The SUBSYSTEM==&quot;block&quot; key is needed in order to avoid
+    matching SCSI generic devices. Without it, in the case with SCSI
+    CD-ROMs, the symlinks will sometimes point to the correct 
+    <filename>/dev/srX</filename> devices, and sometimes to
+    <filename>/dev/sgX</filename>, which is wrong.</para>
+ 
+    <para>The second approach yields:</para>
+
+<screen role="nodump"><userinput>cat &gt;/etc/udev/rules.d/82-cdrom.rules &lt;&lt;"EOF"
+<literal>
+# Custom CD-ROM symlinks
+SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-0:1", SYMLINK+="cdrom"
+SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", SYMLINK+="cdrom1 dvd"
+</literal>
+EOF</userinput></screen>
+
+    <para>This way, the symlinks will stay correct even if you replace drives
+    with different models, but place them to the old positions on the IDE
+    bus. The ENV{ID_TYPE}==&quot;cd&quot; key makes sure that the symlink
+    disappears if you put something other than a CD-ROM in that position on
+    the bus.</para>
+
+    <para>Of course, it is possible to mix the two approaches.</para>
+
+  </sect2>
+
+  <sect2>
+
+    <title>Dealing with duplicate devices</title>
+
+    <para>As explained in <xref linkend="ch-scripts-udev"/>, the order in
+    which devices with the same function appear in
+    <filename class="directory">/dev</filename> is essentially random.
+    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.
+    For all classes of hardware except sound cards and network cards, this is
+    fixable by creating udev rules for custom persistent symlinks.
+    The case of network cards is covered separately in
+    <xref linkend="ch-scripts-network"/>, and sound card configuration can
+    be found in <ulink url="&blfs-root;">BLFS</ulink>.</para>
+
+    <para>For each of your devices that is likely to have this problem
+    (even if the problem doesn't exist in your current Linux distribution),
+    find the corresponding directory under
+    <filename class="directory">/sys/class</filename> or
+    <filename class="directory">/sys/block</filename>.
+    For video devices, this may be
+    <filename
+    class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
+    Figure out the attributes that identify the device uniquely (usually,
+    vendor and product IDs and/or serial numbers work):</para>
+
+<screen role="nodump"><userinput>udevinfo -a -p /sys/class/video4linux/video0</userinput></screen>
+
+    <para>Then write rules that create the symlinks, e.g.:</para>
+
+<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*", SYSFS{idProduct}=="1910", SYSFS{idVendor}=="0d81", SYMLINK+="webcam"
+KERNEL=="video*", SYSFS{device}=="0x036f", SYSFS{vendor}=="0x109e", SYMLINK+="tvtuner"
+</literal>
+EOF</userinput></screen>
+
+    <para>The result is that <filename>/dev/video0</filename> and
+    <filename>/dev/video1</filename> devices still refer randomly to the tuner
+    and the web camera (and thus should never be used directly), but there are
+    symlinks <filename>/dev/tvtuner</filename> and
+    <filename>/dev/webcam</filename> that always point to the correct
+    device.</para>
+
+    <para>More information on writing Udev rules can be found in
+    <filename>/usr/share/doc/udev-&udev-version;/index.html</filename>.</para>
+
+ </sect2>
+
+</sect1>

chapter07/udev.xml

@@ -267,8 +267,7 @@
       <para>This usually happens if a rule unexpectedly matches a device. For
       example, a poorly-writen rule can match both a SCSI disk (as desired)
       and the corresponding SCSI generic device (incorrectly) by vendor.
-      Increase the logging verbosity of Udev, find the offending rule by
-      examining the logs and make it more specific.</para>
+      Find the offending rule and make it more specific.</para>
 
     </sect3>
 
@@ -316,8 +315,8 @@
       names being stable. Instead, create your own rules that make symlinks with
       stable names based on some stable attributes of the device, such as a
       serial number or the output of various *_id utilities installed by Udev.
-      See also the network interface renaming example in
-      <xref linkend="ch-scripts-network"/>.</para>
+      See <xref linkend="ch-scripts-symlinks"/> and
+      <xref linkend="ch-scripts-network"/> for examples.</para>
 
     </sect3>