Index: final-preps/aboutlfs.xml
===================================================================
--- final-preps/aboutlfs.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/aboutlfs.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,43 @@
+<?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-final-preps-aboutlfs">
+  <?dbhtml filename="aboutlfs.html"?>
+
+  <title>About $LFS</title>
+
+  <para>Throughout this book, the environment variable <envar>LFS</envar> will
+  be used several times. It is paramount that this variable is always defined.
+  It should be set to the mount point chosen for the LFS partition.
+  Check that the <envar>LFS</envar> variable is set up properly with:</para>
+
+<screen><userinput>echo $LFS</userinput></screen>
+
+  <para>Make sure the output shows the path to the LFS partition's mount
+  point, which is <filename class="directory">/mnt/lfs</filename> if the
+  provided example was followed. If the output is incorrect, the
+  variable can be set with:</para>
+
+<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
+
+  <para>Having this variable set is beneficial in that commands such as
+  <command>install -d $LFS/tools</command> can be typed literally. The shell
+  will automatically replace <quote>$LFS</quote> with
+  <quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
+  processes the command line.</para>
+
+  <para>If you haven't created the <filename class="directory">/mnt/lfs</filename>
+  directory, do so at this time by issuing the following commands:</para>
+
+<screen><userinput>install -d $LFS</userinput></screen>
+
+  <para>Do not forget to check that <envar>$LFS</envar> is set whenever
+  you leave and reenter the current working environment (as when doing a
+  <quote>su</quote> to <systemitem class="username">root</systemitem> or
+  another user).</para>
+
+</sect1>
Index: final-preps/aboutsbus.xml
===================================================================
--- final-preps/aboutsbus.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/aboutsbus.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,57 @@
+<?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-final-preps-aboutsbus">
+  <?dbhtml filename="aboutsbus.html"?>
+
+  <title>About SBUs</title>
+
+  <para>TO BE REWRITTEN</para>
+
+  <!--
+  <para>Many people would like to know beforehand approximately how long
+  it takes to compile and install each package. Because Linux From
+  Scratch can be built on many different systems, it is impossible to
+  provide accurate time estimates.  The biggest package (Glibc) will
+  take approximately 20 minutes on the fastest systems, but could take
+  up to three days on slower systems! Instead of providing actual times,
+  the Static Build Unit (SBU) measure will be
+  used instead.</para>
+
+  <para>The SBU measure works as follows. The first package to be compiled
+  from this book is the statically-linked Binutils in <xref
+  linkend="chapter-temporary-tools"/>.  The time it takes to compile
+  this package is what will be referred to as the Static Build Unit
+  or SBU. All other compile times will be expressed relative to this
+  time.</para>
+
+  <para>For example, consider a package whose compilation time is 4.5
+  SBUs. This means that if a system took 10 minutes to compile and
+  install the static Binutils, it will take
+  <emphasis>approximately</emphasis> 45 minutes to build this example
+  package. Fortunately, most build times are shorter than the one
+  for Binutils.</para>
+
+  <para>Please note that if the system compiler on the host is GCC-2.x based, the
+  SBUs listed may be somewhat understated. This is because the SBU is
+  based on the very first package, compiled with the old GCC, while the
+  rest of the system is compiled with the newer GCC-&gcc-version; (which is
+  known to be approximately 30 percent slower). SBUs are also not
+  highly accurate for Symmetric Multi-Processor (SMP)-based machines.</para>
+
+  <para>In general, SBUs are not entirely accurate because they depend on many
+  factors, including the host system's version of GCC. Note that on Symmetric
+  Multi-Processor (SMP)-based machines, SBUs are even less accurate.  They are
+  provided here to give an estimate of how long it might take to install a
+  package, but the numbers can vary by as much as dozens of minutes in some
+  cases.</para>
+
+  <para>To view actual timings for a number of specific machines, we recommend
+  <ulink url="&lfs-root;~bdubbs/"/>.</para>
+  -->
+
+</sect1>
Index: final-preps/abouttestsuites.xml
===================================================================
--- final-preps/abouttestsuites.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/abouttestsuites.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,56 @@
+<?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-final-preps-abouttestsuites">
+  <?dbhtml filename="abouttestsuites.html"?>
+
+  <title>About the Test Suites</title>
+
+  <para>TO BE REWRITTEN (and maybe moved to final-system chapter)</para>
+
+  <para>Most packages provide a test suite. Running the test suite for a
+  newly built package is a good idea because it can provide a <quote>sanity
+  check</quote> indicating that everything compiled correctly. A test suite
+  that passes its set of checks usually proves that the package is
+  functioning as the developer intended. It does not, however, guarantee
+  that the package is totally bug free.</para>
+
+  <para>Some test suites are more important than others. For example,
+  the test suites for the core toolchain packages&mdash;GCC, Binutils, and
+  Glibc&mdash;are of the utmost importance due to their central role in a
+  properly functioning system. The test suites for GCC and Glibc can
+  take a very long time to complete, especially on slower hardware, but
+  are strongly recommended.</para>
+
+  <note>
+    <para>Experience has shown that there is little to be gained
+    from running the test suites in <xref
+    linkend="chapter-temporary-tools"/>. There can be no escaping the fact
+    that the host system always exerts some influence on the tests in that
+    chapter, often causing inexplicable failures. Because the tools built
+    in <xref linkend="chapter-temporary-tools"/> are temporary and
+    eventually discarded, we do not recommend running the test suites in
+    <xref linkend="chapter-temporary-tools"/> for the average reader. The
+    instructions for running those test suites are provided for the
+    benefit of testers and developers, but they are strictly
+    optional.</para>
+  </note>
+
+  <para>A common issue with running the test suites for Binutils and GCC
+  is running out of pseudo terminals (PTYs). This can result in a high
+  number of failing tests. This may happen for several reasons, but the
+  most likely cause is that the host system does not have the
+  <systemitem class="filesystem">devpts</systemitem> file system set up
+  correctly. This issue is discussed in greater detail in <xref
+  linkend="chapter-temporary-tools"/>.</para>
+
+  <para>Sometimes package test suites will fail, but for reasons which the
+  developers are aware of and have deemed non-critical. Consult the logs located
+  at <ulink url="&test-results;"/> to verify whether or not these failures are
+  expected. This site is valid for all tests throughout this book.</para>
+
+</sect1>
Index: final-preps/addinguser.xml
===================================================================
--- final-preps/addinguser.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/addinguser.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,107 @@
+<?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-final-preps-addinguser">
+  <?dbhtml filename="addinguser.html"?>
+
+  <title>Adding the LFS User</title>
+
+  <para>When logged in as user <systemitem class="username">root</systemitem>,
+  making a single mistake can damage or destroy a system. Therefore, we
+  recommend building the packages as an unprivileged user.
+  You could use your own user name, but to make it easier to set up a clean
+  work environment, create a new user called <systemitem
+  class="username">lfs</systemitem> as a member of a new group (also named
+  <systemitem class="groupname">lfs</systemitem>) and use this user during
+  the installation process. As <systemitem class="username">root</systemitem>,
+  issue the following commands to add the new user:</para>
+
+<screen><userinput>groupadd lfs
+useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
+
+  <variablelist>
+    <title>The meaning of the command line options:</title>
+
+    <varlistentry>
+      <term><parameter>-s /bin/bash</parameter></term>
+      <listitem>
+        <para>This makes <command>bash</command> the default shell for
+        user <systemitem class="username">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-g lfs</parameter></term>
+      <listitem>
+        <para>This option adds user <systemitem class="username">lfs</systemitem>
+        to group <systemitem class="groupname">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-m</parameter></term>
+      <listitem>
+        <para>This creates a home directory for <systemitem
+        class="username">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-k /dev/null</parameter></term>
+      <listitem>
+        <para>This parameter prevents possible copying of files from a skeleton
+        directory (default is <filename class="directory">/etc/skel</filename>)
+        by changing the input location to the special null device.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>lfs</parameter></term>
+      <listitem>
+        <para>This is the actual name for the created group and user.</para>
+      </listitem>
+    </varlistentry>
+
+  </variablelist>
+
+  <para>To log in as <systemitem class="username">lfs</systemitem> (as
+  opposed to switching to user <systemitem class="username">lfs</systemitem>
+  when logged in as <systemitem class="username">root</systemitem>, which
+  does not require the <systemitem class="username">lfs</systemitem> user
+  to have a password), give <systemitem class="username">lfs</systemitem>
+  a password:</para>
+
+<screen><userinput>passwd lfs</userinput></screen>
+
+  <para>Grant <systemitem class="username">lfs</systemitem> full access to
+  <filename class="directory">$LFS</filename> and <filename
+  class="directory">$LFS/tools</filename> by making <systemitem
+  class="username">lfs</systemitem> the directories owner:</para>
+
+<screen><userinput>chown lfs $LFS
+chown lfs $LFS/tools</userinput></screen>
+
+  <para>If a separate working directory was created as suggested, we will
+  show you how to create the directory and give user <systemitem
+  class="username">lfs</systemitem> ownership of this directory:</para>
+
+<screen><userinput>install -d $LFS/sources
+chown lfs $LFS/sources</userinput></screen>
+
+  <para>Next, login as user <systemitem class="username">lfs</systemitem>.
+  This can be done via a virtual console, through a display manager, or
+  with the following substitute user command:</para>
+
+<screen><userinput>su - lfs</userinput></screen>
+
+  <para>The <quote><parameter>-</parameter></quote> instructs
+  <command>su</command> to start a login shell as opposed to a non-login
+  shell. The difference between these two types of shells can be found
+  in detail in <filename>bash(1)</filename> and <command>info
+  bash</command>.</para>
+
+</sect1>
Index: final-preps/chapter.xml
===================================================================
--- final-preps/chapter.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/chapter.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE chapter 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;
+]>
+
+<chapter id="chapter-final-preps" xreflabel="Final Preparations">
+  <?dbhtml dir="final-preps"?>
+  <?dbhtml filename="chapter.html"?>
+
+  <title>Final Preparations</title>
+
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingcrossdir.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
+
+</chapter>
Index: final-preps/creatingcrossdir.xml
===================================================================
--- final-preps/creatingcrossdir.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/creatingcrossdir.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,45 @@
+<?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-final-preps-creatingcrossdir">
+  <?dbhtml filename="creatingcrossdir.html"?>
+
+  <title>Creating the $HOME/cross-tools Directory</title>
+
+  <para>All programs compiled in <xref linkend="chapter-cross-tools"/> will
+  be installed under <filename class="directory">$HOME/cross-tools</filename>
+  to keep them separate from the host programs. The programs compiled here are
+  cross tools and will not be a part of the final LFS system. By keeping these
+  programs in a separate directory, they can easily be discarded later after
+  their use.</para>
+
+  <para>Create the required directory by running the following as
+  the <systemitem class="username">lfs</systemitem> user:</para>
+
+<screen><userinput>install -d $HOME/cross-tools</userinput></screen>
+
+  <para>The next step is to create a <filename
+  class="symlink">/cross-tools</filename> symlink on the host system.
+  This will point to the newly-created directory in your home directory.
+  Since normal users will not have permissions to write to the root tree,
+  we need to exit the <command>su</command> and run the symlink command as
+  <systemitem class="username">root</systemitem>:</para>
+
+<screen><userinput>exit
+LFSHOME=`su - lfs -c 'echo $HOME'`
+ln -s $LFSHOME/cross-tools /
+unset LFSHOME
+su - lfs</userinput></screen>
+
+  <para>TO BE REWRITTEN - The created symlink enables the toolchain to be
+  compiled so that
+  it always refers to <filename class="directory">/cross-tools</filename>,
+  meaning that the compiler, assembler, and linker will work both in
+  this chapter and this host architecture and in the next (when we are
+  <quote>chrooted</quote> to the LFS partition).</para>
+
+</sect1>
Index: final-preps/creatingtoolsdir.xml
===================================================================
--- final-preps/creatingtoolsdir.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/creatingtoolsdir.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,50 @@
+<?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-final-preps-creatingtoolsdir">
+  <?dbhtml filename="creatingtoolsdir.html"?>
+
+  <title>Creating the $LFS/tools Directory</title>
+
+  <para>All programs compiled in <xref linkend="chapter-temporary-tools"/>
+  will be installed under <filename class="directory">$LFS/tools</filename>
+  to keep them separate from the programs compiled in <xref
+  linkend="chapter-building-system"/>. The programs compiled here are
+  temporary tools and will not be a part of the final LFS system. By keeping
+  these programs in a separate directory, they can easily be discarded later
+  after their use. This also prevents these programs from ending up in the
+  host production directories (easy to do by accident in <xref
+  linkend="chapter-temporary-tools"/>).</para>
+
+  <para>Create the required directory by running the following as
+  <systemitem class="username">root</systemitem>:</para>
+
+<screen><userinput>install -d $LFS/tools</userinput></screen>
+
+  <para>The next step is to create a <filename class="symlink">/tools</filename>
+  symlink on the host system. This will point to the newly-created directory
+  on the LFS partition. Run this command as <systemitem
+  class="username">root</systemitem> as well:</para>
+
+<screen><userinput>ln -s $LFS/tools /</userinput></screen>
+
+  <note>
+    <para>The above command is correct. The <command>ln</command> command
+    has a few syntactic variations, so be sure to check <command>info
+    coreutils ln</command> and <filename>ln(1)</filename> before reporting
+    what you may think is an error.</para>
+  </note>
+
+  <para>TO BE REWRiTTEN - The created symlink enables the toolchain to be
+  compiled so that
+  it always refers to <filename class="directory">/tools</filename>,
+  meaning that the compiler, assembler, and linker will work both in
+  this chapter (when we are still using some tools from the host) and in
+  the next (when we are <quote>chrooted</quote> to the LFS
+  partition).</para>
+
+</sect1>
Index: final-preps/settingenviron.xml
===================================================================
--- final-preps/settingenviron.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
+++ final-preps/settingenviron.xml	(revision bf8c11fb096060737d31a21fba001b2722737b95)
@@ -0,0 +1,94 @@
+<?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-final-preps-settingenviron">
+  <?dbhtml filename="settingenvironment.html"?>
+
+  <title>Setting Up the Environment</title>
+
+  <para>Set up a good working environment by creating two new startup
+  files for the <command>bash</command> shell. While logged in as user
+  <systemitem class="username">lfs</systemitem>, issue the following
+  command to create a new <filename>.bash_profile</filename>:</para>
+
+<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
+<literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal>
+EOF</userinput></screen>
+
+  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
+  the initial shell is usually a <emphasis>login</emphasis> shell which
+  reads the <filename>/etc/profile</filename> of the host (probably
+  containing some settings and environment variables) and then
+  <filename>.bash_profile</filename>. The
+  <command>exec env -i.../bin/bash</command> command in the
+  <filename>.bash_profile</filename> file replaces the running shell with
+  a new one with a completely empty environment, except for the
+  <envar>HOME</envar>, <envar>TERM</envar>, and <envar>PS1</envar> variables.
+  This ensures that no unwanted and potentially hazardous environment
+  variables from the host system leak into the build environment. The
+  technique used here achieves the goal of ensuring a clean environment.</para>
+
+  <para>The new instance of the shell is a <emphasis>non-login</emphasis>
+  shell, which does not read the <filename>/etc/profile</filename> or
+  <filename>.bash_profile</filename> files, but rather reads the
+  <filename>.bashrc</filename> file instead. Create the
+  <filename>.bashrc</filename> file now:</para>
+
+<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
+<literal>set +h
+umask 022
+LFS=/mnt/lfs
+LC_ALL=POSIX
+PATH=/cross-tools/bin:/bin:/usr/bin
+export LFS LC_ALL PATH</literal>
+EOF</userinput></screen>
+
+  <para>The <command>set +h</command> command turns off
+  <command>bash</command>'s hash function. Hashing is ordinarily a useful
+  feature&mdash;<command>bash</command> uses a hash table to remember the
+  full path of executable files to avoid searching the <envar>PATH</envar>
+  time and again to find the same executable. However, the new tools should
+  be used as soon as they are installed. By switching off the hash function,
+  the shell will always search the <envar>PATH</envar> when a program is to
+  be run. As such, the shell will find the newly compiled tools in
+  <filename class="directory">$LFS/tools</filename> as soon as they are
+  available without remembering a previous version of the same program in a
+  different location.</para>
+
+  <para>Setting the user file-creation mask (umask) to 022 ensures that
+  newly created files and directories are only writable by their owner,
+  but are readable and executable by anyone (assuming default modes are
+  used by the open(2) system call, new files will end up with permission
+  mode 644 and directories with mode 755).</para>
+
+  <para>The <envar>LFS</envar> variable should be set to the
+  chosen mount point.</para>
+
+  <para>TO BE REWRITTEN - The <envar>LC_ALL</envar> variable controls
+  the localization of
+  certain programs, making their messages follow the conventions of a
+  specified country.  If the host system uses a version of Glibc older
+  than 2.2.4, having <envar>LC_ALL</envar> set to something other than
+  <quote>POSIX</quote> or <quote>C</quote> (during this chapter) may cause
+  issues if you exit the chroot environment and wish to return later.
+  Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote>
+  (the two are equivalent) ensures that everything will work as expected in
+  the chroot environment.</para>
+
+  <para>By putting <filename class="directory">/tools/bin</filename> ahead
+  of the standard <envar>PATH</envar>, all the programs installed in
+  <xref linkend="chapter-temp-system"/> are picked up by the shell
+  immediately after their installation. This, combined with turning off
+  hashing, limits the risk that old programs are used from the host when
+  the same programs are available in the temporary system.</para>
+
+  <para>Finally, to have the environment fully prepared for building the
+  temporary tools, source the just-created user profile:</para>
+
+<screen><userinput>source ~/.bash_profile</userinput></screen>
+
+</sect1>
