[966b175] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
[b06ca36] | 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
---|
[966b175] | 4 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
| 7 |
|
---|
| 8 | <sect1 id="ch-scripts-symlinks">
|
---|
| 9 | <?dbhtml filename="symlinks.html"?>
|
---|
| 10 |
|
---|
[2a135aa] | 11 | <title>Creating Custom Symlinks to Devices</title>
|
---|
[966b175] | 12 |
|
---|
| 13 | <sect2>
|
---|
| 14 |
|
---|
| 15 | <title>CD-ROM symlinks</title>
|
---|
| 16 |
|
---|
| 17 | <para>Some software that you may want to install later (e.g., various
|
---|
[84dbfdac] | 18 | media players) expect the <filename class="symlink">/dev/cdrom</filename>
|
---|
| 19 | and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and
|
---|
| 20 | to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put
|
---|
| 21 | references to those symlinks into <filename>/etc/fstab</filename>. Udev
|
---|
| 22 | comes with a script that will generate rules files to create these symlinks
|
---|
| 23 | for you, depending on the capabilities of each device, but you need to
|
---|
| 24 | decide which of two modes of operation you wish to have the script use.</para>
|
---|
| 25 |
|
---|
[8536c02] | 26 | <para>First, the script can operate in <quote>by-path</quote> mode (used by
|
---|
| 27 | default for USB and FireWire devices), where the rules it creates depend on
|
---|
| 28 | the physical path to the CD or DVD device. Second, it can operate in
|
---|
| 29 | <quote>by-id</quote> mode (default for IDE and SCSI devices), where the
|
---|
| 30 | rules it creates depend on identification strings stored in the CD or DVD
|
---|
| 31 | device itself. The path is determined by Udev's <command>path_id</command>
|
---|
| 32 | script, and the identification strings are read from the hardware by its
|
---|
[84dbfdac] | 33 | <command>ata_id</command> or <command>scsi_id</command> programs, depending
|
---|
| 34 | on which type of device you have.</para>
|
---|
| 35 |
|
---|
| 36 | <para>There are advantages to each approach; the correct approach to use
|
---|
| 37 | will depend on what kinds of device changes may happen. If you expect the
|
---|
| 38 | physical path to the device (that is, the ports and/or slots that it plugs
|
---|
| 39 | into) to change, for example because you plan on moving the drive to a
|
---|
| 40 | different IDE port or a different USB connector, then you should use the
|
---|
| 41 | <quote>by-id</quote> mode. On the other hand, if you expect the device's
|
---|
| 42 | identification to change, for example because it may die, and you would
|
---|
| 43 | replace it with a different device with the same capabilities and which
|
---|
| 44 | is plugged into the same connectors, then you should use the
|
---|
| 45 | <quote>by-path</quote> mode.</para>
|
---|
| 46 |
|
---|
| 47 | <para>If either type of change is possible with your drive, then choose a
|
---|
| 48 | mode based on the type of change you expect to happen more often.</para>
|
---|
| 49 |
|
---|
| 50 | <!-- If you use by-id mode, the symlinks will survive even the transition
|
---|
| 51 | to libata for IDE drives, but that is not for the book. -->
|
---|
| 52 |
|
---|
[80640a49] | 53 | <important><para>External devices (for example, a USB-connected CD drive)
|
---|
| 54 | should not use by-path persistence, because each time the device is plugged
|
---|
| 55 | into a new external port, its physical path will change. All
|
---|
| 56 | externally-connected devices will have this problem if you write Udev rules
|
---|
| 57 | to recognize them by their physical path; the problem is not limited to CD
|
---|
| 58 | and DVD drives.</para></important>
|
---|
[84dbfdac] | 59 |
|
---|
| 60 | <para>If you wish to see the values that the Udev scripts will use, then
|
---|
| 61 | for the appropriate CD-ROM device, find the corresponding directory under
|
---|
[966b175] | 62 | <filename class="directory">/sys</filename> (e.g., this can be
|
---|
| 63 | <filename class="directory">/sys/block/hdd</filename>) and
|
---|
| 64 | run a command similar to the following:</para>
|
---|
| 65 |
|
---|
[61e63d3] | 66 | <screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
|
---|
[84dbfdac] | 67 |
|
---|
| 68 | <para>Look at the lines containing the output of various *_id programs.
|
---|
| 69 | The <quote>by-id</quote> mode will use the ID_SERIAL value if it exists and
|
---|
| 70 | is not empty, otherwise it will use a combination of ID_MODEL and
|
---|
| 71 | ID_REVISION. The <quote>by-path</quote> mode will use the ID_PATH value.</para>
|
---|
| 72 |
|
---|
[8536c02] | 73 | <para>If the default mode is not suitable for your situation, then the
|
---|
| 74 | following modification can be made to the
|
---|
[84dbfdac] | 75 | <filename>/etc/udev/rules.d/75-cd-aliases-generator.rules</filename> file,
|
---|
[8536c02] | 76 | as follows (where <replaceable>mode</replaceable> is one of
|
---|
| 77 | <quote>by-id</quote> or <quote>by-path</quote>):</para>
|
---|
[84dbfdac] | 78 |
|
---|
[fbfd0b5] | 79 | <screen role="nodump"><userinput>sed -i -e 's/write_cd_rules/& <replaceable>mode</replaceable>/' \
|
---|
[84dbfdac] | 80 | /etc/udev/rules.d/75-cd-aliases-generator.rules</userinput></screen>
|
---|
[966b175] | 81 |
|
---|
[84dbfdac] | 82 | <para>Note that it is not necessary to create the rules files or symlinks
|
---|
| 83 | at this time, because you have bind-mounted the host's
|
---|
| 84 | <filename class="directory">/dev</filename> directory into the LFS system,
|
---|
[651719a] | 85 | and we assume the symlinks exist on the host. The rules and symlinks will
|
---|
| 86 | be created the first time you boot your LFS system.</para>
|
---|
[a3b689f] | 87 |
|
---|
[651719a] | 88 | <para>However, if you have multiple CD-ROM devices, then the symlinks
|
---|
| 89 | generated at that time may point to different devices than they point to on
|
---|
| 90 | your host, because devices are not discovered in a predictable order. The
|
---|
| 91 | assignments created when you first boot the LFS system will be stable, so
|
---|
| 92 | this is only an issue if you need the symlinks on both systems to point to
|
---|
| 93 | the same device. If you need that, then inspect (and possibly edit) the
|
---|
| 94 | generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename>
|
---|
| 95 | file after booting, to make sure the assigned symlinks match what you need.</para>
|
---|
[966b175] | 96 |
|
---|
| 97 | </sect2>
|
---|
| 98 |
|
---|
| 99 | <sect2>
|
---|
| 100 |
|
---|
| 101 | <title>Dealing with duplicate devices</title>
|
---|
| 102 |
|
---|
| 103 | <para>As explained in <xref linkend="ch-scripts-udev"/>, the order in
|
---|
| 104 | which devices with the same function appear in
|
---|
| 105 | <filename class="directory">/dev</filename> is essentially random.
|
---|
| 106 | E.g., if you have a USB web camera and a TV tuner, sometimes
|
---|
| 107 | <filename>/dev/video0</filename> refers to the camera and
|
---|
| 108 | <filename>/dev/video1</filename> refers to the tuner, and sometimes
|
---|
| 109 | after a reboot the order changes to the opposite one.
|
---|
| 110 | For all classes of hardware except sound cards and network cards, this is
|
---|
| 111 | fixable by creating udev rules for custom persistent symlinks.
|
---|
| 112 | The case of network cards is covered separately in
|
---|
| 113 | <xref linkend="ch-scripts-network"/>, and sound card configuration can
|
---|
| 114 | be found in <ulink url="&blfs-root;">BLFS</ulink>.</para>
|
---|
| 115 |
|
---|
| 116 | <para>For each of your devices that is likely to have this problem
|
---|
| 117 | (even if the problem doesn't exist in your current Linux distribution),
|
---|
| 118 | find the corresponding directory under
|
---|
| 119 | <filename class="directory">/sys/class</filename> or
|
---|
| 120 | <filename class="directory">/sys/block</filename>.
|
---|
| 121 | For video devices, this may be
|
---|
| 122 | <filename
|
---|
| 123 | class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
|
---|
| 124 | Figure out the attributes that identify the device uniquely (usually,
|
---|
| 125 | vendor and product IDs and/or serial numbers work):</para>
|
---|
| 126 |
|
---|
[61e63d3] | 127 | <screen role="nodump"><userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput></screen>
|
---|
[966b175] | 128 |
|
---|
| 129 | <para>Then write rules that create the symlinks, e.g.:</para>
|
---|
| 130 |
|
---|
[8857ace2] | 131 | <screen role="nodump"><userinput>cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
|
---|
[966b175] | 132 | <literal>
|
---|
| 133 | # Persistent symlinks for webcam and tuner
|
---|
[659cc3d] | 134 | KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
|
---|
[c226182] | 135 | SYMLINK+="webcam"
|
---|
[659cc3d] | 136 | KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
|
---|
[c226182] | 137 | SYMLINK+="tvtuner"
|
---|
[966b175] | 138 | </literal>
|
---|
| 139 | EOF</userinput></screen>
|
---|
| 140 |
|
---|
| 141 | <para>The result is that <filename>/dev/video0</filename> and
|
---|
| 142 | <filename>/dev/video1</filename> devices still refer randomly to the tuner
|
---|
| 143 | and the web camera (and thus should never be used directly), but there are
|
---|
| 144 | symlinks <filename>/dev/tvtuner</filename> and
|
---|
| 145 | <filename>/dev/webcam</filename> that always point to the correct
|
---|
| 146 | device.</para>
|
---|
| 147 |
|
---|
| 148 | <para>More information on writing Udev rules can be found in
|
---|
| 149 | <filename>/usr/share/doc/udev-&udev-version;/index.html</filename>.</para>
|
---|
| 150 |
|
---|
| 151 | </sect2>
|
---|
| 152 |
|
---|
| 153 | </sect1>
|
---|