Changeset 37153e0
- Timestamp:
- 03/07/2006 08:25:40 PM (18 years ago)
- Children:
- 2536b38
- Parents:
- 98c3af0
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter01/changelog.xml
r98c3af0 r37153e0 40 40 <para>March 7, 2006</para> 41 41 <itemizedlist> 42 <listitem> 43 <para>[matthew] - Update Udev rules file to load SCSI modules and 44 upload firmware to devices that need it. Improve explanations of 45 device and module handling. Thanks to Alexander Patrakov.</para> 46 </listitem> 42 47 <listitem> 43 48 <para>[archaic] - Replaced the debian-specific groff patch with an -
chapter06/udev.xml
r98c3af0 r37153e0 100 100 <screen><userinput>cp -v ../&udev-config-file; /etc/udev/rules.d/25-lfs.rules</userinput></screen> 101 101 102 <para>Alter Udev's configuration file so that Udev can automatically 103 load kernel modules.</para> 104 105 <screen><userinput>sed -i 147,150d /etc/udev/rules.d/25-lfs.rules 106 cat >> /etc/udev/rules.d/25-lfs.rules << "EOF" 107 # Rules to allow hotplugging of devices with modular drivers 108 ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", \ 109 RUN+="/sbin/modprobe $env{MODALIAS}" 110 ACTION=="add", SUBSYSTEM=="scsi", SYSFS{type}=="[07]", \ 111 RUN+="/sbin/modprobe sd_mod" 102 <para>Create some rules that work around broken sysfs attribute creation 103 timing in linux-2.6.15:</para> 104 105 <screen><userinput>cat >> /etc/udev/rules.d/10-wait_for_sysfs.rules << "EOF" 106 ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*", WAIT_FOR_SYSFS="bus" 107 ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address" 112 108 EOF</userinput></screen> 113 109 -
chapter07/network.xml
r98c3af0 r37153e0 24 24 class="directory">/etc/rc.d/rc*.d</filename>).</para> 25 25 26 <sect2> 27 <title>Creating stable names for network interfaces</title> 28 <para>Instructions in this section are optional if you have only one 29 network card.</para> 30 31 <para>With Udev and modular network drivers, the network interface 32 numbering is not persistent across reboots by default, because the 33 drivers are loaded in parallel and, thus, in random order. 34 For example, on a computer having two network cards made by Intel and 35 Realtek, the network card manufactured by Intel may become eth0 and the 36 Realtek card becomes eth1. In some cases, after a reboot the cards get 37 renumbered the other way around. To avoid this, create Udev rules that 38 assign stable names to network cards based on their MAC addresses.</para> 39 40 <para>First, find out the MAC addresses of your network cards:</para> 41 <screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen> 42 <para>For each network card (but not for the loopback interface), 43 invent a descriptive name, such as <quote>realtek</quote>, and create 44 Udev rules similar to the following:</para> 45 46 <screen role="nodump"><userinput> 47 cat > /etc/udev/rules.d/26-network.rules << "EOF" 48 ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>52:54:00:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>" 49 ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>" 50 EOF</userinput></screen> 51 52 <para>These rules will always rename the network cards to 53 <quote>realtek</quote> and <quote>intel</quote>, independently of the 54 original numbering provided by the kernel. Use these names instead of 55 <quote>eth0</quote> in the network interface configuration files created 56 below.</para> 57 58 <note><para>Persistent names must be different from the default network 59 interface names assigned by the kernel.</para></note> 60 </sect2> 26 61 <sect2> 27 62 <title>Creating Network Interface Configuration Files</title> -
chapter07/udev.xml
r98c3af0 r37153e0 87 87 class="directory">/sys</filename>), data which the built-in drivers 88 88 registered with <systemitem class="filesystem">sysfs</systemitem> are 89 available to userspace processes and to <command>udev </command> for device89 available to userspace processes and to <command>udevd</command> for device 90 90 node creation.</para> 91 91 </sect3> … … 98 98 hotplug event handler from the default of <command>/sbin/hotplug</command> 99 99 This is done because, instead of the kernel calling out to an external 100 binary, <command>udev </command> will listen on a netlink socket for100 binary, <command>udevd</command> will listen on a netlink socket for 101 101 hotplug events that the kernel raises. The bootscript copies any static 102 102 device nodes that exist in <filename 103 103 class="directory">/lib/udev/devices</filename> to <filename 104 class="directory">/dev</filename>. This is necessary because some devices 105 are needed before the dynamic device handling processes are available 106 during the early stages of booting a system. Creating static device nodes 107 in <filename class="directory">/lib/udev/devices</filename> also provides 104 class="directory">/dev</filename>. This is necessary because some devices, 105 directories and symlinks are needed before the dynamic device handling 106 processes are available during the early stages of booting a system. 107 Creating static device nodes in 108 <filename class="directory">/lib/udev/devices</filename> also provides 108 109 an easy workaround for devices that are not supported by the dynamic 109 110 device handling infrastructure. The bootscript then starts the Udev … … 139 140 <title>Module Loading</title> 140 141 141 <para>If a device driver has been compiled as a module, the rules that 142 LFS installs will cause <command>udevd</command> to call out to 143 <command>/sbin/modprobe</command> with the name of the corresponding 144 module, thereby loading the driver.</para> 142 <para>Device drivers compiled as modules may have aliases built into them. 143 Aliases are visible in the output of the <command>modinfo</command> 144 program and are usually related to the bus-specific identifiers of devices 145 supported by a module. For example, the <emphasis>snd-fm801</emphasis> 146 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, 147 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>. 148 For most devices, the bus driver exports the alias of the driver that 149 would handle the device via <systemitem 150 class="filesystem">sysfs</systemitem>. E.g., the 151 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file 152 might contain the string 153 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>. 154 The rules that LFS installs will cause <command>udevd</command> to call 155 out to <command>/sbin/modprobe</command> with the contents of the 156 <envar>MODALIAS</envar> uevent environment variable (that should be the 157 same as the contents of the <filename>modalias</filename> file in sysfs), 158 thus loading all modules whose aliases match this string after wildcard 159 expansion.</para> 160 161 <para>In this example, this means that, in addition to 162 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted) 163 <emphasis>forte</emphasis> driver will be loaded if it is 164 available. See below for ways in which the loading of unwanted drivers can 165 be prevented.</para> 166 167 <para>The kernel itself is also able to load modules for network 168 protocols, filesystems and NLS support on demand.</para> 145 169 </sect3> 146 170 … … 154 178 </sect3> 155 179 156 <!-- FIXME: These are questions Matt thought of while rewriting this page157 to reflect the hotplug-less setup but didn't have time to investigate158 straight away.159 <sect3>160 <title>Questions?</title>161 162 <para>7.4.2.3: Are default ownership/permissions still 0660 root:root? I163 thought they'd changed, but can't be sure. Running without a config file164 will prove this pretty quickly.</para>165 166 <para>7.4.2.4: How does <command>udevd</command> know which driver to167 load, i.e. the correct module name? Is it in the hotplug event? I don't168 think it can be in /sys as that won't be populated yet (it's the driver169 itself that populates /sys, after all).</para>170 171 <para>Is the S05modules script still required? If so, what are the use172 cases for it?</para>173 174 </sect3> -->175 176 180 </sect2> 177 181 178 182 <sect2> 179 <title>Problems with Creating Devices</title> 180 181 <para>There are a few known problems when it comes to automatically creating 182 device nodes:</para> 183 184 <para>1) A kernel driver might not export its data to <systemitem 185 class="filesystem">sysfs</systemitem>.</para> 186 187 <para>This is most common with third party drivers from outside the kernel 188 tree. Udev will be unable to automatically create device nodes for such 189 drivers. Create a static device node in 190 <filename>/lib/udev/devices</filename> with the appropriate major/minor 191 numbers (see the file <filename>devices.txt</filename> inside the kernel 192 documentation or the documentation provided by the third party driver 193 vendor). The static device node will be copied to 194 <filename class="directory">/dev</filename> by the 195 <command>S10udev</command> bootscript.</para> 196 197 <para>2) A non-hardware device is required. This is most common with 198 the Advanced Linux Sound Architecture (ALSA) project's Open Sound 199 System (OSS) compatibility module. These types of devices can be 200 handled in one of two ways:</para> 201 202 <itemizedlist> 203 204 <listitem> 205 <para>Adding the module names to 206 <filename>/etc/sysconfig/modules</filename></para> 207 </listitem> 208 209 <listitem> 210 <para>Using an <quote>install</quote> line in 211 <filename>/etc/modprobe.conf</filename>. This tells the 212 <command>modprobe</command> command <quote>when loading this module, 213 also load this other module, at the same time.</quote> 214 For example:</para> 215 216 <screen role="nodump"><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \ 217 snd-pcm-oss ; true</userinput></screen> 218 219 <para>This will cause the system to load both the 220 <emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis> 221 modules when any request is made to load the driver 222 <emphasis>snd-pcm</emphasis>.</para> 223 </listitem> 224 225 </itemizedlist> 226 183 <title>Problems with Loading Modules and Creating Devices</title> 184 185 <para>There are a few possible problems when it comes to automatically 186 creating device nodes.</para> 187 188 <sect3> 189 <title>A kernel module is not loaded automatically</title> 190 <para>Udev will only load a module if it has a bus-specific alias and the 191 bus driver properly exports the necessary aliases to <systemitem 192 class="filesystem">sysfs</systemitem>. In other cases, one should 193 arrange module loading by other means. With Linux-&linux-version;, Udev is 194 known to load properly-written drivers for PCI, USB, SCSI, SERIO and 195 FireWire devices.</para> 196 197 <!-- After linux-2.6.16, add INPUT and IDE to the list above --> 198 199 <para>To determine if the device driver you require has the necessary 200 support for Udev, run <command>modinfo</command> with the module name as 201 the argument. Now try locating the device directory under 202 <filename class="directory">/sys/bus</filename> and check whether there is 203 a <filename>modalias</filename> file there.</para> 204 205 <para>If the <filename>modalias</filename> file exists, and its contents 206 match the module alias, but the module is still not loaded, it is a kernel 207 bug - the kernel forgets to export the alias to the uevent environment. 208 This is the case, for example, with the input subsystem in 209 Linux-&linux-version;, and is anticipated to be fixed in later kernel 210 versions. As a workaround...</para> 211 212 <!-- After Linux-2.6.16, find a different example for the para above --> 213 214 <para>If the <filename>modalias</filename> file exists in <systemitem 215 class="filesystem">sysfs</systemitem>, the driver supports the device and 216 can talk to it directly, but doesn't have the alias, it is a bug in the 217 driver. Load the driver without the help from Udev and expect the issue 218 to be fixed later.</para> 219 220 <para>If there is no <filename>modalias</filename> file in the relevant 221 directory under <filename class="directory">/sys/bus</filename>, this 222 means that the kernel developers have not yet added modalias support to 223 this bus type. With Linux-&linux-version;, this is the case with ISA and 224 IDE busses. Expect this issue to be fixed in later kernel versions.</para> 225 226 <!-- Remove IDE from the list above after Linux-2.6.16 --> 227 228 <para>Udev is not intended to load <quote>wrapper</quote> drivers such as 229 <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as 230 <emphasis>loop</emphasis> at all.</para> 231 </sect3> 232 233 <sect3> 234 <title>A kernel module is not loaded automatically, and Udev is not 235 intended to load it</title> 236 237 <para>If the <quote>wrapper</quote> module only enhances the functionality 238 provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis> 239 enhances the functionality of <emphasis>snd-pcm</emphasis> by making the 240 sound cards available to OSS applications), configure 241 <command>modprobe</command> to load the wrapper after Udev loads the 242 wrapped module. To do this, add an <quote>install</quote> line in 243 <filename>/etc/modprobe.conf</filename>. For example:</para> 244 <screen role="nodump">install snd-pcm modprobe -i snd-pcm ; modprobe \ 245 snd-pcm-oss ; true</screen> 246 247 <para>If the module in question is not a wrapper and is useful by itself, 248 configure the <command>S05modules</command> bootscript to load this 249 module on system boot. To do this, add the module name to the 250 <filename>/etc/sysconfig/modules</filename> file on a separate line. 251 This works for wrapper modules too, but is suboptimal in that case.</para> 252 </sect3> 253 254 <sect3> 255 <title>Udev loads some unwanted module</title> 256 257 <para>Either don't build the module, or blacklist it in 258 <filename>/etc/modprobe.conf</filename> file as done with the 259 <emphasis>forte</emphasis> module in the example below:</para> 260 <screen role="nodump">blacklist forte</screen> 261 262 <para>Blacklisted modules can still be loaded manually with the 263 explicit <command>modprobe</command> command.</para> 264 </sect3> 265 266 <sect3> 267 <title>Udev creates a device incorrectly, or makes a wrong symlink</title> 268 269 <para>This usually happens if a rule unexpectedly matches a device. For 270 example, a poorly-writen rule can match by both a SCSI disk (as desired) 271 and the corresponding SCSI generic device (incorrectly) by vendor. 272 Increase the logging verbosity of Udev, find the offending rule by 273 examining the logs and make it more specific.</para> 274 </sect3> 275 276 <sect3> 277 <title>Udev rule works unreliably</title> 278 <para>This may be another manifestation of the previous problem. If not, 279 and your rule uses <systemitem class="filesystem">sysfs</systemitem> 280 attributes, it may be a kernel timing issue, to be fixed in later kernels. 281 For now, you can work around it by creating a rule that waits for the used 282 <systemitem class="filesystem">sysfs</systemitem> attribute and appending 283 it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename> 284 file. Please notify the LFS Development list if you do so and it helps. 285 </para> 286 </sect3> 287 288 <sect3> 289 <title>Udev does not create a device</title> 290 <para>Further text assumes that the driver is built statically into the 291 kernel or already loaded as a module, and that you have already checked 292 that Udev doesn't create a misnamed device.</para> 293 294 <para>Udev has no information needed to create a device node if a kernel 295 driver does not export its data to <systemitem 296 class="filesystem">sysfs</systemitem>. 297 This is most common with third party drivers from outside the kernel 298 tree. Create a static device node in 299 <filename>/lib/udev/devices</filename> with the appropriate major/minor 300 numbers (see the file <filename>devices.txt</filename> inside the kernel 301 documentation or the documentation provided by the third party driver 302 vendor). The static device node will be copied to 303 <filename class="directory">/dev</filename> by the 304 <command>S10udev</command> bootscript.</para> 305 </sect3> 306 307 <sect3> 308 <title>Device naming order changes randomly after rebooting</title> 309 <para>This is due to the fact that Udev, by design, handles uevents and 310 loads modules in parallel, and thus in an unpredictable order. This will 311 never be <quote>fixed</quote>. You should not rely upon the kernel device 312 names being stable. Instead, create your own rules that make symlinks with 313 stable names based on some stable attributes of the device, such as a 314 serial number or the output of various *_id utilities installed by Udev. 315 See also the network interface renaming example in 316 <xref linkend="ch-scripts-network"/>.</para> 317 </sect3> 318 227 319 </sect2> 228 320 -
general.ent
r98c3af0 r37153e0 83 83 <!ENTITY texinfo-version "4.8"> 84 84 <!ENTITY udev-version "085"> 85 <!ENTITY udev-config-file "udev-config- 5.rules">85 <!ENTITY udev-config-file "udev-config-6.rules"> 86 86 <!ENTITY util-linux-version "2.12r"> 87 87 <!ENTITY vim-version "6.4">
Note:
See TracChangeset
for help on using the changeset viewer.