Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
3) Linux-2.6.15 is used, which means that some deices (e.g., IDE
CD-ROMs and input devices) won't get modaliases or won't generate
uevents properly.
There is already a note in the book concerning how to handle devices
whose drivers don't work correctly under udev (i.e.
/etc/sysconfig/modules, etc.).
There are no words about what should and what should not be expected
to work. I will provide them later.
Rather than doing that, we could always just hold off on merging the
udev_update branch until linux-2.6.16 is released. Those trying out the
branch know (or should do!) that it might lead to breakage.
Then please delay the merge until linux-2.6.30 (or 2.6.40?). Even with
linux-2.6.16, udev won't load ISAPNP and ACPI modules, although the need
for them is detectable.
Issue with "more than one CD-ROM" also exists, but has no clear
upstream solution (they say: dynamically generate rules for
persistent CD-ROM naming, but provide no implementation).
>
OTOH, I would be happy with the following:
/dev/cdroms/SAMSUNG_CD-ROM_SC-148F
/dev/cdroms/PHILIPS_CDD5301_5VO1306DM00190
(these are results of running the ata_id program on my CD-ROMs).
Hmm, how does cdrom_id differ, if at all? That way we'd cope with both
SCSI and ATA CD-ROMS, right?
cdrom_id is different:
$ /sbin/cdrom_id /dev/hdb
ID_CDROM=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_RAM=1
$ /sbin/cdrom_id /dev/hdd
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_RAM=1
No serial number or any other descriptive key. This information is
useful with "import" keyword in udev rules, in order to differentiate
between CD-ROM and CD-RW drives.
Or even with HAL, that actually creates the mount points and fstab
entries for both my CD-ROMs.
Given that I know no good solution except manually-created rules or HAL,
and the current behaviour of the symlink pointing to some random CD-ROM,
even not the same CD-ROM after different reboots, I think that the
cdrom symlink rule should just be dropped.
11) The deprecated udev_run_hotplugd helper is needed for
compatibility with BLFS (look at HAL).
Why? I thought Kay was actively helping the HAL guys out? Why has
he caused it to break by deprecating the udev_run_hotplugd helper?
That's just obsolete BLFS setup. HAL is able to work without the
hotplug.d hook, but BLFS doesn't configure it to work this way.
Then it's a BLFS issue. Granted, before this branch was developed, they
couldn't be expected to know about the issue. Alexander, would you mind
getting a patch ready to apply to BLFS once the udev_update branch is
merged to trunk? Bruce, would you accept such a patch?
Quick and dirty solution, 100% equivalent to the old setup but I don't
know if this is optimal:
Remove the file that HAL installs under /etc/hotplug.d/default. Instead,
create this udev rule:
RUN+="/usr/lib/hal/hal.hotplug"
BTW this works even without udev_update (i.e., with linux-2.6.12.5 and
old udev).
13) The need for persistent device naming is not explained (Ticket
#1672)
Should it go under "device and module handling", under "configuring
the network script", or split between both? My preference is to split.
The split sounds best, though of course we can see what it looks like
and decide for definite then.
A draft of the patch is attached. It reworks the section about device
and module handling, and implements persistent names for network devices.
WARNING: the patch is incomplete. It assumes that SCSI module
autoloading rules are already added, but they are in fact not.
--
Alexander E. Patrakov
Index: chapter06/udev.xml
===================================================================
--- chapter06/udev.xml (revision 7394)
+++ chapter06/udev.xml (working copy)
@@ -111,6 +111,14 @@
RUN+="/sbin/modprobe sd_mod"
EOF</userinput></screen>
+ <para>Create some rules that work around broken sysfs attribute creation
+ timing in linux-2.6.15:</para>
+
+<screen><userinput>cat >> /etc/udev/rules.d/10-wait_for_sysfs.rules << "EOF"
+ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*", WAIT_FOR_SYSFS="bus"
+ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address"
+EOF</userinput></screen>
+
<para>Install the documentation that explains how to create Udev rules:</para>
<screen><userinput>install -m644 -D -v docs/writing_udev_rules/index.html /usr/share/doc/udev-&udev-version;/index.html</userinput></screen>
Index: chapter07/udev.xml
===================================================================
--- chapter07/udev.xml (revision 7394)
+++ chapter07/udev.xml (working copy)
@@ -86,7 +86,7 @@
class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
class="directory">/sys</filename>), data which the built-in drivers
registered with <systemitem class="filesystem">sysfs</systemitem> are
- available to userspace processes and to <command>udev</command> for device
+ available to userspace processes and to <command>udevd</command> for device
node creation.</para>
</sect3>
@@ -97,11 +97,12 @@
device nodes when Linux is booted. The script starts by unsetting the
hotplug event handler from the default of <command>/sbin/hotplug</command>
This is done because, instead of the kernel calling out to an external
- binary, <command>udev</command> will listen on a netlink socket for
+ binary, <command>udevd</command> will listen on a netlink socket for
hotplug events that the kernel raises. The bootscript copies any static
device nodes that exist in <filename
class="directory">/lib/udev/devices</filename> to <filename
- class="directory">/dev</filename>. This is necessary because some devices
+ class="directory">/dev</filename>. This is necessary because some devices,
+ directories and symlinks
are needed before the dynamic device handling processes are available
during the early stages of booting a system. Creating static device nodes
in <filename class="directory">/lib/udev/devices</filename> also provides
@@ -132,16 +133,40 @@
it will default permissions to <emphasis>660</emphasis> and ownership to
<emphasis>root:root</emphasis>. Documentation on the syntax of the Udev
rules configuration files are available in
- <filename>/usr/share/doc/udev-084/index.html</filename></para>
+ <filename>/usr/share/doc/udev-&udev-version;/index.html</filename></para>
</sect3>
<sect3>
<title>Module Loading</title>
- <para>If a device driver has been compiled as a module, the rules that
- LFS installs will cause <command>udevd</command> to call out to
- <command>/sbin/modprobe</command> with the name of the corresponding
- module, thereby loading the driver.</para>
+ <para>Device drivers compiled as modules may have aliases built into them.
+ Aliases are visible in the output of the <command>modinfo</command>
+ program and are usually related to the bus-specific identifiers of
+ devices supported by a module. E.g., the <emphasis>snd-fm801</emphasis>
+ driver supports
+ PCI devices with vendor ID 0x1319 and device ID 0x0801, and has
+ the <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote> alias.
+ For most devices, the bus driver exports via <systemitem
+ class="filesystem">sysfs</systemitem> the alias of the driver
+ that would handle this device. E.g., the
+ <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
+ might contain the string
+ <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
+ The rules that LFS installs will cause <command>udevd</command> to call
+ out to <command>/sbin/modprobe</command> with the contents of the
+ <envar>MODALIAS</envar> uevent environment variable (that should be the
+ same as the contents of the <filename>modalias</filename> file in sysfs),
+ thus loading all modules whose aliases match this string after wildcard
+ expansion.</para>
+
+ <para>In this example, this means that, in addition to
+ <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
+ <emphasis>forte</emphasis> driver will be loaded if it is
+ available. See below the ways to prevent loading of unwanted
+ drivers.</para>
+
+ <para>The kernel itself is also able to load modules for network protocols,
+ filesystems and NLS support on demand.</para>
</sect3>
<sect3>
@@ -162,68 +187,162 @@
<para>7.4.2.3: Are default ownership/permissions still 0660 root:root? I
thought they'd changed, but can't be sure. Running without a config file
will prove this pretty quickly.</para>
+ <para>Answer: Yes</para>
<para>7.4.2.4: How does <command>udevd</command> know which driver to
load, i.e. the correct module name? Is it in the hotplug event? I don't
think it can be in /sys as that won't be populated yet (it's the driver
itself that populates /sys, after all).</para>
+ <para>Answer: The bus driver populates /sys, and then udev loads the
+ device driver.</para>
<para>Is the S05modules script still required? If so, what are the use
cases for it?</para>
+ <para>Answer: Yes, for undetectable modules such as loop, nbd,
+ ppp_generic, and for ISA devices.</para>
</sect3> -->
</sect2>
<sect2>
- <title>Problems with Creating Devices</title>
+ <title>Problems with Loading Modules and Creating Devices</title>
- <para>There are a few known problems when it comes to automatically creating
- device nodes:</para>
+ <para>There are a few possible problems when it comes to automatically creating
+ device nodes.</para>
- <para>1) A kernel driver might not export its data to <systemitem
- class="filesystem">sysfs</systemitem>.</para>
+ <sect3>
+ <title>A kernel module is not loaded automatically</title>
+ <para>Udev loads only modules that have bus-specific aliases, and only if
+ the bus driver properly exports the wanted aliases to <systemitem
+ class="filesystem">sysfs</systemitem>. In other cases, one should
+ arrange module loading by other means. With linux-2.6.15, Udev is known
+ to load properly-written drivers
+ for PCI, USB, SCSI, SERIO and FireWire devices.
+ </para>
+<!-- After linux-2.6.16, add INPUT and IDE to the list above -->
- <para>This is most common with third party drivers from outside the kernel
- tree. Udev will be unable to automatically create device nodes for such
- drivers. Create a static device node in
- <filename>/lib/udev/devices</filename> with the appropriate major/minor
- numbers (see the file <filename>devices.txt</filename> inside the kernel
- documentation or the documentation provided by the third party driver
- vendor). The static device node will be copied to
- <filename class="directory">/dev</filename> by the
- <command>S10udev</command> bootscript.</para>
+ <para>Run <command>modinfo</command>
+ with the module name as the argument. Then try locating the device directory
+ under <filename class="directory">/sys/bus</filename> and checking
+ whether there is a <filename>modalias</filename> file there.</para>
+
+ <para>If it exists,
+ and its contents matches the module alias, but the module is still not
+ loaded, it is a kernel bug: the kernel
+ forgets to export the alias to the uevent environment. This is the case,
+ e.g., with the input subsystem in linux-2.6.15-gregkh, and should be fixed
+ in later kernel versions.</para>
+
+ <para>Otherwise, udev is not supposed to load this
+ module with this kernel version.</para>
- <para>2) A non-hardware device is required. This is most common with
- the Advanced Linux Sound Architecture (ALSA) project's Open Sound
- System (OSS) compatibility module. These types of devices can be
- handled in one of two ways:</para>
+<!-- Remove IDE from the list below after linux-2.6.16 -->
+ <para>If there is no <filename>modalias</filename> file in the relevant
+ directory under <filename class="directory">/sys/bus</filename>, this means
+ that the kernel developers have not yet added modalias support to this
+ bus type. With linux-2.6.15, this is the case with ISA and IDE busses.
+ Expect this issue to be fixed in later kernel versions.</para>
+
+ <para>If the <filename>modalias</filename> file exists in <systemitem
+ class="filesystem">sysfs</systemitem>, the driver supports the device and
+ can talk to it directly, but doesn't have the alias, it is a bug in the
+ driver. Load the driver without the help from udev and expect the issue
+ to be fixed later.</para>
- <itemizedlist>
+ <para>Udev is not supposed to load <quote>wrapper</quote> drivers such as
+ <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
+ <emphasis>loop</emphasis> at all.</para>
+ </sect3>
- <listitem>
- <para>Adding the module names to
- <filename>/etc/sysconfig/modules</filename></para>
- </listitem>
+ <sect3>
+ <title>A kernel module is not loaded automatically,
+ and udev is not supposed to load it</title>
- <listitem>
- <para>Using an <quote>install</quote> line in
- <filename>/etc/modprobe.conf</filename>. This tells the
- <command>modprobe</command> command <quote>when loading this module,
- also load this other module, at the same time.</quote>
- For example:</para>
+ <para>If this <quote>wrapper</quote> module only enhances the functionality
+ provided by some
+ other module (e.g., <emphasis>snd-pcm-oss</emphasis> enhances the
+ functionality of <emphasis>snd-pcm</emphasis> by making the sound cards
+ available to OSS applications), configure <command>modprobe</command>
+ to load the wrapper after udev loads the wrapped module. To do this,
+ an <quote>install</quote> line in <filename>/etc/modprobe.conf</filename>.
+ For example:</para>
+<screen role="nodump">install snd-pcm modprobe -i snd-pcm ; modprobe \
+ snd-pcm-oss ; true</screen>
+
+ <para>If the module in question is not a wrapper and is useful by itself,
+ configure the <command>S05modules</command> bootscript to load this
+ module on system boot. To do this, add the module name to the
+ <filename>/etc/sysconfig/modules</filename> file on a separate line.
+ This works for wrapper modules too, but is suboptimal in that case.</para>
+ </sect3>
-<screen role="nodump"><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \
- snd-pcm-oss ; true</userinput></screen>
+ <sect3>
+ <title>Udev loads some unwanted module</title>
- <para>This will cause the system to load both the
- <emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis>
- modules when any request is made to load the driver
- <emphasis>snd-pcm</emphasis>.</para>
- </listitem>
+ <para>Either don't build the module, or blacklist it in
+ <filename>/etc/modprobe.conf</filename> file as done with the
+ <emphasis>forte</emphasis> module in the example below:</para>
+<screen role="nodump">blacklist forte</screen>
- </itemizedlist>
+ <para>Blacklisted modules can still be loaded manually with the
+ explicit <command>modprobe</command> command.</para>
+ </sect3>
+ <sect3>
+ <title>Udev creates a device incorrectly, or makes a wrong symlink</title>
+
+ <para>This usually happens if an incorrect rule unexpectedly matches
+ the device, or some rule unexpectedly matches the wrong device. E.g.,
+ a poorly-writen rule can match by vendor both a SCSI disk (as desired)
+ and the corresponding SCSI generic device (incorrectly). Increase
+ the logging verbosity of udev, find the offending rule by examining the
+ logs and make it more specific.</para>
+ </sect3>
+
+ <sect3>
+ <title>Udev rule works unreliably</title>
+ <para>This may be another manifestation of the previous problem. If not,
+ and your rule uses <systemitem class="filesystem">sysfs</systemitem>
+ attributes, it may be a kernel timing issue,
+ to be fixed in later kernels. For now, you can work around it by creating
+ a rule that waits for the used <systemitem
+ class="filesystem">sysfs</systemitem> attribute and appending it to the
+ <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename> file.
+ Please notify the LFS Development list if you do so and it helps.</para>
+ </sect3>
+
+ <sect3>
+ <title>Udev does not create a device</title>
+ <para>Further text assumes that the driver is built statically into the
+ kernel or already loaded as a module, and that you have already checked
+ that udev doesn't create a misnamed device.</para>
+
+ <para>Udev has no information needed to create a device node if a kernel
+ driver does not export its data to <systemitem
+ class="filesystem">sysfs</systemitem>.
+ This is most common with third party drivers from outside the kernel
+ tree. Create a static device node in
+ <filename>/lib/udev/devices</filename> with the appropriate major/minor
+ numbers (see the file <filename>devices.txt</filename> inside the kernel
+ documentation or the documentation provided by the third party driver
+ vendor). The static device node will be copied to
+ <filename class="directory">/dev</filename> by the
+ <command>S10udev</command> bootscript.</para>
+ </sect3>
+
+ <sect3>
+ <title>Devide naming order changes randomly after rebooting</title>
+ <para>This is due to the fact that Udev, by design, handles uevents and
+ loads modules in parallel, and thus in unpredictable order. This will
+ never be <quote>fixed</quote>. You should
+ not rely upon the kernel device names being stable. Instead, create
+ your own rules that make symlinks with stable names based on some
+ stable attributes of the device, such as a serial number or the output
+ of various *_id utilities installed by Udev. See also the network
+ interface renaming example in <xref linkend="ch-scripts-network"/>.</para>
+ </sect3>
+
</sect2>
<sect2>
Index: chapter07/network.xml
===================================================================
--- chapter07/network.xml (revision 7394)
+++ chapter07/network.xml (working copy)
@@ -24,6 +24,42 @@
class="directory">/etc/rc.d/rc*.d</filename>).</para>
<sect2>
+ <title>Creating stable names for network interfaces</title>
+ <para>Instructions in this section are optional if you have only one
+ network card.</para>
+
+ <para>With Udev and modular network drivers, the network interface
+ numbering is not persistent across reboots by default, because the
+ drivers are loaded in parallel and, thus, in random order.
+ E.g., in some cases,
+ on a computer having two network cards made by Intel and Realtek,
+ the network card manufactured by Intel becomes eth0 and the Realtek
+ card becomes eth1, and in some cases after a reboot the cards get
+ renumbered the other way
+ round. In order to avoid this, create udev rules that assign stable
+ names to network cards based on their MAC addresses.</para>
+
+ <para>First, find out the MAC addresses of your network cards:</para>
+<screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen>
+ <para>For each network card (but not for the loopback interface),
+ invent a descriptive name, such as <quote>realtek</quote>, and create
+ udev rules similar to the following:</para>
+
+<screen><userinput>
+cat > /etc/udev/rules.d/26-network.rules << "EOF"
+ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="52:54:00:12:34:56", NAME="realtek"
+ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="intel"
+EOF</userinput></screen>
+ <para>This rule will always rename the network cards
+ to <quote>realtek</quote> and <quote>intel</quote>, independently of the
+ original numbering provided by the kernel.
+ Use these names instead of <quote>eth0</quote> in the network interface
+ configuration files created below.</para>
+
+ <note><para>Persistent names must be different from the default network
+ interface names assigned by the kernel.</para></note>
+ </sect2>
+ <sect2>
<title>Creating Network Interface Configuration Files</title>
<para>Which interfaces are brought up and down by the network script
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
