Ticket #1804: udev.diff

File udev.diff, 11.2 KB (added by alexander@…, 18 years ago)

More udev changes

  • chapter07/udev.xml

     
    267267      <para>This usually happens if a rule unexpectedly matches a device. For
    268268      example, a poorly-writen rule can match both a SCSI disk (as desired)
    269269      and the corresponding SCSI generic device (incorrectly) by vendor.
    270       Increase the logging verbosity of Udev, find the offending rule by
    271       examining the logs and make it more specific.</para>
     270      Find the offending rule and make it more specific.</para>
    272271
    273272    </sect3>
    274273
     
    316315      names being stable. Instead, create your own rules that make symlinks with
    317316      stable names based on some stable attributes of the device, such as a
    318317      serial number or the output of various *_id utilities installed by Udev.
    319       See also the network interface renaming example in
    320       <xref linkend="ch-scripts-network"/>.</para>
     318      See <xref linkend="ch-scripts-symlinks"/> and
     319      <xref linkend="ch-scripts-network"/> for examples.</para>
    321320
    322321    </sect3>
    323322
  • chapter07/network.xml

     
    3737    Realtek card becomes  <filename class="devicefile">eth1</filename>. In some
    3838    cases, after a reboot the cards get renumbered the other way around. To
    3939    avoid this, create Udev rules that assign stable names to network cards
    40     based on their MAC addresses.</para>
     40    based on their MAC addresses or bus positions.</para>
    4141
    42     <para>First, find out the MAC addresses of your network cards:</para>
     42    <para>If you are going to use MAC addresses to identify your network
     43    cards, find them out:</para>
    4344
    4445<screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen>
    4546
     
    4849    Udev rules similar to the following:</para>
    4950
    5051<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/26-network.rules &lt;&lt; "EOF"
    51 <literal>ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>52:54:00:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>"
    52 ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
     52<literal>ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="<replaceable>00:e0:4c:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>"
     53ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
    5354EOF</userinput></screen>
    5455
    55     <para>These rules will always rename the network cards to
    56     <quote>realtek</quote> and <quote>intel</quote>, independently of the
    57     original numbering provided by the kernel. Use these names instead of
    58     <quote>eth0</quote> in the network interface configuration files created
     56    <para>The DRIVER=="?*" key prevents Udev from attempting to rename 8021Q
     57    VLAN interfaces (not available without the Vlan package from
     58    <ulink url="http://www.candelatech.com/~greear/vlan/"/>).
     59    This is necessary since VLANs have the same MAC address as
     60    the real network card.</para>
     61
     62<!-- Yes, I know that VLANs are beyond BLFS. This is not the reason to get them
     63     incorrect by default when every distro does this right. -->
     64 
     65    <para>If you are going to use the bus position as a key, create
     66    Udev rules similar to the following:</para>
     67
     68<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/26-network.rules &lt;&lt; "EOF"
     69<literal>ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0c.0</replaceable>", NAME="<replaceable>realtek</replaceable>"
     70ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", ID=="<replaceable>0000:00:0d.0</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
     71EOF</userinput></screen>
     72
     73   <para>These rules will always rename the network cards to
     74    <quote>realtek</quote> and <quote>intel</quote>, independently
     75    of the original numbering provided by the kernel (i.e.: the original
     76    <quote>eth0</quote> and <quote>eth1</quote> interfaces will no longer
     77    exist, unless you put such <quote>descriptive</quote> names in the NAME
     78    key). Use the descriptive names from the Udev rules instead
     79    of <quote>eth0</quote> in the network interface configuration files
    5980    below.</para>
    6081
    61     <note>
    62       <para>Persistent names must be different from the default network
    63       interface names assigned by the kernel.</para>
    64     </note>
    65 
    6682  </sect2>
    6783
    6884  <sect2>
  • chapter07/symlinks.xml

     
     1<?xml version="1.0" encoding="ISO-8859-1"?>
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     4  <!ENTITY % general-entities SYSTEM "../general.ent">
     5  %general-entities;
     6]>
     7
     8<sect1 id="ch-scripts-symlinks">
     9  <?dbhtml filename="symlinks.html"?>
     10
     11  <title>Creating custom symlinks to devices</title>
     12  <sect2>
     13    <title>CD-ROM symlinks</title>
     14    <para>Some software that you may want to install later (e.g., various
     15    media players) expect the /dev/cdrom and /dev/dvd symlinks to exist.
     16    Also, it may be convenient to put references to those symlinks into
     17    <filename>/etc/fstab</filename>. For each of your CD-ROM devices,
     18    find the corresponding directory under
     19    <filename class="directory">/sys</filename> (e.g., this can be
     20    <filename class="directory">/sys/block/hdd</filename>) and
     21    run a command similar to the following:</para>
     22
     23<screen role="nodump"><userinput>udevtest /block/hdd</userinput></screen>
     24
     25    <para>Look at the lines containing the output of various *_id programs.</para>
     26
     27    <para>There are two approaches to creating symlinks. The first one is to
     28    use the model name and the serial number, the second one is based on the
     29    location of the device on the bus. If you are going to use the first
     30    approach, create a file similar to the following:</para>
     31
     32<screen role="nodump"><userinput>cat &gt;/etc/udev/rules.d/82-cdrom.rules &lt;&lt;"EOF"
     33<literal>
     34# Custom CD-ROM symlinks
     35SUBSYSTEM=="block", ENV{ID_MODEL}=="SAMSUNG_CD-ROM_SC-148F", ENV{ID_REVISION}=="PS05", SYMLINK+="cdrom"
     36SUBSYSTEM=="block", ENV{ID_MODEL}=="PHILIPS_CDD5301", ENV{ID_SERIAL}=="5VO1306DM00190", SYMLINK+="cdrom1 dvd"
     37</literal>
     38EOF</userinput></screen>
     39
     40   <para>This way, the symlinks will stay correct even if you move the drives
     41    to different positions on the IDE bus, but the
     42    <filename>/dev/cdrom</filename> symlink won't be created if you replace
     43    the old SAMSUNG CD-ROM with a new drive.</para>
     44<!-- The symlinks in the first approach survive even the transition
     45     to libata for IDE drives, but that is not for the book. -->
     46
     47    <para>The SUBSYSTEM=="block" key is needed in order to avoid matching SCSI
     48    generic devices. Without it, in the case with SCSI CD-ROMs, the symlinks
     49    will sometimes point to the correct <filename>/dev/srX</filename>
     50    devices, and sometimes to <filename>/dev/sgX</filename>, which is
     51    wrong.</para>
     52 
     53    <para>The second approach yields:</para>
     54
     55<screen role="nodump"><userinput>cat &gt;/etc/udev/rules.d/82-cdrom.rules &lt;&lt;"EOF"
     56<literal>
     57# Custom CD-ROM symlinks
     58SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-0:1", SYMLINK+="cdrom"
     59SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", SYMLINK+="cdrom1 dvd"
     60</literal>
     61EOF</userinput></screen>
     62
     63    <para>This way, the symlinks will stay correct even if you repace drives
     64    with different models, but place them to the old positions on the IDE
     65    bus. The ENV{ID_TYPE}=="cd" key makes sure that the symlink disappears if
     66    you put something other than a CD-ROM in that position on the bus.</para>
     67
     68    <para>Of course, it is possible to mix the two approaches.</para>
     69  </sect2>
     70
     71  <sect2>
     72    <title>Dealing with duplicate devices</title>
     73    <para>As explained in <xref linkend="ch-scripts-udev"/>, the order in which
     74    devices with the same function appear in
     75    <filename class="directory">/dev</filename> is essentially random.
     76    E.g., if you have a USB web camera and a TV tuner, sometimes
     77    <filename>/dev/video0</filename> refers to the camera and
     78    <filename>/dev/video1</filename> refers to te tuner, and sometimes
     79    after a reboot the order changes to the opposite one.
     80    For all classes of hardware except sound cards and network cards, this is
     81    fixable by creating udev rules for custom persistent symlinks.
     82    The case of network cards is covered separately in
     83    <xref linkend="ch-scripts-network"/>, and sound card configuration can
     84    be found in BLFS.</para>
     85
     86    <para>For each of your devices that is likely to have this problem
     87    (even if the problem doesn't exist in your current Linux distribution),
     88    find the corresponding directory under
     89    <filename class="directory">/sys/class</filename> or
     90    <filename class="directory">/sys/block</filename>.
     91    For video devices, this may be
     92    <filename class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
     93    Figure out the attributes that identify the device uniquely (usually,
     94    vendor and product IDs and/or serial numbers work):</para>
     95<screen role="nodump"><userinput>udevinfo -a -p /sys/class/video4linux/video0</userinput></screen>
     96    <para>Then write rules that create the symlinks, e.g.:</para>
     97<screen role="nodump"><userinput>cat &gt;/etc/udev/rules.d/83-duplicate_devs.rules &lt;&lt;"EOF"
     98<literal>
     99# Persistent symlinks for webcam and tuner
     100KERNEL=="video*", SYSFS{idProduct}=="1910", SYSFS{idVendor}=="0d81", SYMLINK+="webcam"
     101KERNEL=="video*", SYSFS{device}=="0x036f", SYSFS{vendor}=="0x109e", SYMLINK+="tvtuner"
     102</literal>
     103EOF</userinput></screen>
     104    <para>The result is that <filename>/dev/video0</filename> and
     105    <filename>/dev/video1</filename> devices still refer randomly to the tuner
     106    and the web camera (and thus should never be used directly), but there are
     107    symlinks <filename>/dev/tvtuner</filename> and
     108    <filename>/dev/webcam</filename> that always point to the correct
     109    device.</para>
     110
     111    <para>More information on writing Udev rules can be found in
     112    <filename>/usr/share/doc/udev-&udev-version;/index.html</filename>.</para>
     113 </sect2>
     114
     115</sect1>
  • chapter07/chapter07.xml

     
    2222  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="profile.xml"/>
    2323  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="hostname.xml"/>
    2424  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="hosts.xml"/>
     25  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="symlinks.xml"/>
    2526  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="network.xml"/>
    2627
    2728</chapter>