source: chapter07/symlinks.xml@ 0a28f5f4

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 7.10 7.10-rc1 7.3 7.4 7.4-rc1 7.4-rc2 7.5 7.5-rc1 7.6 7.6-rc1 7.7 7.7-rc1 7.8 7.8-rc1 7.9 7.9-rc1 7.9-rc2 8.0 8.0-rc1 8.1 8.1-rc1 8.1-rc2 8.2 8.2-rc1 8.3 8.3-rc1 8.3-rc2 8.4 8.4-rc1 9.0 9.0-rc1 9.1 9.1-rc1 BOOK.old arm cross-chap5 hybrid ml-11.0 multilib nosym old-trunk test trunk xry111/clfs-ng xry111/git-transition xry111/glibc-2.34 xry111/lfs-next xry111/tester-nohack xry111/usr-move
Last change on this file since 0a28f5f4 was 0a28f5f4, checked in by Bruce Dubbs <bdubbs@…>, 9 years ago

Update file name for adjusting CD-ROM symlink
rules mode in section 7.5.1

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

  • Property mode set to 100644
File size: 7.6 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/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
13 <sect2>
14
15 <title>CD-ROM symlinks</title>
16
17 <para>Some software that you may want to install later (e.g., various
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
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
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
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>
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
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
66<screen role="nodump"><userinput>udevadm test /sys/block/hdd</userinput></screen>
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
73 <para>If the default mode is not suitable for your situation, then the
74 following modification can be made to the
75 <filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename> file,
76 as follows (where <replaceable>mode</replaceable> is one of
77 <quote>by-id</quote> or <quote>by-path</quote>):</para>
78
79<screen role="nodump"><userinput>sed -i -e 's/"write_cd_rules"/"write_cd_rules <replaceable>mode</replaceable>"/' \
80 /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput></screen>
81
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,
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>
87
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>
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;view/svn/postlfs/devices.html">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
127<screen role="nodump"><userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput></screen>
128
129 <para>Then write rules that create the symlinks, e.g.:</para>
130
131<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/83-duplicate_devs.rules &lt;&lt; "EOF"
132<literal>
133# Persistent symlinks for webcam and tuner
134KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
135 SYMLINK+="webcam"
136KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
137 SYMLINK+="tvtuner"
138</literal>
139EOF</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 </sect2>
149
150</sect1>
Note: See TracBrowser for help on using the repository browser.