gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-18 19:29:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merged the udev_update branch to trunk.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7509 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Archaic 2006-04-13 18:45:33 +00:00
parent dd7ed7b42f
commit d2c332bc21
24 changed files with 892 additions and 680 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

179
chapter01/changelog.xml
View File

@ -36,6 +36,15 @@
</listitem>
-->
<listitem>
<para>April 13, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Merged the udev_update branch to trunk.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>April 12, 2006</para>
<itemizedlist>
@ -43,9 +52,6 @@
<para>[jhuntwork] - Rewrote section explaining IP Addresses.
Thanks Bryan Kadzban and Bruce Dubbs. Resolves Ticket 1663.</para>
</listitem>
<listitem>
<para>[jhuntwork] - Adjust some redundant text in Berkeley DB page.</para>
</listitem>
<listitem>
<para>[jhuntwork] - Added a pointer to GDBM in Berkeley DB page.
Also added explanatory text concerning why LFS chose Debian's
@ -69,6 +75,19 @@
</itemizedlist>
</listitem>
<listitem>
<para>April 8, 2006</para>
<itemizedlist>
<listitem>
<para>[jhuntwork] - Added a command to create an empty /etc/mtab file early
in chapter 6. This avoids testsuite failures in e2fsprogs and possibly other
programs that expect /etc/mtab to be present. Explanation from Dan Nicholson,
slightly modified. Also merged the 'Creating Essential Symlinks' section with
'Creating passwd, group and log Files'.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>April 6, 2006</para>
<itemizedlist>
@ -82,12 +101,31 @@
</itemizedlist>
</listitem>
<listitem>
<para>April 2, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Moved the chowning of /tools to the end of chapter 5
and rewrote note about backing up or re-using /tools. Moved the
mounting of kernel filesystems before pkgmgt page and rewrote the page
to mount --bind /dev and mount all other kernel filesystems while
outside chroot. Rewrote note about re-entering chroot and remounting
kernel filesystems. Removed /dev from the list of dirs created in
chroot and added it before chroot.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>March 30, 2006</para>
<itemizedlist>
<listitem>
<para>[ken] - Correct my erroneous comment about UTF-8 locales in
Man-DB. Thanks to Alexander for explaining it.</para>
Man-DB. Thanks to Alexander for explaining it.</para>
</listitem>
<listitem>
<para>[ken] - upgraded to Linux-2.6.16.1, Iproute2-2.6.16-060323,
and Udev-088.</para>
</listitem>
</itemizedlist>
</listitem>
@ -97,20 +135,33 @@
<itemizedlist>
<listitem>
<para>[ken] - Upgrade to shadow-4.0.15 and add convert-mans script
to convert its UTF-8 man pages. Thanks to Alexander and Archaic for
the script and commands. Fixes tickets #1748 and #1750.</para>
to convert its UTF-8 man pages. Thanks to Alexander and Archaic for
the script and commands. Fixes tickets #1748 and #1750.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>March 22, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Updated to lfs-bootscripts-20060321.</para>
</listitem>
</itemizedlist>
</listitem>
<para>March 22, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Updated to
lfs-bootscripts-udev_update-20060321.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>March 21, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Updated the bootscripts. Removed references to
hotplug and the bootscripts udev patch. Removed reference to
udevstart. Added text and commands for generating Udev bug reports.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>March 18, 2006</para>
@ -163,12 +214,32 @@
<listitem>
<para>[matthew] - Upgrade to Man-pages 2.25.</para>
</listitem>
<listitem>
<para>[matthew] - Remove an example of poor Udev support as it
does not apply to the kernel used in the book. Thanks to Alexander
Patrakov.</para>
</listitem>
<listitem>
<para>[matthew] - Upgrade to Linux 2.6.15.6.</para>
</listitem>
<listitem>
<para>[matthew] - Upgrade to udev-087.</para>
</listitem>
<listitem>
<para>[matthew] - Udev's run_program rules require a null device to be
present at an early stage, so create one in /lib/udev/devices.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>March 7, 2006</para>
<itemizedlist>
<listitem>
<para>[matthew] - Update Udev rules file to load SCSI modules and
upload firmware to devices that need it. Improve explanations of
device and module handling. Thanks to Alexander Patrakov.</para>
</listitem>
<listitem>
<para>[archaic] - Replaced the debian-specific groff patch with an
LFS-style patch.</para>
@ -189,6 +260,10 @@
<listitem>
<para>March 1, 2006</para>
<itemizedlist>
<listitem>
<para>[archaic] - Create the Udev directories before creating the
symlinks.</para>
</listitem>
<listitem>
<para>[jhuntwork] - Added a description of perl configure flags that
help perl deal with a lack of groff. Thanks Dan Nicholson.</para>
@ -209,6 +284,11 @@
<listitem>
<para>February 20, 2006</para>
<itemizedlist>
<listitem>
<para>[matthew] - Use non-deprecated format for accessing MODALIAS
keys in the Udev rules file, and prevent the &quot;$&quot; from being
expanded by the shell.</para>
</listitem>
<listitem>
<para>[matthew] - Add patches 009 and 010 from Bash upstream.</para>
</listitem>
@ -225,6 +305,16 @@
<para>[matthew] - Upgrade Perl libc patch to prevent Perl from trying
to find headers on the host system. Fixes bug 1695.</para>
</listitem>
<listitem>
<para>[matthew] - Expand the Udev module handling rule to run for
every subsystem, not just USB.</para>
</listitem>
<listitem>
<para>[matthew] - Upgrade to Linux 2.6.15.4.</para>
</listitem>
<listitem>
<para>[matthew] - Upgrade to Udev 085.</para>
</listitem>
<listitem>
<para>[matthew] - Install Sed's HTML documentation by using
--enable-html instead of editing the Makefile. Thanks to Greg Schafer
@ -256,6 +346,13 @@
<para>[matthew] - Add the verbose parameter to a couple of commands in
Linux-Libc-Headers and DB.</para>
</listitem>
<listitem>
<para>[matthew] - Create udev specific directories in udev's
instructions instead of the more generic creatingdirs.xml. Add
&quot;pts&quot; and &quot;shm&quot; directories to
<filename class="directory">/lib/udev/devices</filename> so that they
can be mounted successfully at boot time.</para>
</listitem>
</itemizedlist>
</listitem>
@ -269,6 +366,62 @@
</itemizedlist>
</listitem>
<listitem>
<para>February 8, 2006</para>
<itemizedlist>
<listitem>
<para>[matthew] - Rewrite the majority of chapter07/udev.xml to
reflect the new configuration for handling dynamic device naming and
module loading.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>February 3, 2006</para>
<itemizedlist>
<listitem>
<para>[matthew] - Create the
<filename class="directory">/lib/firmware</filename> directory that
can be used by Udev's <command>firmware_helper</command> utility.
</para>
</listitem>
<listitem>
<para>[matthew] - Add descriptions of Udev's helper binaries.</para>
</listitem>
<listitem>
<para>[manuel] - Add udev bootscript patch to whatsnew. Removed
hotplug from list of packages to download.</para>
</listitem>
<listitem>
<para>[ken] - Add udev bootscript patch to list of patches to
download.</para>
</listitem>
<listitem>
<para>[ken] - Correct the size of the udev tarball.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>February 2, 2006</para>
<itemizedlist>
<listitem>
<para>[matthew] - Upgrade to Udev-084 and build all its extras to
enable custom rules to be written more easily. Also, change the
rules file to handle kernel module loading and patch the udev
bootscript to work with this version of udev.</para>
</listitem>
<listitem>
<para>[matthew] - Remove the hotplug package and related bootscript
Udev will now handle device creation and module loading.</para>
</listitem>
<listitem>
<para>[matthew] - Upgrade to Linux-2.6.15.2.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>January 30, 2006</para>
<itemizedlist>

10
chapter01/whatsnew.xml
View File

@ -91,18 +91,15 @@
<!--<listitem>
<para>Gzip &gzip-version;</para>
</listitem>-->
<!--<listitem>
<para>Hotplug &hotplug-version;</para>
</listitem>-->
<listitem>
<para>IANA-Etc &iana-etc-version;</para>
</listitem>
<!--<listitem>
<para>Inetutils &inetutils-version;</para>
</listitem>-->
<!--<listitem>
<listitem>
<para>IPRoute2 &iproute2-version;</para>
</listitem>-->
</listitem>
<!--<listitem>
<para>Kbd &kbd-version;</para>
</listitem>-->
@ -269,6 +266,9 @@
<listitem>
<para>glibc-2.3.4-fix_test-1.patch</para>
</listitem>
<listitem>
<para>hotplug-2004-09-23</para>
</listitem>
<listitem>
<para>inetutils-1.4.2-kernel_headers-1.patch</para>
</listitem>

14
chapter03/packages.xml
View File

@ -242,14 +242,6 @@
</listitem>
</varlistentry>
<varlistentry>
<term>Hotplug (&hotplug-version;) - 40 KB:</term>
<listitem>
<para>Download: <ulink
url="&kernel;linux/utils/kernel/hotplug/hotplug-&hotplug-version;.tar.bz2"/></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Iana-Etc (&iana-etc-version;) - 174 KB:</term>
<listitem>
@ -270,7 +262,7 @@
</varlistentry>
<varlistentry>
<term>IPRoute2 (&iproute2-version;) - 291 KB:</term>
<term>IPRoute2 (&iproute2-version;) - 377 KB:</term>
<listitem>
<para>Home page: <ulink
url="http://linux-net.osdl.org/index.php/Iproute2"/></para>
@ -315,7 +307,7 @@
</varlistentry>
<varlistentry>
<term>Linux (&linux-version;) - 36,522 KB:</term>
<term>Linux (&linux-version;) - 39,884 KB:</term>
<listitem>
<para>Home page: <ulink url="http://www.kernel.org/"/></para>
<para>Download: <ulink
@ -522,7 +514,7 @@
</varlistentry>
<varlistentry>
<term>Udev (&udev-version;) - 427 KB:</term>
<term>Udev (&udev-version;) - 185 KB:</term>
<listitem>
<para>Home page: <ulink
url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/></para>

2
chapter03/patches.xml
View File

@ -138,7 +138,7 @@
</varlistentry>
<varlistentry>
<term>Linux kernel UTF-8 Composing Patch - 3 KB:</term>
<term>Linux kernel UTF-8 Composing Patch - 11 KB:</term>
<listitem>
<para><ulink url="&patches-root;&linux-utf8-patch;"/></para>
</listitem>

46
chapter05/changingowner.xml Normal file
View File

@ -0,0 +1,46 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-changingowner">
<?dbhtml filename="changingowner.html"?>
<title>Changing Ownership</title>
<note>
<para>The commands in the remainder of this book must be performed while
logged in as user <systemitem class="username">root</systemitem> and no
longer as user <systemitem class="username">lfs</systemitem>. Also, double
check that <envar>$LFS</envar> is set in <systemitem
class="username">root</systemitem>'s environment.</para>
</note>
<para>Currently, the <filename class="directory">/tools</filename> directory
is owned by the user <systemitem class="username">lfs</systemitem>, a user
that exists only on the host system. If the <filename
class="directory">/tools</filename> directory is kept as is, the files are
owned by a user ID without a corresponding account. This is dangerous because
a user account created later could get this same user ID and would own the
<filename class="directory">/tools</filename> directory and all the files
therein, thus exposing these files to possible malicious manipulation.</para>
<para>To avoid this issue, you could add the <systemitem
class="username">lfs</systemitem> user to the new LFS system later when
creating the <filename>/etc/passwd</filename> file, taking care to assign it
the same user and group IDs as on the host system. Better yet, change the
ownership of the <filename class="directory">/tools</filename> directory to
user <systemitem class="username">root</systemitem> by running the following
command:</para>
<screen><userinput>chown -R root:root /tools</userinput></screen>
<para>Although the <filename class="directory">/tools</filename> directory can
be deleted once the LFS system has been finished, it can be retained to build
additional LFS systems <emphasis>of the same book version</emphasis>. How best
to backup <filename class="directory">/tools</filename> is a matter of
personal preference and is left as an exercise for the reader.</para>
</sect1>

1
chapter05/chapter05.xml
View File

@ -42,5 +42,6 @@
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="texinfo.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="util-linux.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="stripping.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="changingowner.xml"/>
</chapter>

40
chapter06/changingowner.xml
View File

@ -1,40 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-system-changingowner">
<?dbhtml filename="changingowner.html"?>
<title>Changing Ownership</title>
<para>Currently, the <filename class="directory">/tools</filename> directory
is owned by the user <systemitem class="username">lfs</systemitem>, a user
that exists only on the host system. Although the <filename
class="directory">/tools</filename> directory can be deleted once the LFS
system has been finished, it can be retained to build additional LFS systems.
If the <filename class="directory">/tools</filename> directory is kept as is,
the files are owned by a user ID without a corresponding account. This is
dangerous because a user account created later could get this same user ID
and would own the <filename class="directory">/tools</filename> directory
and all the files therein, thus exposing these files to possible malicious
manipulation.</para>
<para>To avoid this issue, add the <systemitem class="username">lfs</systemitem>
user to the new LFS system later when creating the
<filename>/etc/passwd</filename> file, taking care to assign it the same user
and group IDs as on the host system. Alternatively, assign the contents of
the <filename class="directory">/tools</filename> directory to user
<systemitem class="username">root</systemitem> by running the following
command:</para>
<screen><userinput>chown -R 0:0 /tools</userinput></screen>
<para>The command uses <parameter>0:0</parameter> instead of
<parameter>root:root</parameter>, because <command>chown</command>
is unable to resolve the name <quote>root</quote> until the
<filename>passwd</filename> file has been created.</para>
</sect1>

6
chapter06/chapter06.xml
View File

@ -12,14 +12,11 @@
<title>Installing Basic System Software</title>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="introduction.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="pkgmgt.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="kernfs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="pkgmgt.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="chroot.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="changingowner.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingdirs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="createfiles.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="pwdgroup.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="devices.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="linux-libc-headers.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="man-pages.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="glibc.xml"/>
@ -53,7 +50,6 @@
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="grep.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="groff.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="gzip.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="hotplug.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="inetutils.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="iproute2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="kbd.xml"/>

18
chapter06/chroot.xml
View File

@ -44,16 +44,18 @@
reason, hashing is switched off by passing the <parameter>+h</parameter> option
to <command>bash</command>.</para>
<para>It is important that all the commands throughout the remainder of this
chapter and the following chapters are run from within the chroot environment.
If you leave this environment for any reason (rebooting for example), remember
to first mount the <systemitem class="filesystem">proc</systemitem> and
<systemitem class="filesystem">devpts</systemitem> file systems (discussed
in the previous section) and enter chroot again before continuing with the
installations.</para>
<para>Note that the <command>bash</command> prompt will say
<computeroutput>I have no name!</computeroutput> This is normal because the
<filename>/etc/passwd</filename> file has not been created yet.</para>
<note>
<para>It is important that all the commands throughout the remainder of this
chapter and the following chapters are run from within the chroot
environment. If you leave this environment for any reason (rebooting for
example), ensure that the virtual kernel filesystems are mounted as
explained in <xref linkend="ch-system-bindmount"/> and <xref
linkend="ch-system-kernfsmount"/> and enter chroot again before continuing
with the installation.</para>
</note>
</sect1>

116
chapter06/createfiles.xml
View File

@ -8,7 +8,31 @@
<sect1 id="ch-system-createfiles">
<?dbhtml filename="createfiles.html"?>
<title>Creating Essential Symlinks</title>
<title>Creating Essential Files and Symlinks</title>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/etc/passwd">/etc/passwd</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/etc/group">/etc/group</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/var/run/utmp">/var/run/utmp</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/var/log/btmp">/var/log/btmp</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/var/log/lastlog">/var/log/lastlog</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<primary sortas="e-/var/log/wtmp">/var/log/wtmp</primary>
</indexterm>
<para>Some programs use hard-wired paths to programs which do not exist yet. In
order to satisfy these programs, create a number of symbolic links which will be
@ -20,4 +44,94 @@ ln -sv /tools/bin/perl /usr/bin
ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib
ln -sv bash /bin/sh</userinput></screen>
<para>A proper Linux system maintains a list of the mounted file systems in
the file <filename>/etc/mtab</filename>. Normally, this file would be
created when we mount a new file system. Since we will not be mounting any
file systems inside our chroot environment, create an empty file for
utilities that expect the presence of <filename>/etc/mtab</filename>:</para>
<screen><userinput>touch /etc/mtab</userinput></screen>
<para>In order for user <systemitem class="username">root</systemitem> to be
able to login and for the name <quote>root</quote> to be recognized, there
must be relevant entries in the <filename>/etc/passwd</filename> and
<filename>/etc/group</filename> files.</para>
<para>Create the <filename>/etc/passwd</filename> file by running the following
command:</para>
<screen><userinput>cat &gt; /etc/passwd &lt;&lt; "EOF"
<literal>root:x:0:0:root:/root:/bin/bash</literal>
EOF</userinput></screen>
<para>The actual password for <systemitem class="username">root</systemitem>
(the <quote>x</quote> used here is just a placeholder) will be set later.</para>
<para>Create the <filename>/etc/group</filename> file by running the following
command:</para>
<screen><userinput>cat &gt; /etc/group &lt;&lt; "EOF"
<literal>root:x:0:
bin:x:1:
sys:x:2:
kmem:x:3:
tty:x:4:
tape:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
usb:x:14:
cdrom:x:15:</literal>
EOF</userinput></screen>
<para>The created groups are not part of any standard&mdash;they are groups
decided on in part by the requirements of the Udev configuration in this
chapter, and in part by common convention employed by a number of existing
Linux distributions. The Linux Standard Base (LSB, available at <ulink
url="http://www.linuxbase.org"/>) recommends only that, besides the group
<systemitem class="groupname">root</systemitem> with a Group ID (GID) of 0,
a group <systemitem class="groupname">bin</systemitem> with a GID of 1 be
present. All other group names and GIDs can be chosen freely by the system
administrator since well-written programs do not depend on GID numbers, but
rather use the group's name.</para>
<para>To remove the <quote>I have no name!</quote> prompt, start a new
shell. Since a full Glibc was installed in <xref
linkend="chapter-temporary-tools"/> and the
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>
files have been created, user name and group name resolution will now
work.</para>
<screen role="nodump"><userinput>exec /tools/bin/bash --login +h</userinput></screen>
<para>Note the use of the <parameter>+h</parameter> directive. This tells
<command>bash</command> not to use its internal path hashing. Without this
directive, <command>bash</command> would remember the paths to binaries it has
executed. To ensure the use of the newly compiled binaries as soon as they are
installed, the <parameter>+h</parameter> directive will be used for the duration
of this chapter.</para>
<para>The <command>login</command>, <command>agetty</command>, and
<command>init</command> programs (and others) use a number of log
files to record information such as who was logged into the system and
when. However, these programs will not write to the log files if they
do not already exist. Initialize the log files and give them
proper permissions:</para>
<screen><userinput>touch /var/run/utmp /var/log/{btmp,lastlog,wtmp}
chgrp -v utmp /var/run/utmp /var/log/lastlog
chmod -v 664 /var/run/utmp /var/log/lastlog</userinput></screen>
<para>The <filename>/var/run/utmp</filename> file records the users
that are currently logged in. The <filename>/var/log/wtmp</filename>
file records all logins and logouts. The
<filename>/var/log/lastlog</filename> file records when
each user last logged in. The <filename>/var/log/btmp</filename> file
records the bad login attempts.</para>
</sect1>

2
chapter06/creatingdirs.xml
View File

@ -13,7 +13,7 @@
<para>It is time to create some structure in the LFS file system. Create a
standard directory tree by issuing the following commands:</para>
<screen><userinput>install -dv /{bin,boot,dev,etc/opt,home,lib,mnt}
<screen><userinput>install -dv /{bin,boot,etc/opt,home,lib,mnt}
install -dv /{sbin,srv,usr/local,var,opt}
install -dv /root -m 0750
install -dv /tmp /var/tmp -m 1777

93
chapter06/devices.xml
View File

@ -1,93 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-system-devices">
<?dbhtml filename="devices.html"?>
<title>Populating /dev</title>
<indexterm zone="ch-system-devices">
<primary sortas="e-/dev/">/dev/*</primary>
</indexterm>
<sect2>
<title>Creating Initial Device Nodes</title>
<para>When the kernel boots the system, it requires the presence of a few
device nodes, in particular the <filename class="devicefile">console</filename>
and <filename class="devicefile">null</filename> devices. The device nodes
will be created on the hard disk so that they are available before
<command>udev</command> has been started, and additionally when Linux is
started in single user mode (hence the restrictive permissions on
<filename class="devicefile">console</filename>). Create the devices by
running the following commands:</para>
<screen><userinput>mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3</userinput></screen>
</sect2>
<sect2>
<title>Mounting tmpfs and Populating /dev</title>
<para>The recommended method of populating the <filename
class="directory">/dev</filename> directory with devices is to mount a
virtual filesystem (such as <systemitem class="filesystem">tmpfs</systemitem>)
on the <filename class="directory">/dev</filename> directory, and allow the
devices to be created dynamically on that virtual filesystem as they are
detected or accessed. This is generally done during the boot process. Since
this new system has not been booted, it is necessary to do what the
LFS-Bootscripts package would otherwise do by mounting <filename
class="directory">/dev</filename>:</para>
<screen><userinput>mount -nvt tmpfs none /dev</userinput></screen>
<para>The Udev package is what actually creates the devices in the <filename
class="directory">/dev</filename> directory. Since it will not be installed
until later on in the process, manually create the minimal set of device nodes
needed to complete the building of this system:</para>
<screen><userinput>mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
mknod -m 666 /dev/ptmx c 5 2
mknod -m 666 /dev/tty c 5 0
mknod -m 444 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
chown -v root:tty /dev/{console,ptmx,tty}</userinput></screen>
<para>There are some symlinks and directories required by LFS that are
created during system startup by the LFS-Bootscripts package. Since this
is a chroot environment and not a booted environment, those symlinks and
directories need to be created here:</para>
<screen><userinput>ln -sv /proc/self/fd /dev/fd
ln -sv /proc/self/fd/0 /dev/stdin
ln -sv /proc/self/fd/1 /dev/stdout
ln -sv /proc/self/fd/2 /dev/stderr
ln -sv /proc/kcore /dev/core
mkdir -v /dev/pts
mkdir -v /dev/shm</userinput></screen>
<para>Finally, mount the proper virtual (kernel) file systems on the
newly-created directories:</para>
<screen><userinput>mount -vt devpts -o gid=4,mode=620 none /dev/pts
mount -vt tmpfs none /dev/shm</userinput></screen>
<para>The <command>mount</command> commands executed above may result
in the following warning message:</para>
<screen><computeroutput>can't open /etc/fstab: No such file or directory.</computeroutput></screen>
<para>This file&mdash;<filename>/etc/fstab</filename>&mdash;has not
been created yet but is also not required for the file systems to be
properly mounted. As such, the warning can be safely ignored.</para>
</sect2>
</sect1>

223
chapter06/hotplug.xml
View File

@ -1,223 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-system-hotplug" role="wrap">
<?dbhtml filename="hotplug.html"?>
<title>Hotplug-&hotplug-version;</title>
<indexterm zone="ch-system-hotplug">
<primary sortas="a-Hotplug">Hotplug</primary>
</indexterm>
<sect2 role="package">
<title/>
<para>The Hotplug package contains scripts that react upon hotplug events
generated by the kernel. Such events correspond to every change in the kernel
state visible in the <systemitem class="filesystem">sysfs</systemitem>
filesystem, e.g., the addition and removal of hardware. This package also
detects existing hardware during boot and inserts the relevant modules into the
running kernel.</para>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem>
<seg>0.01 SBU</seg>
<seg>460 KB</seg>
</seglistitem>
</segmentedlist>
<segmentedlist>
<segtitle>&dependencies;</segtitle>
<seglistitem>
<seg>Bash, Coreutils, Findutils, Gawk, and Make</seg>
</seglistitem>
</segmentedlist>
</sect2>
<sect2 role="installation">
<title>Installation of Hotplug</title>
<para>This package does not come with a test suite.</para>
<para>Install the Hotplug package:</para>
<screen><userinput>make install</userinput></screen>
<para>Copy a file that the <quote>install</quote> target omits.</para>
<screen><userinput>cp -v etc/hotplug/pnp.distmap /etc/hotplug</userinput></screen>
<para>Remove the init script that Hotplug installs since we are going to be
using the script included in the LFS-Bootscripts package:</para>
<screen><userinput>rm -rfv /etc/init.d</userinput></screen>
<para>Network device hotplugging is not yet supported by the LFS-Bootscripts
package. For that reason, remove the network hotplug agent:</para>
<screen><userinput>rm -fv /etc/hotplug/net.agent</userinput></screen>
<para>Create a directory for storing firmware that can be loaded by
<command>hotplug</command>:</para>
<screen><userinput>mkdir -v /lib/firmware</userinput></screen>
</sect2>
<sect2 id="contents-hotplug" role="content">
<title>Contents of Hotplug</title>
<segmentedlist>
<segtitle>Installed program</segtitle>
<segtitle>Installed scripts</segtitle>
<segtitle>Installed files</segtitle>
<seglistitem>
<seg>hotplug</seg>
<seg>/etc/hotplug/*.rc, /etc/hotplug/*.agent</seg>
<seg>/etc/hotplug/hotplug.functions, /etc/hotplug/blacklist,
/etc/hotplug/{pci,usb}, /etc/hotplug/usb.usermap, /etc/hotplug.d,
and /var/log/hotplug/events</seg>
</seglistitem>
</segmentedlist>
<variablelist>
<bridgehead renderas="sect3">Short Descriptions</bridgehead>
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<varlistentry id="hotplug">
<term><command>hotplug</command></term>
<listitem>
<para>This script is called by default by the Linux kernel when
something changes in its internal state (e.g., a new device is
added or an existing device is removed)</para>
<indexterm zone="ch-system-hotplug hotplug">
<primary sortas="b-hotplug">hotplug</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-rc">
<term><command>/etc/hotplug/*.rc</command></term>
<listitem>
<para>These scripts are used for cold plugging, i.e., detecting and
acting upon hardware already present during system startup. They are
called by the <filename>hotplug</filename> initscript included in
the LFS-Bootscripts package. The <command>*.rc</command> scripts try
to recover hotplug events that were lost during system boot because,
for example, the root filesystem was not mounted by the kernel</para>
<indexterm zone="ch-system-hotplug hotplug-rc">
<primary sortas="d-/etc/hotplug/*.rc">/etc/hotplug/*.rc</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-agent">
<term><command>/etc/hotplug/*.agent</command></term>
<listitem>
<para>These scripts are called by <command>hotplug</command> in response
to different types of hotplug events generated by the kernel. Their
action is to insert corresponding kernel modules and call any
user-provided scripts</para>
<indexterm zone="ch-system-hotplug hotplug-agent">
<primary sortas="d-/etc/hotplug/*.agent">/etc/hotplug/*.agent</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-blacklist">
<term><filename>/etc/hotplug/blacklist</filename></term>
<listitem>
<para>This file contains the list of modules that should never be
inserted into the kernel by the Hotplug scripts</para>
<indexterm zone="ch-system-hotplug hotplug-blacklist">
<primary sortas="e-/etc/hotplug/blacklist">/etc/hotplug/blacklist</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-functions">
<term><filename>/etc/hotplug/hotplug.functions</filename></term>
<listitem>
<para>This file contains common functions used by other scripts in the
Hotplug package</para>
<indexterm zone="ch-system-hotplug hotplug-functions">
<primary sortas="e-/etc/hotplug/hotplug.functions">/etc/hotplug/hotplug.functions</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-subdirs">
<term><filename class="directory">/etc/hotplug/{pci,usb}</filename></term>
<listitem>
<para>These directories contain user-written handlers for hotplug
events</para>
<indexterm zone="ch-system-hotplug hotplug-subdirs">
<primary sortas="e-/etc/hotplug/{pci,usb}">/etc/hotplug/{pci,usb}</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-usb.usermap">
<term><filename>/etc/hotplug/usb.usermap</filename></term>
<listitem>
<para>This file contains rules that determine which user-defined handlers to
call for each USB device, based on its vendor ID and other
attributes</para>
<indexterm zone="ch-system-hotplug hotplug-usb.usermap">
<primary sortas="e-/etc/hotplug/usb.usermap">/etc/hotplug/usb.usermap</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-hotplug.d">
<term><filename class="directory">/etc/hotplug.d</filename></term>
<listitem>
<para>This directory contains programs (or symlinks to them) that are
interested in receiving hotplug events. For example, Udev puts its
symlink here during installation</para>
<indexterm zone="ch-system-hotplug hotplug-hotplug.d">
<primary sortas="e-/etc/hotplug.d">/etc/hotplug.d</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-firmware">
<term><filename class="directory">/lib/firmware</filename></term>
<listitem>
<para>This directory contains the firmware for devices that need to
have their firmware loaded before use</para>
<indexterm zone="ch-system-hotplug hotplug-firmware">
<primary sortas="e-/lib/firmware">/lib/firmware</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="hotplug-events">
<term><filename>/var/log/hotplug/events</filename></term>
<listitem>
<para>This file contains all the events that <command>hotplug</command>
has called since bootup</para>
<indexterm zone="ch-system-hotplug hotplug-events">
<primary sortas="e-/var/log/hotplug/events">/var/log/hotplug/events</primary>
</indexterm>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>

7
chapter06/introduction.xml
View File

@ -55,11 +55,4 @@
there is a list of programs and libraries (along with brief descriptions of
these) that the package installs.</para>
<note>
<para>At this point, you may wish to keep your finished temporary
tools for use in future LFS builds by creating a tarball of the
<filename class="directory">/tools</filename> directory and
storing it in a safe location.</para>
</note>
</sect1>

4
chapter06/iproute2.xml
View File

@ -25,8 +25,8 @@
<segtitle>&diskspace;</segtitle>
<seglistitem>
<seg>0.1 SBU</seg>
<seg>4.3 MB</seg>
<seg>0.2 SBU</seg>
<seg>4.8 MB</seg>
</seglistitem>
</segmentedlist>

81
chapter06/kernfs.xml
View File

@ -8,33 +8,72 @@
<sect1 id="ch-system-kernfs">
<?dbhtml filename="kernfs.html"?>
<title>Mounting Virtual Kernel File Systems</title>
<title>Preparing Virtual Kernel File Systems</title>
<para>Various file systems exported by the kernel are used to communicate to and
from the kernel itself. These file systems are virtual in that no disk space is
used for them. The content of the file systems resides in memory.</para>
<indexterm zone="ch-system-kernfs">
<primary sortas="e-/dev/">/dev/*</primary>
</indexterm>
<para>Begin by creating directories onto which the file systems will be
mounted:</para>
<para>Various file systems exported by the kernel are used to communicate to
and from the kernel itself. These file systems are virtual in that no disk
space is used for them. The content of the file systems resides in
memory.</para>
<screen><userinput>mkdir -pv $LFS/{proc,sys}</userinput></screen>
<para>Begin by creating directories onto which the file systems will be
mounted:</para>
<para>Now mount the file systems:</para>
<screen><userinput>mkdir -pv $LFS/{dev,proc,sys}</userinput></screen>
<screen><userinput>mount -vt proc proc $LFS/proc
<sect2>
<title>Creating Initial Device Nodes</title>
<para>When the kernel boots the system, it requires the presence of a few
device nodes, in particular the <filename
class="devicefile">console</filename> and <filename
class="devicefile">null</filename> devices. The device nodes will be created
on the hard disk so that they are available before <command>udev</command>
has been started, and additionally when Linux is started in single user mode
(hence the restrictive permissions on <filename
class="devicefile">console</filename>). Create the devices by running the
following commands:</para>
<screen><userinput>mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3</userinput></screen>
</sect2>
<sect2 id="ch-system-bindmount">
<title>Mounting and Populating /dev</title>
<para>The recommended method of populating the <filename
class="directory">/dev</filename> directory with devices is to mount a
virtual filesystem (such as <systemitem
class="filesystem">tmpfs</systemitem>) on the <filename
class="directory">/dev</filename> directory, and allow the devices to be
created dynamically on that virtual filesystem as they are detected or
accessed. This is generally done during the boot process by Udev. Since
this new system does not yet have Udev and has not yet been booted, it is
necessary to mount and populate <filename
class="directory">/dev</filename> manually. This is accomplished by bind
mounting the host system's <filename class="directory">/dev</filename>
directory. A bind mount is a special type of mount that allows you to
create a mirror of a directory or mount point to some other location. Use
the following command to achieve this:</para>
<screen><userinput>mount --bind /dev $LFS/dev</userinput></screen>
</sect2>
<sect2 id="ch-system-kernfsmount">
<title>Mounting Virtual Kernel File Systems</title>
<para>Now mount the remaining virtual kernel filesystems:</para>
<screen><userinput>mount -vt devpts devpts $LFS/dev/pts
mount -vt tmpfs shm $LFS/dev/shm
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys</userinput></screen>
<para>Remember that if for any reason you stop working on the LFS
system and start again later, it is important to check that these file
systems are mounted again before entering the chroot
environment.</para>
<para>Additional file systems will soon be mounted from within the
chroot environment. To keep the host up to date, perform a <quote>fake
mount</quote> for each of these now:</para>
<screen><userinput>mount -vft tmpfs tmpfs $LFS/dev
mount -vft tmpfs tmpfs $LFS/dev/shm
mount -vft devpts -o gid=4,mode=620 devpts $LFS/dev/pts</userinput></screen>
</sect2>
</sect1>

8
chapter06/pkgmgt.xml
View File

@ -39,14 +39,6 @@
the <ulink url="&hints-root;">Hints subproject</ulink> and see if one of them
fits your need.</para>
<note>
<para>As no particular package management technique is mentioned in LFS,
the commands in the remainder of this book must be performed while logged in
as user <systemitem class="username">root</systemitem> and no longer as user
<systemitem class="username">lfs</systemitem>. Also, double check that
<envar>$LFS</envar> is set.</para>
</note>
<sect2>
<title>Upgrade Issues</title>

243
chapter06/udev.xml
View File

@ -26,7 +26,7 @@
<seglistitem>
<seg>0.1 SBU</seg>
<seg>3.8 MB</seg>
<seg>4.8 MB</seg>
</seglistitem>
</segmentedlist>
@ -43,19 +43,31 @@
<sect2 role="installation">
<title>Installation of Udev</title>
<para>Create some devices and directories that Udev cannot handle due to
them being required very early in the boot process:</para>
<screen><userinput>install -dv /lib/{firmware,udev/devices/{pts,shm}}
mknod -m0666 /lib/udev/devices/null c 1 3
ln -sv /proc/self/fd /lib/udev/devices/fd
ln -sv /proc/self/fd/0 /lib/udev/devices/stdin
ln -sv /proc/self/fd/1 /lib/udev/devices/stdout
ln -sv /proc/self/fd/2 /lib/udev/devices/stderr
ln -sv /proc/kcore /lib/udev/devices/core</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make EXTRAS=extras/run_directory</userinput></screen>
<screen><userinput>make EXTRAS="extras/ata_id extras/cdrom_id extras/edd_id \
extras/firmware extras/floppy extras/scsi_id \
extras/usb_id extras/volume_id"</userinput></screen>
<variablelist>
<title>The meaning of the make option:</title>
<varlistentry>
<term><parameter>EXTRAS=extras/run_directory</parameter></term>
<term><parameter>EXTRAS=...</parameter></term>
<listitem>
<para>This builds the <command>udev_run_devd</command> and
<command>udev_run_hotplugd</command> binaries, which are required
for correct handling of hotpluggable devices.</para>
<para>This builds several helper binaries that can aid in writing custom
Udev rules.</para>
</listitem>
</varlistentry>
@ -66,7 +78,10 @@
<para>Install the package:</para>
<screen><userinput>make DESTDIR=/ EXTRAS=extras/run_directory install</userinput></screen>
<screen><userinput>make DESTDIR=/ \
EXTRAS="extras/ata_id extras/cdrom_id extras/edd_id \
extras/firmware extras/floppy extras/scsi_id \
extras/usb_id extras/volume_id" install</userinput></screen>
<variablelist>
<title>The meaning of the make parameter:</title>
@ -87,16 +102,78 @@
<screen><userinput>cp -v ../&udev-config-file; /etc/udev/rules.d/25-lfs.rules</userinput></screen>
<para>Create some rules that work around broken sysfs attribute creation
timing in linux-2.6.15:</para>
<screen><userinput>cat &gt;&gt; /etc/udev/rules.d/10-wait_for_sysfs.rules &lt;&lt; "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>
<!-- Not for the LiveCD -->
<!-- Edit Me -->
<para>Run the <command>udevstart</command> program to create our full
complement of device nodes.</para>
<important>
<screen><userinput>/sbin/udevstart</userinput></screen>
<para>When Udev is started by the LFS-Bootscripts, a replay of all kernel
device events happens. These events tell Udev what devices exist.
Sometimes the Udev bootscript doesn't wait long enough for
<command>udevd</command> to process all of the replayed events and
consequently the devices for those missed events are not created before the
script exits. Since <command>udevd</command> is still running in the
background, the devices will be created a few milliseconds later, but the
next bootscript to run may require a device to exist before it has been
created. To avoid such missed events, and to avoid hardcoding an overly
long wait time, It is recommended that you run the following commands to
aid the LFS development team in debugging these missed events and finding
an acceptable solution more quickly.</para>
<para>First, create a simple C file:</para>
<screen><userinput>cat &gt; bug.c &lt;&lt; EOF
<literal>/* Simple event recorder */
#define _GNU_SOURCE
#include &lt;sys/types.h&gt;
#include &lt;sys/stat.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;unistd.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;argz.h&gt;
int main(int argc, char * argv[])
{
char * envz;
size_t len;
int bug;
bug = open("/dev/bug", O_WRONLY | O_APPEND);
if (bug == -1)
return 0;
setenv("_SEPARATOR", "--------------------------------------", 1);
argz_create(environ, &amp;envz, &amp;len);
argz_stringify(envz, len, '\n');
envz[len-1]='\n';
write(bug, envz, len);
close(bug);
free(envz);
return 0;
}</literal>
EOF</userinput></screen>
<para>Now compile it:</para>
<screen><userinput>gcc -o /lib/udev/bug bug.c</userinput></screen>
<para>The next step adds a simple logging rule to run this program.</para>
<screen><userinput>cat &gt; /etc/udev/rules.d/90-bug.rules &lt;&lt; "EOF"
<literal>ACTION=="add", RUN+="bug"</literal>
EOF</userinput></screen>
<para>When booting the new LFS system, if any events are missed, a warning
message will appear and a <filename>/dev/bugreport</filename> file will be
created. The warning message will tell you where to send feedback.</para>
</important>
</sect2>
@ -108,8 +185,9 @@
<segtitle>Installed directory</segtitle>
<seglistitem>
<seg>udev, udev_run_devd, udev_run_hotplugd, udevcontrol, udevd,
udevinfo, udevmonitor, udevsend, udevstart, and udevtest</seg>
<seg>ata_id, cdrom_id, create_floppy_devices, edd_id, firmware_helper,
scsi_id, udevcontrol, udevd, udevinfo, udevmonitor, udevtest, usb_id
and vol_id</seg>
<seg>/etc/udev</seg>
</seglistitem>
</segmentedlist>
@ -119,38 +197,66 @@
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<varlistentry id="udev">
<term><command>udev</command></term>
<varlistentry id="ata_id">
<term><command>ata_id</command></term>
<listitem>
<para>Creates device nodes in <filename class="directory">/dev</filename>
or renames network interfaces (not in LFS) in response to hotplug
events</para>
<indexterm zone="ch-system-udev udev">
<primary sortas="b-udev">udev</primary>
<para>Provides Udev with a unique string and
additional information (uuid, label) for an ATA drive</para>
<indexterm zone="ch-system-udev ata_id">
<primary sortas="b-ata_id">ata_id</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="udev_run_devd">
<term><command>udev_run_devd</command></term>
<varlistentry id="cdrom_id">
<term><command>cdrom_id</command></term>
<listitem>
<para>Executes programs and scripts in the <filename
class="directory">/etc/dev.d/</filename> directory in response to
hotplug events</para>
<indexterm zone="ch-system-udev udev_run_devd">
<primary sortas="b-udev_run_devd">udev_run_devd</primary>
<para>Provides Udev with the capabilities of a
CD-ROM or DVD-ROM drive</para>
<indexterm zone="ch-system-udev cdrom_id">
<primary sortas="b-cdrom_id">cdrom_id</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="udev_run_hotplugd">
<term><command>udev_run_hotplugd</command></term>
<varlistentry id="create_floppy_devices">
<term><command>create_floppy_devices</command></term>
<listitem>
<para>Executes programs and scripts in the <filename
class="directory">/etc/hotplug.d/</filename> directory in response
to hotplug events</para>
<indexterm zone="ch-system-udev udev_run_hotplugd">
<primary sortas="b-udev_run_hotplugd">udev_run_hotplugd</primary>
<para>Creates all possible floppy devices based on the CMOS type</para>
<indexterm zone="ch-system-udev create_floppy_devices">
<primary sortas="b-create_floppy_devices">create_floppy_devices</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="edd_id">
<term><command>edd_id</command></term>
<listitem>
<para>Provides Udev with the EDD ID for a BIOS disk drive</para>
<indexterm zone="ch-system-udev edd_id">
<primary sortas="b-edd_id">edd_id</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="firmware_helper">
<term><command>firmware_helper</command></term>
<listitem>
<para>Uploads firmware to devices</para>
<indexterm zone="ch-system-udev firmware_helper">
<primary sortas="b-firmware_helper">firmware_helper</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="scsi_id">
<term><command>scsi_id</command></term>
<listitem>
<para>Provides Udev with a unique SCSI identifier
based on the data returned from sending a SCSI INQUIRY command to
the specified device</para>
<indexterm zone="ch-system-udev scsi_id">
<primary sortas="b-scsi_id">scsi_id</primary>
</indexterm>
</listitem>
</varlistentry>
@ -169,8 +275,9 @@
<varlistentry id="udevd">
<term><command>udevd</command></term>
<listitem>
<para>A daemon that reorders hotplug events before submitting them to
<command>udev</command>, thus avoiding various race conditions</para>
<para>A daemon that listens for uevents on the netlink socket,
creates devices and runs the configured external programs in
response to these uevents</para>
<indexterm zone="ch-system-udev udevd">
<primary sortas="b-udevd">udevd</primary>
</indexterm>
@ -180,7 +287,7 @@
<varlistentry id="udevinfo">
<term><command>udevinfo</command></term>
<listitem>
<para>Allows users to query the <command>udev</command> database for
<para>Allows users to query the Udev database for
information on any device currently present on the system; it also
provides a way to query any device in the <systemitem
class="filesystem">sysfs</systemitem> tree to help create udev
@ -194,56 +301,52 @@
<varlistentry id="udevmonitor">
<term><command>udevmonitor</command></term>
<listitem>
<para>Prints the event received from the kernel and the event which
<command>udev</command> sends out after rule processing</para>
<para>Prints the event received from the kernel and the environment
which Udev sends out after rule processing</para>
<indexterm zone="ch-system-udev udevmonitor">
<primary sortas="b-udevmonitor">udevmonitor</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="udevsend">
<term><command>udevsend</command></term>
<listitem>
<para>Delivers hotplug events to <command>udevd</command></para>
<indexterm zone="ch-system-udev udevsend">
<primary sortas="b-udevsend">udevsend</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="udevstart">
<term><command>udevstart</command></term>
<listitem>
<para>Creates device nodes in <filename class="directory">/dev</filename>
that correspond to drivers compiled directly into the kernel; it
performs that task by simulating hotplug events presumably dropped by
the kernel before invocation of this program (e.g., because the root
filesystem has not been mounted) and submitting such synthetic hotplug
events to <command>udev</command></para>
<indexterm zone="ch-system-udev udevstart">
<primary sortas="b-udevstart">udevstart</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="udevtest">
<term><command>udevtest</command></term>
<listitem>
<para>Simulates a <command>udev</command> run for the given device,
and prints out the name of the node the real <command>udev</command>
would have created or (not in LFS) the name of the renamed network
interface</para>
<para>Simulates a uevent for the given device, and prints out the
name of the node the real <command>udevd</command> would have created,
or the name of the renamed network interface</para>
<indexterm zone="ch-system-udev udevtest">
<primary sortas="b-udevtest">udevtest</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="usb_id">
<term><command>usb_id</command></term>
<listitem>
<para>Provides Udev with information about USB
devices</para>
<indexterm zone="ch-system-udev usb_id">
<primary sortas="b-usb_id">usb_id</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="vol_id">
<term><command>vol_id</command></term>
<listitem>
<para>Provides Udev with the label and uuid of a
filesystem</para>
<indexterm zone="ch-system-udev vol_id">
<primary sortas="b-vol_id">vol_id</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="etc-udev">
<term><filename class="directory">/etc/udev</filename></term>
<listitem>
<para>Contains <command>udev</command> configuation files,
<para>Contains Udev configuation files,
device permissions, and rules for device naming</para>
<indexterm zone="ch-system-udev etc-udev">
<primary sortas="e-/etc/udev">/etc/udev</primary>

12
chapter07/bootscripts.xml
View File

@ -56,7 +56,7 @@
<segtitle>Installed scripts</segtitle>
<seglistitem>
<seg>checkfs, cleanfs, console, functions, halt, hotplug, ifdown, ifup,
<seg>checkfs, cleanfs, console, functions, halt, ifdown, ifup,
localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals,
setclock, static, swap, sysklogd, template, and udev</seg>
</seglistitem>
@ -125,16 +125,6 @@
</listitem>
</varlistentry>
<varlistentry id="hotplug-bootscripts">
<term><command>hotplug</command></term>
<listitem>
<para>Loads modules for system devices</para>
<indexterm zone="ch-scripts-bootscripts hotplug-bootscripts">
<primary sortas="d-hotplug">hotplug</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="ifdown-bootscripts">
<term><command>ifdown</command></term>
<listitem>

42
chapter07/network.xml
View File

@ -23,6 +23,48 @@
symlinks from all run-level directories (<filename
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. For example, on a computer having
two network cards made by Intel and Realtek, the network card manufactured
by Intel may become <filename class="devicefile">eth0</filename> and the
Realtek card becomes <filename class="devicefile">eth1</filename>. In some
cases, after a reboot the cards get renumbered the other way around. 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 role="nodump"><userinput>cat &gt; /etc/udev/rules.d/26-network.rules &lt;&lt; "EOF"
<literal>ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>52:54:00:12:34:56</replaceable>", NAME="<replaceable>realtek</replaceable>"
ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", NAME="<replaceable>intel</replaceable>"</literal>
EOF</userinput></screen>
<para>These rules 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>

382
chapter07/udev.xml
View File

@ -23,13 +23,15 @@
<para>Linux systems in general traditionally use a static device creation
method, whereby a great many device nodes are created under <filename
class="directory">/dev</filename> (sometimes literally thousands of nodes),
regardless of whether the corresponding hardware devices actually exist. This is
typically done via a <command>MAKEDEV</command> script, which contains a number
of calls to the <command>mknod</command> program with the relevant major and
minor device numbers for every possible device that might exist in the world.
Using the Udev method, only those devices which are detected by the kernel get
device nodes created for them. Because these device nodes will be created each
time the system boots, they will be stored on a <systemitem
regardless of whether the corresponding hardware devices actually exist. This
is typically done via a <command>MAKEDEV</command> script, which contains a
number of calls to the <command>mknod</command> program with the relevant
major and minor device numbers for every possible device that might exist in
the world.</para>
<para>Using the Udev method, only those devices which are detected by the
kernel get device nodes created for them. Because these device nodes will be
created each time the system boots, they will be stored on a <systemitem
class="filesystem">tmpfs</systemitem> file system (a virtual file system that
resides entirely in system memory). Device nodes do not require much space, so
the memory that is used is negligible.</para>
@ -50,160 +52,278 @@
naming, was perhaps the most critical. It is generally accepted that if
device names are allowed to be configurable, then the device naming policy
should be up to a system administrator, not imposed on them by any
particular developer(s). The <systemitem class="filesystem">devfs</systemitem>
file system also suffers from race conditions that are inherent in its design
and cannot be fixed without a substantial revision to the kernel. It has also
been marked as deprecated due to a lack of recent maintenance.</para>
particular developer(s). The <systemitem
class="filesystem">devfs</systemitem> file system also suffers from race
conditions that are inherent in its design and cannot be fixed without a
substantial revision to the kernel. It has also been marked as deprecated
due to a lack of recent maintenance.</para>
<para>With the development of the unstable 2.5 kernel tree, later released as
the 2.6 series of stable kernels, a new virtual filesystem called <systemitem
class="filesystem">sysfs</systemitem> came to be. The job of <systemitem
class="filesystem">sysfs</systemitem> is to export a view of the system's
hardrware configuration to userspace processes. With this userspace-visible
representation, the possibility of seeing a userspace replacement for
<systemitem class="filesystem">devfs</systemitem> became much more
realistic.</para>
<para>With the development of the unstable 2.5 kernel tree, later released
as the 2.6 series of stable kernels, a new virtual filesystem called
<systemitem class="filesystem">sysfs</systemitem> came to be. The job of
<systemitem class="filesystem">sysfs</systemitem> is to export a view of
the system's hardware configuration to userspace processes. With this
userspace-visible representation, the possibility of seeing a userspace
replacement for <systemitem class="filesystem">devfs</systemitem> became
much more realistic.</para>
</sect2>
<sect2>
<title>Udev Implementation</title>
<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
mentioned briefly above. One may wonder how <systemitem
class="filesystem">sysfs</systemitem> knows about the devices present on
a system and what device numbers should be used for them. Drivers that have
been compiled into the kernel directly register their objects with
<systemitem class="filesystem">sysfs</systemitem> as they are detected by
the kernel. For drivers compiled as modules, this registration will happen
when the module is loaded. Once the <systemitem
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
node creation.</para>
<sect3>
<title>Sysfs</title>
<para>The <command>S10udev</command> initscript takes care of creating
these device nodes when Linux is booted. This script starts by registering
<command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events
(discussed below) are not usually generated during this stage, but
<command>udev</command> is registered just in case they do occur. The
<command>udevstart</command> program then walks through the <systemitem
class="filesystem">/sys</systemitem> filesystem and creates devices under
<filename class="directory">/dev</filename> that match the descriptions.
For example, <filename>/sys/class/tty/vcs/dev</filename> contains the
string <quote>7:0</quote> This string is used by <command>udevstart</command>
to create <filename>/dev/vcs</filename> with major number
<emphasis>7</emphasis> and minor <emphasis>0</emphasis>. The names and
permissions of the nodes created under the <filename
class="directory">/dev</filename> directory are configured according to the
rules specified in the files within the <filename
class="directory">/etc/udev/rules.d/</filename> directory. These are
numbered in a similar fashion to the LFS-Bootscripts package. If
<command>udev</command> can't find a rule for the device it is creating,
it will default permissions to <emphasis>660</emphasis> and ownership to
<emphasis>root:root</emphasis>.</para>
<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
mentioned briefly above. One may wonder how <systemitem
class="filesystem">sysfs</systemitem> knows about the devices present on
a system and what device numbers should be used for them. Drivers that
have been compiled into the kernel directly register their objects with
<systemitem class="filesystem">sysfs</systemitem> as they are detected by
the kernel. For drivers compiled as modules, this registration will happen
when the module is loaded. Once the <systemitem
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>udevd</command> for device
node creation.</para>
<para>Once the above stage is complete, all devices that were already present
and have compiled-in drivers will be available for use. This leads us to the
devices that have modular drivers.</para>
</sect3>
<para>Earlier, we mentioned the concept of a <quote>hotplug event
handler.</quote> When a new device connection is detected by the kernel,
the kernel will generate a hotplug event and look at the file
<filename>/proc/sys/kernel/hotplug</filename> to determine the userspace
program that handles the device's connection. The <command>udev</command>
bootscript registered <command>udevsend</command> as this handler. When
these hotplug events are generated, the kernel will tell
<command>udev</command> to check the <filename
class="directory">/sys</filename> filesystem for the information pertaining
to this new device and create the <filename class="directory">/dev</filename>
entry for it.</para>
<sect3>
<title>Udev Bootscript</title>
<para>This brings us to one problem that exists with <command>udev</command>,
and likewise with <systemitem class="filesystem">devfs</systemitem> before it.
It is commonly referred to as the <quote>chicken and egg</quote> problem. Most
Linux distributions handle loading modules via entries in
<filename>/etc/modules.conf</filename>. Access to a device node causes the
appropriate kernel module to load. With <command>udev</command>, this method
will not work because the device node does not exist until the module is loaded.
To solve this, the <command>S05modules</command> bootscript was added to the
LFS-Bootscripts package, along with the
<filename>/etc/sysconfig/modules</filename> file. By adding module names to the
<filename>modules</filename> file, these modules will be loaded when the
computer starts up. This allows <command>udev</command> to detect the devices
and create the appropriate device nodes.</para>
<para>The <command>S10udev</command> initscript takes care of creating
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>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,
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
an easy workaround for devices that are not supported by the dynamic
device handling infrastructure. The bootscript then starts the Udev
daemon, <command>udevd</command>, which will act on any hotplug events it
receives. Finally, the bootscript &quot;coldplugs&quot; any devices that
have already been registered with the kernel by forcing them to raise
hotplug events which <command>udevd</command> will then handle.</para>
<para>Note that on slower machines or for drivers that create a lot of device
nodes, the process of creating devices may take a few seconds to complete.
This means that some device nodes may not be immediately accessible.</para>
</sect3>
<sect3>
<title>Device Node Creation</title>
<para>To obtain the right major and minor number for a device, Udev relies
on the information provided by <systemitem
class="filesystem">sysfs</systemitem> in <filename
class="directory">/sys</filename>. For example,
<filename>/sys/class/tty/vcs/dev</filename> contains the string
<quote>7:0</quote>. This string is used by <command>udevd</command>
to create a device node with major number <emphasis>7</emphasis> and minor
<emphasis>0</emphasis>. The names and permissions of the nodes created
under the <filename class="directory">/dev</filename> directory are
determined by rules specified in the files within the <filename
class="directory">/etc/udev/rules.d/</filename> directory. These are
numbered in a similar fashion to the LFS-Bootscripts package. If
<command>udevd</command> can't find a rule for the device it is creating,
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-&udev-version;/index.html</filename></para>
</sect3>
<sect3>
<title>Module Loading</title>
<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. For example, the <emphasis>snd-fm801</emphasis>
driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
For most devices, the bus driver exports the alias of the driver that
would handle the device via <systemitem
class="filesystem">sysfs</systemitem>. 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 for ways in which the loading of unwanted drivers can
be prevented.</para>
<para>The kernel itself is also able to load modules for network
protocols, filesystems and NLS support on demand.</para>
</sect3>
<sect3>
<title>Handling Hotpluggable/Dynamic Devices</title>
<para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
player, the kernel recognizes that the device is now connected and
generates a hotplug event. This hotplug event is then handled by
<command>udevd</command> as described above.</para>
</sect3>
</sect2>
<sect2>
<title>Handling Hotpluggable/Dynamic Devices</title>
<title>Problems with Loading Modules and Creating Devices</title>
<para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
player, the kernel recognizes that the device is now connected and generates
a hotplug event. If the driver is already loaded (either because it was
compiled into the kernel or because it was loaded via the
<command>S05modules</command> bootscript), <command>udev</command> will be
called upon to create the relevant device node(s) according to the
<systemitem class="filesystem">sysfs</systemitem> data available in
<filename class="directory">/sys</filename>.</para>
<para>There are a few possible problems when it comes to automatically
creating device nodes.</para>
<para>If the driver for the just plugged in device is available as a module but
currently unloaded, the Hotplug package will load the appropriate module
and make this device available by creating the device node(s) for it.</para>
<sect3>
<title>A kernel module is not loaded automatically</title>
</sect2>
<para>Udev will only load a module if it has a bus-specific alias and the
bus driver properly exports the necessary aliases to <systemitem
class="filesystem">sysfs</systemitem>. In other cases, one should
arrange module loading by other means. With Linux-&linux-version;, Udev is
known to load properly-written drivers for PCI, USB, SCSI, SERIO and
FireWire devices.</para>
<sect2>
<title>Problems with Creating Devices</title>
<!-- After linux-2.6.16, add INPUT and IDE to the list above -->
<para>There are a few known problems when it comes to automatically creating
device nodes:</para>
<para>To determine if the device driver you require has the necessary
support for Udev, run <command>modinfo</command> with the module name as
the argument. Now try locating the device directory under
<filename class="directory">/sys/bus</filename> and check whether there is
a <filename>modalias</filename> file there.</para>
<para>1) A kernel driver may not export its data to <systemitem
class="filesystem">sysfs</systemitem>.</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>
<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. Use the <filename>/etc/sysconfig/createfiles</filename>
configuration file to manually create the devices. Consult the
<filename>devices.txt</filename> file inside the kernel documentation or
the documentation for that driver to find the proper major/minor
numbers.</para>
<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-&linux-version;, this is the case with ISA and
IDE busses. Expect this issue to be fixed in later kernel versions.</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 above after Linux-2.6.16 -->
<itemizedlist>
<para>Udev is not intended 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>
<listitem>
<para>Adding the module names to
<filename>/etc/sysconfig/modules</filename></para>
</listitem>
</sect3>
<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>
<sect3>
<title>A kernel module is not loaded automatically, and Udev is not
intended to load it</title>
<screen role="nodump"><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \
snd-pcm-oss ; true</userinput></screen>
<para>If the <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, add an <quote>install</quote> line in
<filename>/etc/modprobe.conf</filename>. For example:</para>
<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>
<screen role="nodump"><literal>install snd-pcm modprobe -i snd-pcm ; modprobe \
snd-pcm-oss ; true</literal></screen>
</itemizedlist>
<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>
<sect3>
<title>Udev loads some unwanted module</title>
<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"><literal>blacklist forte</literal></screen>
<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 a rule unexpectedly matches a device. For
example, a poorly-writen rule can match by both a SCSI disk (as desired)
and the corresponding SCSI generic device (incorrectly) by vendor.
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>Device 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 an 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>

26
chapter08/kernel.xml
View File

@ -24,8 +24,8 @@
<segtitle>&diskspace;</segtitle>
<seglistitem>
<seg>4.20 SBU</seg>
<seg>181 MB</seg>
<seg>2.4 SBU</seg>
<seg>344 MB</seg>
</seglistitem>
</segmentedlist>
@ -98,27 +98,13 @@
<screen><userinput>make</userinput></screen>
<para>If using kernel modules, an <filename>/etc/modprobe.conf</filename> file
may be needed. Information pertaining to modules and kernel configuration is
located in the kernel documentation in the <filename
<para>If using kernel modules, an <filename>/etc/modprobe.conf</filename>
file may be needed. Information pertaining to modules and kernel
configuration is located in <xref linkend="ch-scripts-udev"/> and in the
kernel documentation in the <filename
class="directory">linux-&linux-version;/Documentation</filename> directory.
Also, <filename>modprobe.conf(5)</filename> may be of interest.</para>
<para>Be very careful when reading other documentation relating to kernel
modules because it usually applies to 2.4.x kernels only. As far as we know,
kernel configuration issues specific to Hotplug and Udev are not documented.
The problem is that Udev will create a device node only if Hotplug or a
user-written script inserts the corresponding module into the kernel, and not
all modules are detectable by Hotplug. Note that statements like the one below
in the <filename>/etc/modprobe.conf</filename> file do not work with
Udev:</para>
<screen><literal>alias char-major-XXX some-module</literal></screen>
<para>Because of the complications with Hotplug, Udev, and modules, we
strongly recommend starting with a completely non-modular kernel
configuration, especially if this is the first time using Udev.</para>
<para>Install the modules, if the kernel configuration uses them:</para>
<screen><userinput>make modules_install</userinput></screen>

15
general.ent
View File

@ -1,6 +1,6 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ENTITY version "SVN-20060412">
<!ENTITY releasedate "April 12, 2006">
<!ENTITY version "SVN-20060413">
<!ENTITY releasedate "April 13, 2006">
<!ENTITY milestone "6.2">
<!ENTITY generic-version "development"> <!-- Use "development", "testing", or "x.y[-pre{x}]" -->
@ -52,15 +52,14 @@
<!ENTITY groff-version "1.18.1.1">
<!ENTITY grub-version "0.97">
<!ENTITY gzip-version "1.3.5">
<!ENTITY hotplug-version "2004_09_23">
<!ENTITY iana-etc-version "2.00">
<!ENTITY inetutils-version "1.4.2">
<!ENTITY iproute2-version "051007">
<!ENTITY iproute2-version "2.6.16-060323">
<!ENTITY kbd-version "1.12">
<!ENTITY less-version "394">
<!ENTITY lfs-bootscripts-version "20060321">
<!ENTITY lfs-bootscripts-version "udev_update-20060321">
<!ENTITY libtool-version "1.5.22">
<!ENTITY linux-version "2.6.12.5">
<!ENTITY linux-version "2.6.16.1">
<!ENTITY linux-dl-version "2.6">
<!ENTITY linux-libc-headers-version "2.6.12.0">
<!ENTITY m4-version "1.4.4">
@ -83,8 +82,8 @@
<!ENTITY tar-version "1.15.1">
<!ENTITY tcl-version "8.4.12">
<!ENTITY texinfo-version "4.8">
<!ENTITY udev-version "071">
<!ENTITY udev-config-file "udev-config-5.rules">
<!ENTITY udev-version "088">
<!ENTITY udev-config-file "udev-config-6.rules">
<!ENTITY util-linux-version "2.12r">
<!ENTITY vim-version "6.4">
<!ENTITY zlib-version "1.2.3">

2
patches.ent
View File

@ -30,7 +30,7 @@
<!ENTITY inetutils-gcc4_fixes-patch "inetutils-&inetutils-version;-gcc4_fixes-3.patch">
<!ENTITY inetutils-man_pages-patch "inetutils-&inetutils-version;-no_server_man_pages-1.patch">
<!ENTITY linux-utf8-patch "linux-&linux-version;-utf8_input-2.patch">
<!ENTITY linux-utf8-patch "linux-&linux-version;-utf8_input-1.patch">
<!ENTITY mktemp-tempfile-patch "mktemp-&mktemp-version;-add_tempfile-3.patch">