symlinks.xml 6.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153
  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. <sect1 id="ch-scripts-symlinks">
  8. <?dbhtml filename="symlinks.html"?>
  9. <title>Creating Custom Symlinks to Devices</title>
  10. <sect2>
  11. <title>CD-ROM symlinks</title>
  12. <para>Some software that you may want to install later (e.g., various
  13. media players) expect the /dev/cdrom and /dev/dvd symlinks to exist.
  14. Also, it may be convenient to put references to those symlinks into
  15. <filename>/etc/fstab</filename>. For each of your CD-ROM devices,
  16. find the corresponding directory under
  17. <filename class="directory">/sys</filename> (e.g., this can be
  18. <filename class="directory">/sys/block/hdd</filename>) and
  19. run a command similar to the following:</para>
  20. <screen role="nodump"><userinput>udevtest /block/hdd</userinput></screen>
  21. <para>Look at the lines containing the output of various *_id programs.</para>
  22. <para>There are two approaches to creating symlinks. The first one is to
  23. use the model name and the serial number, the second one is based on the
  24. location of the device on the bus. If you are going to use the first
  25. approach, create a file similar to the following:</para>
  26. <screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/70-persistent-cd.rules &lt;&lt; EOF
  27. <literal>
  28. # Custom CD-ROM symlinks
  29. SUBSYSTEM=="block", ENV{ID_MODEL}=="SAMSUNG_CD-ROM_SC-148F", \
  30. ENV{ID_REVISION}=="PS05", ENV{GENERATED}="1", SYMLINK+="cdrom"
  31. SUBSYSTEM=="block", ENV{ID_MODEL}=="PHILIPS_CDD5301", \
  32. ENV{ID_SERIAL}=="5VO1306DM00190", ENV{GENERATED}="1", SYMLINK+="cdrom1 dvd"
  33. </literal>
  34. EOF</userinput></screen>
  35. <note>
  36. <para>Be aware that Udev does not recognize the backslash for line
  37. continuation. The examples in this book work properly because both
  38. the backslash and newline are ignored by the shell. This makes the
  39. shell send each rule to cat on only one line. (The shell ignores
  40. this sequence because the EOF string used in the here-document
  41. redirection is not enclosed in either double or single quotes. For
  42. more details, see the bash(1) manpage, and search it for "Here
  43. Documents".)</para>
  44. <para>If modifying Udev rules with an editor, be sure to leave each
  45. rule on one physical line.</para>
  46. </note>
  47. <para>This way, the symlinks will stay correct even if you move the drives
  48. to different positions on the IDE bus, but the
  49. <filename>/dev/cdrom</filename> symlink won't be created if you replace
  50. the old SAMSUNG CD-ROM with a new drive.</para>
  51. <!-- The symlinks in the first approach survive even the transition
  52. to libata for IDE drives, but that is not for the book. -->
  53. <para>The SUBSYSTEM==&quot;block&quot; key is needed in order to avoid
  54. matching SCSI generic devices. Without it, in the case with SCSI
  55. CD-ROMs, the symlinks will sometimes point to the correct
  56. <filename>/dev/srX</filename> devices, and sometimes to
  57. <filename>/dev/sgX</filename>, which is wrong.</para>
  58. <para>The ENV{GENERATED}="1" key is needed to prevent the Udev
  59. 75-cd-aliases-generator.rules file from overriding your custom
  60. rules.</para>
  61. <para>The second approach yields:</para>
  62. <screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/70-persistent-cd.rules &lt;&lt; EOF
  63. <literal>
  64. # Custom CD-ROM symlinks
  65. SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", \
  66. ENV{ID_PATH}=="pci-0000:00:07.1-ide-0:1", \
  67. ENV{GENERATED}="1", SYMLINK+="cdrom"
  68. SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", \
  69. ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", \
  70. ENV{GENERATED}="1", SYMLINK+="cdrom1 dvd"
  71. </literal>
  72. EOF</userinput></screen>
  73. <para>This way, the symlinks will stay correct even if you replace drives
  74. with different models, but place them to the old positions on the IDE
  75. bus. The ENV{ID_TYPE}==&quot;cd&quot; key makes sure that the symlink
  76. disappears if you put something other than a CD-ROM in that position on
  77. the bus.</para>
  78. <para>Of course, it is possible to mix the two approaches.</para>
  79. </sect2>
  80. <sect2>
  81. <title>Dealing with duplicate devices</title>
  82. <para>As explained in <xref linkend="ch-scripts-udev"/>, the order in
  83. which devices with the same function appear in
  84. <filename class="directory">/dev</filename> is essentially random.
  85. E.g., if you have a USB web camera and a TV tuner, sometimes
  86. <filename>/dev/video0</filename> refers to the camera and
  87. <filename>/dev/video1</filename> refers to the tuner, and sometimes
  88. after a reboot the order changes to the opposite one.
  89. For all classes of hardware except sound cards and network cards, this is
  90. fixable by creating udev rules for custom persistent symlinks.
  91. The case of network cards is covered separately in
  92. <xref linkend="ch-scripts-network"/>, and sound card configuration can
  93. be found in <ulink url="&blfs-root;">BLFS</ulink>.</para>
  94. <para>For each of your devices that is likely to have this problem
  95. (even if the problem doesn't exist in your current Linux distribution),
  96. find the corresponding directory under
  97. <filename class="directory">/sys/class</filename> or
  98. <filename class="directory">/sys/block</filename>.
  99. For video devices, this may be
  100. <filename
  101. class="directory">/sys/class/video4linux/video<replaceable>X</replaceable></filename>.
  102. Figure out the attributes that identify the device uniquely (usually,
  103. vendor and product IDs and/or serial numbers work):</para>
  104. <screen role="nodump"><userinput>udevinfo -a -p /sys/class/video4linux/video0</userinput></screen>
  105. <para>Then write rules that create the symlinks, e.g.:</para>
  106. <screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/83-duplicate_devs.rules &lt;&lt; EOF
  107. <literal>
  108. # Persistent symlinks for webcam and tuner
  109. KERNEL=="video*", SYSFS{idProduct}=="1910", SYSFS{idVendor}=="0d81", \
  110. SYMLINK+="webcam"
  111. KERNEL=="video*", SYSFS{device}=="0x036f", SYSFS{vendor}=="0x109e", \
  112. SYMLINK+="tvtuner"
  113. </literal>
  114. EOF</userinput></screen>
  115. <para>The result is that <filename>/dev/video0</filename> and
  116. <filename>/dev/video1</filename> devices still refer randomly to the tuner
  117. and the web camera (and thus should never be used directly), but there are
  118. symlinks <filename>/dev/tvtuner</filename> and
  119. <filename>/dev/webcam</filename> that always point to the correct
  120. device.</para>
  121. <para>More information on writing Udev rules can be found in
  122. <filename>/usr/share/doc/udev-&udev-version;/index.html</filename>.</para>
  123. </sect2>
  124. </sect1>