Upgrade Udev to 122, udev-config to 20080522, and lfs-bootscripts to 20080522. Replace "write_net_rules all_interfaces" with a "udevadm test" loop. Fix several typos. Remove the usb_id segfault patch, as it's included in Udev now. Add /lib/udev/devices/kmsg, as udevd uses /dev/kmsg to log a message at startup. Replace udevtrigger/udevinfo with "udevadm trigger" and "udevadm info" in the text.

Should fix #2057, #2079, #2170, and #2186.


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

3 files changed, 44 insertions, 29 deletions

diff --git a/chapter07/network.xml b/chapter07/network.xml
index f3159a571..cf6762e5c 100644
--- a/chapter07/network.xml
+++ b/chapter07/network.xml
@@ -39,7 +39,9 @@
     <para>Pre-generate the rules to ensure the same names get assigned to the
     same devices at every boot, including the first:</para>
 
-<screen><userinput>/lib/udev/write_net_rules all_interfaces</userinput></screen>
+<screen><userinput>for NIC in /sys/class/net/* ; do
+    INTERFACE=${NIC##*/} udevadm test --action=add --subsystem=net $NIC
+done</userinput></screen>
 
     <para>Now, inspect the <filename>/etc/udev/rules.d/70-persistent-net.rules</filename>
     file, to find out which name was assigned to which network device:</para>
@@ -48,14 +50,14 @@
 
     <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 PC vendor and device IDs, if it's a PCI card),
+    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
     the hardware ID nor the driver is used to determine which name to give an
-    interface. The second line is the Udev rule that matches this NIC and
-    actually assigns it a name.</para>
+    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 explanations of each of them
+    optional whitespace. This rule's keys and an explanation of each of them
     are as follows:</para>
 
     <itemizedlist>
@@ -64,22 +66,34 @@
         devices that are not network cards.</para>
       </listitem>
       <listitem>
+        <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
         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>
       </listitem>
       <listitem>
-        <para><literal>ATTRS{type}=="1"</literal> - Optional. This key will
-        only be added if this NIC is a wireless NIC whose driver creates
-        multiple virtual interfaces; it ensures the rule only matches the
-        primary interface. The secondary interfaces are not matched for the
-        same reason that VLAN and bridge sub-interfaces are not matched: there
-        would be a name collision.</para>
+        <para><literal>ATTR{address}</literal> - The value of this key is the
+        NIC's MAC address.</para>
+      </listitem>
+      <listitem>
+        <para><literal>ATTR{type}=="1"</literal> - This ensures the rule only
+        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>ATTRS{address}</literal> - The value of this key is the
-        NIC's MAC address.</para>
+        <para><literal>KERNEL=="eth*"</literal> - This key was added to the
+        Udev rule generator to handle machines that have multiple network
+        interfaces, all with the same MAC address (the PS3 is one such
+        machine).  If the independent interfaces have different basenames,
+        this key will allow Udev to tell them apart.  This is generally not
+        necessary for most Linux From Scratch users, but does not hurt.</para>
       </listitem>
       <listitem>
         <para><literal>NAME</literal> - The value of this key is the name that
diff --git a/chapter07/symlinks.xml b/chapter07/symlinks.xml
index 4b0aafeed..1ddfa62ea 100644
--- a/chapter07/symlinks.xml
+++ b/chapter07/symlinks.xml
@@ -63,7 +63,7 @@
     <filename class="directory">/sys/block/hdd</filename>) and
     run a command similar to the following:</para>
 
-<screen role="nodump"><userinput>udevtest /sys/block/hdd</userinput></screen>
+<screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
 
     <para>Look at the lines containing the output of various *_id programs.
     The <quote>by-id</quote> mode will use the ID_SERIAL value if it exists and
@@ -124,7 +124,7 @@
     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>
+<screen role="nodump"><userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput></screen>
 
     <para>Then write rules that create the symlinks, e.g.:</para>
 
diff --git a/chapter07/udev.xml b/chapter07/udev.xml
index e64fdf191..00afb06e7 100644
--- a/chapter07/udev.xml
+++ b/chapter07/udev.xml
@@ -105,14 +105,14 @@
       class="directory">/lib/udev/devices</filename> to <filename
       class="directory">/dev</filename>. This is necessary because some devices,
       directories, and symlinks are needed before the dynamic device handling
-      processes are available during the early stages of booting a system.
-      Creating static device nodes in <filename
-      class="directory">/lib/udev/devices</filename> also provides an easy
-      workaround for devices that are not supported by the dynamic device
-      handling infrastructure. The bootscript then starts the Udev daemon,
-      <command>udevd</command>, which will act on any uevents it receives.
-      Finally, the bootscript forces the kernel to replay uevents for any
-      devices that have already been registered and then waits for
+      processes are available during the early stages of booting a system, or
+      are required by <command>udevd</command> itself.  Creating static device
+      nodes in <filename class="directory">/lib/udev/devices</filename> also
+      provides an easy workaround for devices that are not supported by the
+      dynamic device handling infrastructure. The bootscript then starts the
+      Udev daemon, <command>udevd</command>, which will act on any uevents it
+      receives. Finally, the bootscript forces the kernel to replay uevents for
+      any devices that have already been registered and then waits for
       <command>udevd</command> to handle them.</para>
 
     </sect3>
@@ -155,9 +155,9 @@
       <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
       might contain the string
       <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
-      The rules that LFS installs will cause <command>udevd</command> to call
-      out to <command>/sbin/modprobe</command> with the contents of the
-      <envar>MODALIAS</envar> uevent environment variable (that should be the
+      The default rules provided with Udev will cause <command>udevd</command>
+      to call out to <command>/sbin/modprobe</command> with the contents of the
+      <envar>MODALIAS</envar> uevent environment variable (which should be the
       same as the contents of the <filename>modalias</filename> file in sysfs),
       thus loading all modules whose aliases match this string after wildcard
       expansion.</para>
@@ -268,7 +268,8 @@
       <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.
-      Find the offending rule and make it more specific.</para>
+      Find the offending rule and make it more specific, with the help of the
+      <command>udevadm info</command> command.</para>
 
     </sect3>
 
@@ -281,8 +282,8 @@
       For now, you can work around it by creating a rule that waits for the used
       <systemitem class="filesystem">sysfs</systemitem> attribute and appending
       it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>
-      file. Please notify the LFS Development list if you do so and it
-      helps.</para>
+      file (create this file if it does not exist). Please notify the LFS
+      Development list if you do so and it helps.</para>
 
     </sect3>