Trunk is now identical to Testing

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

11 files changed, 917 insertions, 19 deletions

diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml
index 171330018..71d3a353f 100644
--- a/chapter07/bootscripts.xml
+++ b/chapter07/bootscripts.xml
@@ -3,13 +3,14 @@
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
-<sect1 id="ch-scripts-bootscripts" xreflabel="Bootscripts" role="wrap">
+<sect1 id="ch-scripts-bootscripts" role="wrap">
 <title>LFS-Bootscripts-&lfs-bootscripts-version;</title>
 <?dbhtml filename="bootscripts.html"?>
 
 <indexterm zone="ch-scripts-bootscripts"><primary sortas="a-Bootscripts">Bootscripts</primary></indexterm>
 
 <sect2 role="package"><title/>
+<para>The LFS-Bootscripts package contains a set of bootscripts.</para>
 
 <segmentedlist>
 <segtitle>&buildtime;</segtitle>
@@ -17,22 +18,220 @@
 <seglistitem><seg>0.1 SBU</seg><seg>0.3 MB</seg></seglistitem>
 </segmentedlist>
 
+<segmentedlist>
+<segtitle>LFS-Bootscripts installation depends on</segtitle>
+<seglistitem><seg>Bash and Coreutils</seg></seglistitem>
+</segmentedlist>
 </sect2>
 
 <sect2 role="installation">
 <title>Installation of LFS-Bootscripts</title>
 
-<para>Installation of the bootscripts is very simple:</para>
+<para>Install the package:</para>
 
 <screen><userinput>make install</userinput></screen>
 
 </sect2>
 
-
 <sect2 id="contents-bootscripts" role="content"><title>Contents of LFS-bootscripts</title>
 
-<para>See testing</para>
+<segmentedlist>
+<segtitle>Installed scripts</segtitle>
+<seglistitem><seg>checkfs, cleanfs, console, functions, halt, ifdown, ifup,
+localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals, setclock, static, 
+swap, sysklogd, template, and udev</seg></seglistitem>
+</segmentedlist>
+
+<variablelist><bridgehead renderas="sect3">Short Descriptions</bridgehead>
+<?dbfo list-presentation="list"?>
+
+<varlistentry id="checkfs-bootscripts">
+<term><command>checkfs</command></term>
+<listitem>
+<para>Checks the file systems before they are mounted (with the exception of journal
+and network based file systems)</para>
+<indexterm zone="ch-scripts-bootscripts checkfs-bootscripts"><primary sortas="d-checkfs">checkfs</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="cleanfs-bootscripts">
+<term><command>cleanfs</command></term>
+<listitem>
+<para>Removes files that should not be
+preserved between reboots, such as those in <filename class="directory">/var/run/</filename> and
+<filename class="directory">/var/lock/</filename>; it re-creates <filename>/var/run/utmp</filename>
+and removes the possibly present <filename>/etc/nologin</filename>,
+<filename>/fastboot</filename>, and <filename>/forcefsck</filename> files</para>
+<indexterm zone="ch-scripts-bootscripts cleanfs-bootscripts"><primary sortas="d-cleanfs">cleanfs</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="console-bootscripts">
+<term><command>console</command></term>
+<listitem>
+<para>Loads the keymap table specified as proper for the keyboard
+layout; it also sets the screen font</para>
+<indexterm zone="ch-scripts-bootscripts console-bootscripts"><primary sortas="d-console">console</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="functions-bootscripts">
+<term><command>functions</command></term>
+<listitem>
+<para>Contains functions shared among different scripts, such as error
+and status checking</para>
+<indexterm zone="ch-scripts-bootscripts functions-bootscripts"><primary sortas="d-functions">functions</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="halt-bootscripts">
+<term><command>halt</command></term>
+<listitem>
+<para>Halts the system</para>
+<indexterm zone="ch-scripts-bootscripts halt-bootscripts"><primary sortas="d-halt">halt</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="hotplug-bootscripts">
+<term><command>hotplug</command></term>
+<listitem>
+<para>Load 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>
+<para>Assists the network script with network devices</para>
+<indexterm zone="ch-scripts-bootscripts ifdown-bootscripts"><primary sortas="d-ifdown">ifdown</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="ifup-bootscripts">
+<term><command>ifup</command></term>
+<listitem>
+<para>Assists the network script with network devices</para>
+<indexterm zone="ch-scripts-bootscripts ifup-bootscripts"><primary sortas="d-ifup">ifup</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="localnet-bootscripts">
+<term><command>localnet</command></term>
+<listitem>
+<para>Sets up the system's hostname and local loopback device</para>
+<indexterm zone="ch-scripts-bootscripts localnet-bootscripts"><primary sortas="d-localnet">localnet</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="mountfs-bootscripts">
+<term><command>mountfs</command></term>
+<listitem>
+<para>Mounts all file systems, except ones that are marked
+<emphasis>noauto</emphasis> or are network based</para>
+<indexterm zone="ch-scripts-bootscripts mountfs-bootscripts"><primary sortas="d-mountfs">mountfs</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="mountkernfs-bootscripts">
+<term><command>mountkernfs</command></term>
+<listitem>
+<para>Is used to mount kernel-provided file systems, such as
+<systemitem class="filesystem">proc</systemitem></para>
+<indexterm zone="ch-scripts-bootscripts mountkernfs-bootscripts"><primary sortas="d-mountkernfs">mountkernfs</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="network-bootscripts">
+<term><command>network</command></term>
+<listitem>
+<para>Sets up network interfaces, such as network cards, and sets up
+the default gateway (where applicable)</para>
+<indexterm zone="ch-scripts-bootscripts network-bootscripts"><primary sortas="d-network">network</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="rc-bootscripts">
+<term><command>rc</command></term>
+<listitem>
+<para>The master run-level control script; it is responsible for
+running all other scripts one-by-one, in a sequence determined by
+the name of the symbolic links being processed</para>
+<indexterm zone="ch-scripts-bootscripts rc-bootscripts"><primary sortas="d-rc">rc</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="reboot-bootscripts">
+<term><command>reboot</command></term>
+<listitem>
+<para>Reboots the system</para>
+<indexterm zone="ch-scripts-bootscripts reboot-bootscripts"><primary sortas="d-reboot">reboot</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="sendsignals-bootscripts">
+<term><command>sendsignals</command></term>
+<listitem>
+<para>Makes sure every process is terminated before the system reboots
+or halts</para>
+<indexterm zone="ch-scripts-bootscripts sendsignals-bootscripts"><primary sortas="d-sendsignals">sendsignals</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="setclock-bootscripts">
+<term><command>setclock</command></term>
+<listitem>
+<para>Resets the kernel clock to local time in case the hardware clock
+is not set to UTC time</para>
+<indexterm zone="ch-scripts-bootscripts setclock-bootscripts"><primary sortas="d-setclock">setclock</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="static-bootscripts">
+<term><command>static</command></term>
+<listitem>
+<para>Provides the functionality needed to assign a static Internet
+Protocol (IP) address to a network interface</para>
+<indexterm zone="ch-scripts-bootscripts static-bootscripts"><primary sortas="d-static">static</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="swap-bootscripts">
+<term><command>swap</command></term>
+<listitem>
+<para>Enables and disables swap files and partitions</para>
+<indexterm zone="ch-scripts-bootscripts swap-bootscripts"><primary sortas="d-swap">swap</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="syslog-ng-bootscripts">
+<term><command>syslog-ng</command></term>
+<listitem>
+<para>Starts and stops the system and kernel log daemons</para>
+<indexterm zone="ch-scripts-bootscripts syslog-ng-bootscripts"><primary sortas="d-syslog-ng">syslog-ng</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="template-bootscripts">
+<term><command>template</command></term>
+<listitem>
+<para>A template to create custom bootscripts for other
+daemons</para>
+<indexterm zone="ch-scripts-bootscripts template-bootscripts"><primary sortas="d-template">template</primary></indexterm>
+</listitem>
+</varlistentry>
+
+<varlistentry id="udev-bootscripts">
+<term><command>udev</command></term>
+<listitem>
+<para>Sets up udev and create the devices nodes in <filename
+class="directory">/dev</filename></para>
+<indexterm zone="ch-scripts-bootscripts udev-bootscripts"><primary sortas="d-udev">udev</primary></indexterm>
+</listitem>
+</varlistentry>
+</variablelist>
 
 </sect2>
 
 </sect1>
+
diff --git a/chapter07/console.xml b/chapter07/console.xml
index 3e5bfdc22..8e59c4bc9 100644
--- a/chapter07/console.xml
+++ b/chapter07/console.xml
@@ -7,15 +7,66 @@
 <title>Configuring the Linux Console</title>
 <?dbhtml filename="console.html"?>
 
-<para>Create the configuration file:</para>
+<indexterm zone="ch-scripts-console">
+<primary sortas="d-console">console</primary>
+<secondary>configuring</secondary></indexterm>
+
+<para>This section discusses how to configure the
+<command>console</command> initscript that sets up the keyboard map
+and the console font. If non-ASCII characters (British pound and Euro
+character are examples of non-ASCII characters) will not be used and
+the keyboard is a U.S. one, skip this section. Without the
+configuration file, the console initscript will do nothing.</para>
+
+<para>The <command>console</command> script uses the
+<filename>/etc/sysconfig/console</filename> as a configuration file.
+Decide which keymap and screen font will be used. The
+language-specific HOWTO can help with this. A pre-made
+<filename>/etc/sysconfig/console</filename> file with known settings
+for several countries was installed with the LFS-Bootscripts package,
+so the relevant section can be uncommented if the country is
+supported. If still in doubt, look in the <filename
+class="directory">/usr/share/kbd</filename> directory for valid
+keymaps and screen fonts.  Read the loadkeys and setfont manual pages
+and determine the correct arguments for these programs. Once decided,
+create the configuration file with the following command:</para>
 
 <screen><userinput>cat &gt;/etc/sysconfig/console &lt;&lt;"EOF"
 <literal>KEYMAP="<replaceable>[arguments for loadkeys]</replaceable>"
 FONT="<replaceable>[arguments for setfont]</replaceable>"</literal>
 EOF</userinput></screen>
 
-<para>If you see that keycode 14 is Backspace and not Delete,
-create the following keymap snippet to fix this issue:</para>
+<para>For example, for Spanish users who also want to use the Euro
+character (accessible by pressing AltGr+E), the following settings are
+correct:</para>
+
+<screen><userinput>cat &gt;/etc/sysconfig/console &lt;&lt;"EOF"
+<literal>KEYMAP="es euro2"
+FONT="lat9-16 -u iso01"</literal>
+EOF</userinput></screen>
+
+<note><para>The <envar>FONT</envar> line above is correct only for the ISO 8859-15
+character set. If using ISO 8859-1 and, therefore, a pound sign
+instead of Euro, the correct <envar>FONT</envar> line would be:</para>
+
+<screen><userinput>FONT="lat1-16"</userinput></screen></note>
+
+<para>If the <envar>KEYMAP</envar> or <envar>FONT</envar> variable is not set, the
+<command>console</command> initscript will not run the corresponding
+program.</para>
+
+<para>In some keymaps, the Backspace and Delete keys send characters
+different from ones in the default keymap built into the kernel. This
+confuses some applications.  For example,
+<application>Emacs</application> displays its help (instead of erasing
+the character before the cursor) when Backspace is pressed. To check
+if the keymap in use is effected (this works only for i386
+keymaps):</para>
+
+<screen><userinput>zgrep '\W14\W' <replaceable>[/path/to/your/keymap]</replaceable></userinput></screen>
+
+<para>If the keycode 14 is Backspace instead of Delete, create the
+following keymap snippet to fix this issue:</para>
 
 <screen><userinput>mkdir -p /etc/kbd &amp;&amp; cat &gt; /etc/kbd/bs-sends-del &lt;&lt;"EOF"
 <literal>                  keycode  14 = Delete Delete Delete Delete
@@ -27,12 +78,32 @@ create the following keymap snippet to fix this issue:</para>
 altgr control alt keycode 111 = Boot</literal>
 EOF</userinput></screen>
 
-<para>Then tell the <command>console</command> script to load this snippet
-after the main keymap:</para>
+<para>Tell the <command>console</command> script to load this
+snippet after the main keymap:</para>
 
 <screen><userinput>cat &gt;&gt;/etc/sysconfig/console &lt;&lt;"EOF"
 <literal>KEYMAP_CORRECTION="/etc/kbd/bs-sends-del"</literal>
 EOF</userinput></screen>
 
+<para>To compile the keymap directly into the kernel instead of
+setting it every time from the <command>console</command> bootscript,
+follow the instructions given in <xref linkend="ch-bootable-kernel" role="."/>
+Doing this ensures that the keyboard will always work as expected,
+even when booting into maintenance mode (by passing
+<parameter>init=/bin/sh</parameter> to the kernel), because the
+<command>console</command> bootscript will not be run in that
+situation. Additionally, the kernel will not set the screen font
+automatically. This should not pose many problems because ASCII characters
+will be handled correctly, and it is unlikely that a user would need
+to rely on non-ASCII characters while in maintenance mode.</para>
+
+<para>Since the kernel will set up the keymap, it is possible to omit
+the <envar>KEYMAP</envar> variable from the
+<filename>/etc/sysconfig/console</filename> configuration file. It can
+also be left in place, if desired, without consequence.  Keeping it
+could be beneficial if running several different kernels where it is
+difficult to ensure that the keymap is compiled into every one of
+them.</para>
+
 </sect1>
 
diff --git a/chapter07/hostname.xml b/chapter07/hostname.xml
index 5b299f335..46c083a43 100644
--- a/chapter07/hostname.xml
+++ b/chapter07/hostname.xml
@@ -7,10 +7,22 @@
 <title>Configuring the localnet Script</title>
 <?dbhtml filename="hostname.html"?>
 
+<indexterm zone="ch-scripts-hostname">
+<primary sortas="d-localnet">localnet</primary>
+<secondary>configuring</secondary></indexterm>
+
+<para>Part of the localnet script is setting up the system's hostname. This
+needs to be configured in the <filename>/etc/sysconfig/network</filename>.</para>
 
 <para>Create the <filename>/etc/sysconfig/network</filename> file and enter a hostname by
 running:</para>
 
 <screen><userinput>echo "HOSTNAME=<replaceable>[lfs]</replaceable>" &gt; /etc/sysconfig/network</userinput></screen>
 
+<para><replaceable>[lfs]</replaceable> needs to be replaced with the
+name the computer is to be called. Do not enter the Fully Qualified
+Domain Name (FQDN) here. That information will be put in the
+<filename>/etc/hosts</filename> file later.</para>
+
 </sect1>
+
diff --git a/chapter07/hosts.xml b/chapter07/hosts.xml
index bc81d39e8..b2a77c0c0 100644
--- a/chapter07/hosts.xml
+++ b/chapter07/hosts.xml
@@ -7,8 +7,42 @@
 <title>Creating the /etc/hosts File</title>
 <?dbhtml filename="hosts.html"?>
 
-<para>If a network card is to be configured, create the 
-<filename>/etc/hosts</filename> file by running:</para>
+<indexterm zone="ch-scripts-hosts"><primary sortas="e-/etc/hosts">/etc/hosts</primary></indexterm>
+
+<indexterm zone="ch-scripts-hosts">
+<primary sortas="d-localnet">localnet</primary>
+<secondary>/etc/hosts</secondary></indexterm>
+
+<indexterm zone="ch-scripts-hosts">
+<primary sortas="d-network">network</primary>
+<secondary>/etc/hosts</secondary></indexterm>
+
+<para>If a network card is to be configured, decide on the IP-address,
+FQDN, and possible aliases for use in the
+<filename>/etc/hosts</filename> file. The syntax is:</para>
+
+<screen>&lt;IP address&gt; myhost.example.org aliases</screen>
+
+<para>Unless the computer is to be visible to the Internet (e.g.,
+there is a registered domain and a valid block of assigned IP
+addresses&mdash;most users do not have this), make sure that the IP
+address is in the private network IP address range. Valid ranges
+are:</para>
+
+<screen>	Class Networks
+	A     10.0.0.0
+	B     172.16.0.0 through 172.31.0.0
+	C     192.168.0.0 through 192.168.255.0</screen>
+
+<para>A valid IP address could be 192.168.1.1. A valid FQDN for this
+IP could be www.linuxfromscratch.org (not recommended because this is
+a valid registered domain address and could cause domain name server
+issues).</para>
+
+<para>Even if not using a network card, an FQDN is still required.
+This is necessary for certain programs to operate correctly.</para>
+
+<para>Create the  <filename>/etc/hosts</filename> file by running:</para>
 
 <screen><userinput>cat &gt; /etc/hosts &lt;&lt; "EOF"
 <literal># Begin /etc/hosts (network card version)
@@ -19,6 +53,12 @@
 # End /etc/hosts (network card version)</literal>
 EOF</userinput></screen>
 
+<para>The <replaceable>[192.168.1.1]</replaceable> and
+<replaceable>[&lt;HOSTNAME&gt;.example.org]</replaceable>
+values need to be changed for specific users or requirements (if
+assigned an IP address by a network/system administrator and the
+machine will be connected to an existing network).</para>
+
 <para>If a network card is not going to be configured, create the
 <filename>/etc/hosts</filename> file by running:</para>
 
@@ -31,3 +71,4 @@ EOF</userinput></screen>
 EOF</userinput></screen>
 
 </sect1>
+
diff --git a/chapter07/inputrc.xml b/chapter07/inputrc.xml
index 62fcb3173..200f9a31b 100644
--- a/chapter07/inputrc.xml
+++ b/chapter07/inputrc.xml
@@ -7,7 +7,45 @@
 <title>Creating the /etc/inputrc File</title>
 <?dbhtml filename="inputrc.html"?>
 
-<para>Create the /etc/inputrc file:</para>
+<indexterm zone="ch-scripts-inputrc"><primary sortas="e-/etc/inputrc">/etc/inputrc</primary></indexterm>
+
+<para>The <filename>/etc/inputrc</filename> file deals with mapping
+the keyboard for specific situations. This file is the start-up file
+used by <application>Readline</application>, the input-related
+library used by <application>Bash</application> and most other
+shells.</para>
+
+<para>For more information, see the bash info page, section
+<emphasis>Readline Init File</emphasis>. The readline info page is
+also a good source of information.</para>
+
+<para>Global values are set in <filename>/etc/inputrc</filename>.
+Personal user values are set in <filename>~/.inputrc</filename>. The
+<filename>~/.inputrc</filename> file will override the global settings
+file. A later page sets up Bash to use
+<filename>/etc/inputrc</filename> if there is no
+<filename>.inputrc</filename> for a user when
+<filename>/etc/profile</filename> is read (usually at login). To make
+the system use both, or to negate global keyboard handling, it is a
+good idea to place a default <filename>.inputrc</filename> into the
+<filename class="directory">/etc/skel</filename> directory for use
+with new users.</para>
+
+<para>Below is a base <filename>/etc/inputrc</filename>, along with
+comments to explain what the various options do. Note that comments
+cannot be on the same line as commands.</para>
+
+<para>To create the <filename>.inputrc</filename> in <filename
+class="directory">/etc/skel</filename> using the command below, change
+the command's output to <filename
+class="directory">/etc/skel/.inputrc</filename> and be sure to
+check/set permissions afterward. Copy that file to
+<filename>/etc/inputrc</filename> and the home directory of any user
+already existing on the system, including <emphasis>root</emphasis>,
+that needs a private version of the file. Be certain to use the
+<parameter>-p</parameter> parameter of <command>cp</command> to
+maintain permissions and be sure to change owner and group
+appropriately.</para>
 
 <screen><userinput>cat &gt; /etc/inputrc &lt;&lt; "EOF"
 <literal># Begin /etc/inputrc
@@ -56,3 +94,4 @@ set bell-style none
 EOF</userinput></screen>
 
 </sect1>
+
diff --git a/chapter07/introduction.xml b/chapter07/introduction.xml
index bfff7e7c7..b4c8ea547 100644
--- a/chapter07/introduction.xml
+++ b/chapter07/introduction.xml
@@ -7,6 +7,21 @@
 <title>Introduction</title>
 <?dbhtml filename="introduction.html"?>
 
-<para>See testing</para>
+<para>This chapter details how to install the bootscripts and set them up
+properly. Most of these scripts will work without modification, but a
+few require additional configuration files because they deal with
+hardware-dependent information.</para>
+
+<para>System-V style init scripts are employed in this book because they are
+widely used. For additional options, a hint detailing the BSD style
+init setup is available at
+<ulink
+url="http://www.linuxfromscratch.org/hints/downloads/files/bsd-init.txt"/>.
+Searching the LFS mailing lists for <quote>depinit</quote> will also offer
+additional choices.</para>
+
+<para>If using an alternate style of init scripts, skip this chapter
+and move on to <xref linkend="chapter-bootable"/>.</para>
 
 </sect1>
+
diff --git a/chapter07/network.xml b/chapter07/network.xml
index 3a86d1a20..304341033 100644
--- a/chapter07/network.xml
+++ b/chapter07/network.xml
@@ -7,12 +7,43 @@
 <title>Configuring the network Script</title>
 <?dbhtml filename="network.html"?>
 
+<indexterm zone="ch-scripts-network">
+<primary sortas="d-network">network</primary>
+<secondary>configuring</secondary></indexterm>
+
+<para>This section only applies if a network card is to be
+configured.</para>
+
+<para>If a network card will not be used, there is likely no need to
+create any configuration files relating to network cards. If that is
+the case, remove the <filename class="symlink">network</filename>
+symlinks from all run-level directories (<filename
+class="directory">/etc/rc.d/rc*.d</filename>).</para>
 
 <sect2>
 <title>Creating Network Interface Configuration Files</title>
 
-<para>The following command creates a sample <filename>ipv4</filename> file for the
-<filename>eth0</filename> device:</para>
+<!-- Edit Me -->
+<para>Which interfaces are brought up and down by the network script
+depends on the files and directories in the <filename
+class="directory">/etc/sysconfig/network-devices</filename> hierarchy.
+This directory should contain a directory for each interface to be configured,
+such as <filename>ifconfig.xyz</filename>, where <quote>xyz</quote> is a
+network interface name. Inside this directory would be files defining
+the attributes to this interface, such as its IP address(es), subnet
+masks, and so forth.</para>
+<!-- -->
+
+<para>If the <filename
+class="directory">/etc/sysconfig/network-devices</filename> directory
+is to be renamed or moved, make sure to edit the
+<filename>/etc/sysconfig/rc</filename> file and update the
+<quote>network_devices</quote> option by providing it with the new
+path.</para>
+
+<para>New files are created in this directory. The following
+command creates a sample <filename>ipv4</filename> file for the
+<emphasis>eth0</emphasis> device:</para>
 
 <screen><userinput>cd /etc/sysconfig/network-devices &amp;&amp;
 mkdir ifconfig.eth0 &amp;&amp;
@@ -25,12 +56,46 @@ PREFIX=24
 BROADCAST=192.168.1.255</literal>
 EOF</userinput></screen>
 
+<para>The values of these variables must be changed in every file to
+match the proper setup. If the <envar>ONBOOT</envar> variable is
+set to <quote>yes</quote> the network script will bring up the
+Network Interface Card (NIC) during booting of the system. If set
+to anything but <quote>yes</quote> the NIC will be ignored by the
+network script and not brought up.</para>
+
+<para>The <envar>SERVICE</envar> variable defines the method of
+obtaining the IP address. The LFS bootscripts have a modular IP
+assignment format, and creating additional files in the <filename
+class="directory">/etc/sysconfig/network-devices/services</filename>
+directory allows other IP assignment methods. This is commonly used
+for Dynamic Host Configuration Protocol (DHCP), which is addressed in the BLFS book.</para>
+
+<para>The <envar>GATEWAY</envar> variable should contain
+the default gateway IP address, if one is present. If not, then comment out
+the variable entirely.</para>
+
+<para>The <envar>PREFIX</envar> variable needs to contain the
+number of bits used in the subnet. Each octet in an IP address is 8
+bits. If the subnet's netmask is 255.255.255.0, then it is using the
+first three octets (24 bits) to specify the network number. If the
+netmask is 255.255.255.240, it would be using the first 28 bits.
+Prefixes longer than 24 bits are commonly used by DSL- and cable-based
+Internet Service Providers (ISPs).  In this example (PREFIX=24), the netmask
+is 255.255.255.0. Adjust according to the specific subnet.</para>
+
 </sect2>
 
 <sect2 id="resolv.conf">
 <title>Creating the /etc/resolv.conf File</title>
+<indexterm zone="resolv.conf"><primary sortas="e-/etc/resolv.conf">/etc/resolv.conf</primary></indexterm>
 
-<para>Create the file by running the following:</para>
+<para>If the system is going to be connected to the Internet, it will
+need some means of Domain Name Service (DNS) name resolution to
+resolve Internet domain names to IP addresses, and vice versa. This is
+best achieved by placing the IP address of the DNS server, available
+from the ISP or network administrator, into
+<filename>/etc/resolv.conf</filename>. Create the file by running the
+following:</para>
 
 <screen><userinput>cat &gt; /etc/resolv.conf &lt;&lt; "EOF"
 <literal># Begin /etc/resolv.conf
@@ -42,6 +107,14 @@ nameserver <replaceable>[IP address of your secondary nameserver]</replaceable>
 # End /etc/resolv.conf</literal>
 EOF</userinput></screen>
 
+<para>Replace <replaceable>[IP address of the
+nameserver]</replaceable> with the IP address of the DNS most
+appropriate for the setup. There will often be more than one entry
+(requirements demand secondary servers for fallback capability). If
+you only need or want one DNS server, remove the second
+<emphasis>nameserver</emphasis> line from the file. The IP address may
+also be a router on the local network.</para>
 </sect2>
 
 </sect1>
+
diff --git a/chapter07/profile.xml b/chapter07/profile.xml
index d60d64d67..fa1b1a232 100644
--- a/chapter07/profile.xml
+++ b/chapter07/profile.xml
@@ -7,8 +7,74 @@
 <title>The Bash Shell Startup Files</title>
 <?dbhtml filename="profile.html"?>
 
+<indexterm zone="ch-scripts-profile"><primary sortas="e-/etc/profile">/etc/profile</primary></indexterm>
 
-<para>Create the <filename>/etc/profile</filename> file:</para>
+<para>The shell program <command>/bin/bash</command> (hereafter
+referred to as <quote>the shell</quote>) uses a collection of startup
+files to help create an environment to run in. Each file has a
+specific use and may effect login and interactive environments
+differently. The files in the <filename
+class="directory">/etc</filename> directory provide global settings.
+If an equivalent file exists in the home directory, it may override
+the global settings.</para>
+
+<para>An interactive login shell is started after a successful login,
+using <command>/bin/login</command>, by reading the
+<filename>/etc/passwd</filename> file. An interactive non-login shell
+is started at the command-line (e.g.,
+<prompt>[prompt]$</prompt><command>/bin/bash</command>). A
+non-interactive shell is usually present when a shell script is
+running. It is non-interactive because it is processing a script and
+not waiting for user input between commands.</para>
+
+<para>For more information, see <command>info bash</command> - Nodes:
+Bash Startup Files and Interactive Shells.</para>
+
+<para>The files <filename>/etc/profile</filename> and
+<filename>~/.bash_profile</filename> are read when the shell is
+invoked as an interactive login shell.</para>
+
+<para>A base <filename>/etc/profile</filename> below sets some
+environment variables necessary for native language support. Setting
+them properly results in:</para>
+
+<itemizedlist>
+<listitem><para>The output of programs translated into the native
+language</para></listitem>
+<listitem><para>Correct classification of characters into letters,
+digits and other classes. This is necessary for Bash to properly
+accept non-ASCII characters in command lines in non-English
+locales</para></listitem>
+<listitem><para>The correct alphabetical sorting order for the
+country</para></listitem>
+<listitem><para>Appropriate default paper size</para></listitem>
+<listitem><para>Correct formatting of monetary, time, and date
+values</para></listitem>
+</itemizedlist>
+
+<para>This script also sets the <envar>INPUTRC</envar>
+environment variable that makes <application>Bash</application> and
+<application>Readline</application> use the
+<filename>/etc/inputrc</filename> file created earlier.</para>
+
+<para>Replace <replaceable>[ll]</replaceable> below with the
+two-letter code for the desired language (e.g., <quote>en</quote>) and
+<replaceable>[CC]</replaceable> with the two-letter code for the
+appropriate country (e.g., <quote>GB</quote>). It may also be
+necessary to specify (and this is actually the preferred form) the
+character encoding (e.g.  <quote>iso8859-1</quote>) after a dot (so
+that the result is <quote>en_GB.iso8859-1</quote>).  Issue the
+following command for more information:</para>
+
+<screen><userinput>man 3 setlocale</userinput></screen>
+
+<para>The list of all locales supported by Glibc can be obtained by running
+the following command:</para>
+
+<screen><userinput>locale -a</userinput></screen>
+
+<para>Once the proper locale settings have been determined, create the
+<filename>/etc/profile</filename> file:</para>
 
 <screen><userinput>cat &gt; /etc/profile &lt;&lt; "EOF"
 <literal># Begin /etc/profile
@@ -20,4 +86,19 @@ export INPUTRC=/etc/inputrc
 # End /etc/profile</literal>
 EOF</userinput></screen>
 
+<note><para>The <quote>C</quote> (default) and <quote>en_US</quote>
+(the recommended one for United States English users) locales are
+different.</para></note>
+
+<para>Setting the keyboard layout, screen font, and 
+locale-related environment variables are the only internationalization
+steps needed to support locales that use ordinary single-byte
+encodings and left-to-right writing direction. More complex cases
+(including UTF-8 based locales) require additional steps and
+additional patches because many applications tend to not work properly
+under such conditions.  These steps and patches are not included in
+the LFS book and such locales are not supported by LFS in any
+way.</para>
+
 </sect1>
+
diff --git a/chapter07/setclock.xml b/chapter07/setclock.xml
index d933eb59f..0527fac00 100644
--- a/chapter07/setclock.xml
+++ b/chapter07/setclock.xml
@@ -7,6 +7,36 @@
 <title>Configuring the setclock Script</title>
 <?dbhtml filename="setclock.html"?>
 
+<indexterm zone="ch-scripts-setclock">
+<primary sortas="d-setclock">setclock</primary>
+<secondary>configuring</secondary></indexterm>
+
+<para>The <command>setclock</command> script reads the time from the hardware clock,
+also known as BIOS or the Complementary Metal Oxide Semiconductor
+(CMOS) clock. If the hardware clock is set to UTC, this script will convert the hardware clock's time to
+the local time using the <filename>/etc/localtime</filename> file
+(which tells the <command>hwclock</command> program which timezone the
+user is in). There is no way to
+detect whether or not the hardware clock is set to UTC time, so this
+needs to be manually configured.</para>
+
+<para>If you cannot remember whether or not the hardware
+clock is set to UTC time, find out by running
+the <userinput>hwclock --localtime --show</userinput> command. This will tell
+what the current time is according to the hardware clock. If this time
+matches whatever your watch says, then the hardware clock is set to
+local time. If the output from <command>hwclock</command> is not local
+time, chances are it is set to UTC time. Verify this by adding or
+subtracting the proper amount of hours for the timezone to this
+<command>hwclock</command> time. For example, if you live in the MST
+timezone, which is also known as GMT -0700, add seven hours to the local
+time. Then, account for Daylight Savings Time, which requires
+subtracting an hour (or only add six in the first place) during the summer
+months.</para>
+
+<para>Change the value of the <envar>UTC</envar> variable below
+to a value of <parameter>0</parameter> (zero) if the hardware clock
+is <emphasis>not</emphasis> set to UTC time.</para>
 
 <para>Create a new file <filename>/etc/sysconfig/clock</filename> by running
 the following:</para>
@@ -19,4 +49,9 @@ UTC=1
 # End /etc/sysconfig/clock</literal>
 EOF</userinput></screen>
 
+<para>A good hint explaining how to deal with time on LFS is available
+at <ulink url="&hints-root;time.txt"/>. It explains issues such as
+time zones, UTC, and the <envar>TZ</envar> environment variable.</para>
+
 </sect1>
+
diff --git a/chapter07/udev.xml b/chapter07/udev.xml
index 73b90c419..51e001134 100644
--- a/chapter07/udev.xml
+++ b/chapter07/udev.xml
@@ -11,8 +11,235 @@
 <primary sortas="a-Udev">Udev</primary>
 <secondary>usage</secondary></indexterm>
 
+<para>In <xref linkend="chapter-building-system"/>, we installed the Udev
+package.  Before we go into the details regarding how this works,
+a brief history of previous methods of handling devices is in
+order.</para>
 
-<para>See testing</para>
+<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 class="filesystem">ramfs</systemitem> (a file system that
+resides entirely in memory and does not take up any disk space).
+Device nodes do not require much disk space, so the memory that is
+used in negligable.</para>
+
+<sect2>
+<title>History</title>
+
+<para>In February 2000, a new filesystem called <systemitem
+class="filesystem">devfs</systemitem> was merged into the 2.3.46
+kernel and was made available during the 2.4 series of
+stable kernels.  Although it was present in the kernel source itself,
+this method of creating devices dynamically never received
+overwhelming support from the core kernel developers.</para>
+
+<para>The main problem with the approach adopted by <systemitem
+class="filesystem">devfs</systemitem> was the way it handled
+device detection, creation, and naming. The latter issue, that of
+device node 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>
+
+<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 structure 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.  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 will
+happen when the module is loaded.  Once the <systemitem
+class="filesystem">sysfs</systemitem> filesystem is mounted (on
+<filename class="directory">/sys</filename>), the 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>
+
+<para>The <command>S10udev</command> initscript takes care of creating
+these device nodes when Linux is booted. This script starts with
+registering <command>/sbin/udev</command> as a hotplug event handler.
+Hotplug events (discussed below) should not be 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
+permissions of each and every device that <command>udevstart</command>
+creates are set using files from the <filename
+class="directory">/etc/udev.d/permissions.d/</filename> directory.
+These are numbered in a similar fashion to the LFS bootscripts.  If
+<command>udev</command> cannot find a permissions file for the device
+it is creating, it will default permissions to
+<emphasis>600</emphasis> and ownership to
+<emphasis>root:root</emphasis>.  The names 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.</para>
+
+<para>Once the above stage is complete, all devices that were already
+present and have compiled-in drivers will be available for use. What 
+about those devices that have modular drivers?</para>
+
+<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 find out the
+userspace program that handles the device's connection.  The
+<command>udev</command> initscript registered <command>udev</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>
+
+<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
+distrubtions 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 is starting up. This allows
+<command>udev</command> to detect the devices and create the
+appropriate device nodes.</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>
+</sect2>
+
+<sect2>
+<title>Handling Hotpluggable/Dynamic Devices</title>
+
+<para>When you plug in a device, such 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>.  If the driver for the
+just plugged in device is available as a module but currently unloaded,
+then attaching the device to the system will only cause the kernel's
+bus driver to generate a hotplug event that notifies userspace of the
+new device connection and it not being attached to a driver. In
+effect, nothing happens and the device itself is not usable
+yet.</para>
+
+<para>If building a system that has a lot of drivers compiled as
+modules rather than directly built into the kernel, using the
+<command>S05modules</command> may not be practical. The Hotplug
+package (see <ulink url="http://linux-hotplug.sourceforge.net/"/>) can
+be beneficial in these cases. When the Hotplug package is installed,
+it will respond to the aforementioned kernel's bus driver hotplug
+events. The Hotplug package will load the appropriate module and make
+this device available by creating the device node(s) for it.</para>
+</sect2>
+
+<sect2>
+<title>Problems with Creating Devices</title>
+
+<para>There are a few known problems when it comes to automatically creating
+devices nodes:</para>
+
+<para>1) A kernel driver may not export its data to <systemitem
+class="filesystem">sysfs</systemitem>.</para>
+   
+<para>This is most common with third party drivers from outside the
+kernel tree.  These drivers will not end up having their device nodes
+created.  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>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>
+
+<itemizedlist>
+
+<listitem><para>Adding the module names to
+<filename>/etc/sysconfig/modules</filename></para></listitem>
+<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>
+
+<screen><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \
+    snd-pcm-oss ; true</userinput></screen>
+
+<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>
+</itemizedlist>
+</sect2>
+
+<sect2>
+<title>Useful Reading</title>
+
+<para>Additional helpful documentation is available at the following
+sites:</para>
+
+<itemizedlist>
+<listitem><para remap="verbatim">A Userspace Implementation of devfs
+<ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"><phrase
+condition="pdf">http://www.kroah.com/linux/talks/ols_2003_udev_paper/
+Reprint-Kroah-Hartman-OLS2003.pdf</phrase></ulink></para></listitem>
+
+<listitem><para remap="verbatim">udev FAQ
+<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem>
+
+<listitem><para remap="verbatim">The Linux Kernel Driver Model
+<ulink url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"><phrase  
+condition="pdf">http://public.planetmirror.com/pub/lca/2003/proceedings/papers/
+Patrick_Mochel/Patrick_Mochel.pdf</phrase></ulink></para></listitem>
+</itemizedlist>
+</sect2>
 
 </sect1>
 
diff --git a/chapter07/usage.xml b/chapter07/usage.xml
index 918f981f7..5baede25b 100644
--- a/chapter07/usage.xml
+++ b/chapter07/usage.xml
@@ -7,7 +7,112 @@
 <title>How Do These Bootscripts Work?</title>
 <?dbhtml filename="usage.html"?>
 
+<indexterm zone="ch-scripts-usage">
+<primary sortas="a-Bootscripts">Bootscripts</primary>
+<secondary>usage</secondary></indexterm>
 
-<para>See testing</para>
+<para>Linux uses a special booting facility named SysVinit that is
+based on a concept of <emphasis>run-levels</emphasis>. It can be quite
+different from one system to another, so it cannot be assumed that
+because things worked in &lt;insert distro name&gt;, they should work
+the same in LFS too. LFS has its own way of doing things, but it
+respects generally accepted standards.</para>
+
+<para>SysVinit (which will be referred to as <quote>init</quote> from
+now on) works using a run-levels scheme. There are seven (from 0 to 6)
+run-levels (actually, there are more run-levels, but they are for
+special cases and are generally not used. The init man page describes
+those details), and each one of those corresponds to the actions the
+computer is supposed to perform when it starts up. The default
+run-level is 3. Here are the descriptions of the different run-levels
+as they are implemented:</para>
+
+<literallayout>0: halt the computer
+1: single-user mode
+2: multi-user mode without networking
+3: multi-user mode with networking
+4: reserved for customization, otherwise does the same as 3
+5: same as 4, it is usually used for GUI login (like X's <command>xdm</command> or KDE's <command>kdm</command>)
+6: reboot the computer</literallayout>
+
+<para>The command used to change run-levels is <command>init
+<replaceable>[runlevel]</replaceable></command>, where
+<replaceable>[runlevel]</replaceable> is the target run-level. For
+example, to reboot the computer, a user would issue the <command>init
+6</command> command.  The <command>reboot</command> command is an
+alias for it, as is the <command>halt</command> command an alias for
+<command>init 0</command>.</para>
+
+<para>There are a number of directories under <filename
+class="directory">/etc/rc.d</filename> that look like <filename
+class="directory">rc?.d</filename> (where ? is the number of the
+run-level) and <filename class="directory">rcsysinit.d</filename>, all
+containing a number of symbolic links. Some begin with a
+<emphasis>K</emphasis>, the others begin with an
+<emphasis>S</emphasis>, and all of them have two numbers following the
+initial letter. The K means to stop (kill) a service and the S means
+to start a service. The numbers determine the order in which the
+scripts are run, from 00 to 99&mdash;the lower the number the earlier it
+gets executed. When init switches to another run-level, the
+appropriate services get killed and others get started.</para>
+
+<para>The real scripts are in <filename
+class="directory">/etc/rc.d/init.d</filename>. They do the actual
+work, and the symlinks all point to them. Killing links and starting
+links point to the same script in <filename
+class="directory">/etc/rc.d/init.d</filename>. This is because the
+scripts can be called with different parameters like
+<parameter>start</parameter>, <parameter>stop</parameter>,
+<parameter>restart</parameter>, <parameter>reload</parameter>, and
+<parameter>status</parameter>. When a K link is encountered, the
+appropriate script is run with the <parameter>stop</parameter>
+argument. When an S link is encountered, the appropriate script is run
+with the <parameter>start</parameter> argument.</para>
+
+<para>There is one exception to this explanation. Links that start
+with an <emphasis>S</emphasis> in the <filename
+class="directory">rc0.d</filename> and <filename
+class="directory">rc6.d</filename> directories will not cause anything
+to be started. They will be called with the parameter
+<parameter>stop</parameter> to stop something. The logic behind this
+is that when a user is going to reboot or halt the system, nothing
+needs to be started.  The system only needs to be stopped.</para>
+
+<para>These are descriptions of what the arguments make the scripts
+do:</para>
+
+<variablelist>
+<varlistentry>
+<term><parameter>start</parameter></term>
+<listitem><para>The service is started.</para></listitem>
+</varlistentry>
+
+<varlistentry>
+<term><parameter>stop</parameter></term>
+<listitem><para>The service is stopped.</para></listitem>
+</varlistentry>
+
+<varlistentry>
+<term><parameter>restart</parameter></term>
+<listitem><para>The service is stopped and then started again.</para></listitem>
+</varlistentry>
+
+<varlistentry>
+<term><parameter>reload</parameter></term>
+<listitem><para>The configuration of the service is updated.
+This is used after the configuration file of a service was modified, when 
+the service does not need to be restarted.</para></listitem>
+</varlistentry>
+
+<varlistentry>
+<term><parameter>status</parameter></term>
+<listitem><para>Tells if the service is running and with which PIDs.</para></listitem>
+</varlistentry>
+</variablelist>
+
+<para>Feel free to modify the way the boot process works (after all,
+it is your own LFS system). The files given here are an example of how
+it can be done.</para>
 
 </sect1>
+