Shifting chapter contents, and moving preparational sections of chapter 5 to a separate chapter.

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

16 files changed, 827 insertions, 819 deletions

diff --git a/book.xml b/book.xml
index c8e2c9af8..3e95e95f8 100644
--- a/book.xml
+++ b/book.xml
@@ -11,11 +11,11 @@
 <part id="part1">
 <title>Part I - Introduction</title>
 &chapter01;
-&chapter02;
 </part>
 
 <part id="part2">
 <title>Part II - Preparing for the build</title>
+&chapter02;
 &chapter03;
 &chapter04;
 &chapter05;
diff --git a/chapter01/askforhelp.xml b/chapter01/askforhelp.xml
new file mode 100644
index 000000000..c4f3fa47f
--- /dev/null
+++ b/chapter01/askforhelp.xml
@@ -0,0 +1,103 @@
+<sect1 id="prepare-askforhelp">
+<title>How to ask for help</title>
+<?dbhtml filename="askforhelp.html" dir="chapter02"?>
+
+<para>If you encounter a problem while using this book, and your problem
+is not listed in the FAQ (<ulink url="&faq-root;"/>), you will find that
+most of the people on Internet Relay Chat (IRC) and on the mailing lists
+are willing to help you (see <xref linkend="ch-scatter-administrativa"/>.
+To assist us in diagnosing and solving your problem, include as much relevant
+information as possible in your request for help.</para>
+
+<sect2>
+<title>Things to mention</title>
+ 
+<para>Apart from a brief explanation of the problem you're having, the
+essential things to include in your request are:</para>
+
+<itemizedlist>
+<listitem><para>the version of the book you are using (being &version;),</para></listitem>
+<listitem><para>the host distribution and version you are using to create
+LFS from,</para></listitem>
+<listitem><para>the package or section giving you problems,</para></listitem>
+<listitem><para>the exact error message or symptom you are receiving,</para></listitem>
+<listitem><para>whether you have deviated from the book at all.</para></listitem>
+</itemizedlist>
+
+<para>(Note that saying that you've deviated from the book doesn't mean
+that we won't help you. After all, LFS is about choice. It'll just
+help us to see other possible causes of your problem.)</para>
+
+</sect2>
+
+<sect2>
+<title>Configure problems</title>
+
+<para>When something goes wrong during the stage where the configure script
+is run, look through the <filename>config.log</filename> file. This file
+may contain errors encountered during configure which weren't printed to
+the screen. Include those relevant lines if you decide to ask for
+help.</para>
+
+</sect2>
+
+<sect2>
+<title>Compile problems</title>
+
+<para>To help us find the cause of the problem, both screen output and
+the contents of various files are useful. The screen output from both
+the ./configure script and the make run can be useful. Don't blindly
+include the whole thing but on the other hand, don't include too little.
+As an example, here is some screen output from make:</para>
+
+<screen>gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
+-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" -DLIBDIR=\"/mnt/lfs/usr/lib\"
+-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
+-g -O2 -c getopt1.c
+gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o expand.o file.o
+function.o getopt.o implicit.o job.o main.o misc.o read.o remake.o rule.o
+signame.o variable.o vpath.o default.o remote-stub.o version.o opt1.o
+-lutil job.o: In function `load_too_high':
+/lfs/tmp/make-3.79.1/job.c:1565: undefined reference to `getloadavg'
+collect2: ld returned 1 exit status
+make[2]: *** [make] Error 1
+make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
+make[1]: *** [all-recursive] Error 1
+make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
+make: *** [all-recursive-am] Error 2</screen>
+
+<para>In this case, many people just include the bottom section where it
+says:</para>
+
+<screen>make [2]: *** [make] Error 1</screen>
+
+<para>and onwards. This isn't enough for us to diagnose the problem because it
+only tells us that <emphasis>something</emphasis> went wrong, not
+<emphasis>what</emphasis> went wrong. The whole section, as in the example
+above, is what should be included to be helpful, because it includes the
+command that was executed and the command's error message(s).</para>
+
+<para>An excellent article on asking for help on the Internet in general
+has been written by Eric S. Raymond. It is available online at <ulink
+url="http://catb.org/~esr/faqs/smart-questions.html"/>.
+Read and follow the hints in that document and you are much more likely
+to get a response to start with and also to get the help you actually
+need.</para>
+
+</sect2>
+
+<sect2>
+<title>Test suite problems</title>
+
+<para>Many packages provide a test suite which, depending on the importance
+of the package, we may encourage you to run. Sometimes packages will
+generate false or expected failures. If you encounter these, you can check
+the LFS Wiki page at <ulink url="&wiki-root;"/> to see whether we have
+already noted and investigated them. If we already know
+about them, then usually there is no need to be concerned.</para>
+
+</sect2>
+
+
+</sect1>
+
diff --git a/chapter01/chapter01.xml b/chapter01/chapter01.xml
index 20020fa3b..0782d3e5c 100644
--- a/chapter01/chapter01.xml
+++ b/chapter01/chapter01.xml
@@ -5,5 +5,6 @@
 &c1-how;
 &c1-changelog;
 &c1-resources;
+&c1-askforhelp;
 
 </chapter>
diff --git a/chapter01/contactinfo.xml b/chapter01/contactinfo.xml
index d88eadb63..0d8351e43 100644
--- a/chapter01/contactinfo.xml
+++ b/chapter01/contactinfo.xml
@@ -27,7 +27,7 @@ support channel is named #LFS-support.</para>
 </sect2>
 
 
-<sect2 id="ch-scatter-maillists" xreflabel="Chapter 1 - Mailing lists">
+<sect2 id="ch-scatter-maillists">
 <title>Mailing lists</title>
 
 <para>The <emphasis>linuxfromscratch.org</emphasis> server is hosting a number
diff --git a/chapter01/how.xml b/chapter01/how.xml
index c5fb2f96b..18bbfc3fc 100644
--- a/chapter01/how.xml
+++ b/chapter01/how.xml
@@ -9,62 +9,57 @@ programs like a compiler, linker and shell to build the new system. Normally
 all the required tools are available if you selected <quote>development</quote>
 as one of the options when you installed your distribution.</para>
 
-<para>In <xref linkend="chapter-making-space"/> you will first create a new Linux native
+<para>In <xref linkend="chapter-making-space"/> you will first create a new
 partition and file system, the place where your new LFS system will be compiled
-and installed. Then in <xref linkend="chapter-getting-materials"/> you download all the
-packages and patches required to build an LFS system, and store them on the new
-file system.</para>
+and installed. Then in <xref linkend="chapter-getting-materials"/> you download
+all the packages and patches needed to build an LFS system, and store them on
+the new file system. In <xref linkend="chapter-preparation"/> you set up a good
+environment to work in.</para>
 
-<para><xref linkend="chapter-temporary-tools"/> then discusses the installation of a number
-of packages that will form the basic development suite (or toolchain) which is
-used to build the actual system in <xref linkend="chapter-building-system"/>. Some of these
-packages are needed to resolve circular dependencies -- for example, to compile
-a compiler you need a compiler.</para>
+<para><xref linkend="chapter-temporary-tools"/> then discusses the installation
+of a number of packages that form the basic development suite used to build the
+actual system in <xref linkend="chapter-building-system"/>.</para>
 
-<para>The first thing to be done in <xref linkend="chapter-temporary-tools"/> is build a
-first pass of the toolchain, made up of Binutils and GCC. The programs from
-these packages will be linked statically in order for them to be usable
-independently of the host system. The second thing to do is build Glibc, the
-C library. Glibc will be compiled by the toolchain programs we just built in
-the first pass. The third thing to do is build a second pass of the toolchain.
-This time the toolchain will be dynamically linked against the newly built
-Glibc. The remaining <xref linkend="chapter-temporary-tools"/> packages are all built using
-this second pass toolchain and dynamically linked against the new
-host-independent Glibc. When this is done, the LFS installation process will no
-longer depend on the host distribution, with the exception of the running
-kernel.</para>
+<para>The first thing to be done in <xref linkend="chapter-temporary-tools"/>
+is build a first pass of the <emphasis>toolchain</emphasis>, consisting of
+Binutils and GCC. The programs from these packages will be linked statically in
+order for them to be usable independently of the host system (thus making it
+in theory possible to skip the second passes). The second thing to do is build
+Glibc, the C library. Glibc will be compiled by the just-built toolchain
+programs. The third thing to do is build a second pass of the toolchain, this
+time linking it dynamically against the newly built Glibc. The remaining <xref
+linkend="chapter-temporary-tools"/> packages are all built using this second
+pass toolchain and are dynamically linked against the new host-independent
+Glibc. When this is done, the LFS installation process will no longer depend on
+the host distribution, with the exception of the running kernel.</para>
 
 <para>You may be thinking that <quote>this seems like a lot of work, just to
 get away from my host distribution</quote>. Well, a full technical explanation
-is provided at the start of <xref linkend="chapter-temporary-tools"/>, including some notes
-on the differences between statically and dynamically linked programs.</para>
+is provided at the start of <xref linkend="chapter-temporary-tools"/>,
+including some notes on the differences between statically and dynamically
+linked programs.</para>
 
-<para>In <xref linkend="chapter-building-system"/> your real LFS system will be built. The
-chroot (change root) program is used to enter a virtual environment and start
-a new shell whose root directory will be set to the LFS partition. This is very
-similar to rebooting and instructing the kernel to mount the LFS partition as
-the root partition. The reason that you don't actually reboot, but instead
-chroot, is that creating a bootable system requires additional work which isn't
-necessary just yet. But the major advantage is that chrooting allows you to
-continue using the host while LFS is being built. While waiting for package
-compilation to complete, you can simply switch to a different VC (Virtual
-Console) or X desktop and continue using the computer as you normally
-would.</para>
+<para>In <xref linkend="chapter-building-system"/> your real LFS system will be
+built. The <command>chroot</command> (change root) program is used to enter a
+virtual environment and start a new shell whose root directory will be set to
+the LFS partition. This is very similar to rebooting and instructing the kernel
+to mount the LFS partition as the root partition. The reason that you don't
+actually reboot, but instead chroot, is that creating a bootable system
+requires additional work which isn't necessary just yet. But the major
+advantage is that chrooting allows you to continue using the host while LFS is
+being built. While waiting for package compilation to complete, you can simply
+switch to a different VC (Virtual Console) or X desktop and continue using the
+computer as you normally would.</para>
 
 <para>To finish the installation, the bootscripts are set up in
 <xref linkend="chapter-bootscripts"/>, the kernel and bootloader are set up in
-<xref linkend="chapter-mixture"/>, and <xref linkend="chapter-finalizing"/> contains some
-pointers to help you after you finish the book. Then, finally, you're ready to
-reboot your computer into your new LFS system.</para>
+<xref linkend="chapter-mixture"/>, and <xref linkend="chapter-finalizing"/>
+contains some pointers to help you after you finish the book. Then, finally,
+you're ready to reboot your computer into your new LFS system.</para>
 
-<para>This is the process in a nutshell. Detailed information on the steps you 
-will take are discussed in the chapters and package descriptions as you 
-progress through them. If something isn't completely clear now, don't worry, 
-everything will fall into place soon.</para>
-
-<para>Please read <xref linkend="chapter-preparation"/> carefully as it explains a few
-important things you should be aware of before you begin to work through
-<xref linkend="chapter-temporary-tools"/> and beyond.</para>
+<para>This is the process in a nutshell. Detailed information on all the steps
+taken is given in the chapters and sections as you progress through them. If
+something isn't completely clear now, don't worry, everything will fall into
+place soon.</para>
 
 </sect1>
-
diff --git a/chapter02/aboutdependencies.xml b/chapter02/aboutdependencies.xml
deleted file mode 100644
index 065f9a864..000000000
--- a/chapter02/aboutdependencies.xml
+++ /dev/null
@@ -1,57 +0,0 @@
-<sect1 id="prepare-aboutdependencies">
-<title>About dependencies</title>
-<?dbhtml filename="aboutdependencies.html" dir="chapter02"?>
-
-<!-- Leave this file in the repo until we figure out finally what to do with
-dependencies -->
-
-<para>There are a few ways to compile a list of a package's installation
-dependencies. What we consider the best way is using the
-<command>strace</command> program available at <ulink
-url="http://www.wi.leidenuniv.nl/~wichert/strace/"/>.</para>
-
-<para><command>strace</command> is a program that provides a trace of all
-system calls made by another program. One of the most useful system calls
-to trace when figuring out dependencies is the <emphasis>execve(2)</emphasis>
-system call, which is used to execute programs (see its man page for
-all the details). Whenever you run a program, be it from a shell or via a
-configure script or Makefile file, the execve call is made. If you trace
-these calls, you will know what programs were executed behind the
-scenes.</para>
-
-<para>Here is a line of output from running a configure script:</para>
-
-<screen>19580 execve("/bin/rm", ["rm", "-f", "conf19538", "conf19538.exe", "conf19538.file"], [/* 26 vars */]) = 0</screen>
-
-<para>This line tells us that the <command>/bin/rm</command> program was
-run with a PID of 19580, which command line parameters it was given (rm -f
-conf195838 conf19538.exe conf19538.file) and its exit value (0).</para>
-
-<para>For dependency purposes all we care about is that
-<command>/bin/rm</command> was run during the configure script, so this is
-an installation dependency. Without <command>rm</command>, the script
-wouldn't be able to run properly.</para>
-
-<para>Unfortunately, this method is not foolproof. Configure scripts check
-for the presense of many programs, but not all of them are considered real
-dependencies. For instance, configure scripts may check for the presence of
-the <command>autoconf</command> program. It will be listed in the strace
-output, but it's not a real installation dependency. A package will in most
-if not all cases install just fine without that program. There are other
-such false positives.</para>
-
-<para>This means automatic dependency gathering is never accurate. You will
-always need to validate the list and figure out the false positives. In
-some (rare) cases autoconf might be a real dependency, so you
-can't simply ignore all autoconf entries. A manual validation really is a
-requirement for an accurate list.</para>
-
-<para>This book is not so verbose as to list exactly which program from which
-package is required for a successful installation (we used to, but it had
-become too much work to maintain it). The book will contain simply the
-names of packages you need to have installed. If you need the verbosity
-in the form of "package a needs file b and c from package d", have a look
-at &lt;enter URL when it's available&gt;.</para>
-
-</sect1>
-
diff --git a/chapter02/aboutlfs.xml b/chapter02/aboutlfs.xml
deleted file mode 100644
index 4141a01c0..000000000
--- a/chapter02/aboutlfs.xml
+++ /dev/null
@@ -1,32 +0,0 @@
-<sect1 id="prepare-aboutlfs">
-<title>About $LFS</title>
-<?dbhtml filename="aboutlfs.html" dir="chapter02"?>
-
-<para>Please read the following paragraphs carefully. Throughout this book the
-variable LFS will be used frequently. $LFS must at all times be replaced with
-the directory where the partition that contains the LFS system is mounted. How
-to create and where to mount the partition will be explained in full detail in
-<xref linkend="chapter-making-space"/>. For the moment let's assume that the LFS partition
-is mounted on <filename>/mnt/lfs</filename>.</para>
-
-<para>When you are told to run a command like
-<userinput>./configure --prefix=$LFS/tools</userinput>, you actually have to
-execute <userinput>./configure --prefix=/mnt/lfs/tools</userinput>.</para>
-
-<para>It's important that this is done no matter where it is read; be it in
-commands entered in a shell, or in a file edited or created.</para>
-
-<para>A possible solution is to set the environment variable LFS.
-This way $LFS can be entered literally instead of replacing it with 
-/mnt/lfs. This is accomplished by running: </para>
-
-<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
-
-<para>Now, if you are told to run a command such as
-<userinput>./configure --prefix=$LFS/tools</userinput>, then you may type it
-literally. Your shell will replace "$LFS" with "/mnt/lfs" when it processes
-the command line (that is, when you hit Enter after having typed the
-command).</para>
-
-</sect1>
-
diff --git a/chapter02/aboutsbus.xml b/chapter02/aboutsbus.xml
deleted file mode 100644
index 0c3e93995..000000000
--- a/chapter02/aboutsbus.xml
+++ /dev/null
@@ -1,39 +0,0 @@
-<sect1 id="prepare-aboutsbus">
-<title>About SBUs</title>
-<?dbhtml filename="aboutsbus.html" dir="chapter02"?>
-
-<para>Most people would like to know beforehand how long it approximately
-takes to compile and install each package. But "Linux from Scratch" is built
-on so many different systems, it is not possible to give actual times that are
-anywhere near accurate: the biggest package (Glibc) won't take more than
-twenty minutes on the fastest systems, but will take something like three days
-on the slowest -- no kidding. So instead of giving actual times, we've come up
-with the idea of using the <emphasis>Static Binutils Unit</emphasis>
-(abbreviated to <emphasis>SBU</emphasis>).</para>
-
-<para>It works like this: the first package you compile in this book is the
-statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
-takes to compile this package is what we call the "Static Binutils Unit" or
-"SBU". All other compile times will be expressed relative to this time.</para>
-
-<para>For example, the time it takes to build the static version of GCC is
-&gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
-to compile and install the static Binutils, then you know it will take
-approximately 45 minutes to build the static GCC. Fortunately, most build times
-are much shorter than the one of Binutils.</para>
-
-<para>Note that if the system compiler on your host is GCC-2 based, the SBUs
-listed may end up being 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% slower.</para>
-
-<para>Also note that SBUs don't work well for SMP-based machines. But if you're
-so lucky as to have multiple processors, chances are that your system is so fast
-that you won't mind.</para>
-
-<para>If you wish to see actual timings for specific machines, have a look at
-<ulink url="&lfs-root;~bdubbs/"/>.</para>
-
-</sect1>
-
diff --git a/chapter02/abouttestsuites.xml b/chapter02/abouttestsuites.xml
deleted file mode 100644
index 6f4831ac1..000000000
--- a/chapter02/abouttestsuites.xml
+++ /dev/null
@@ -1,40 +0,0 @@
-<sect1 id="prepare-abouttestsuites">
-<title>About the test suites</title>
-<?dbhtml filename="abouttestsuites.html" dir="chapter02"?>
-
-<para>Most packages provide a test suite. Running the test suite for a newly
-built package is generally a good idea, as it can provide a nice sanity check
-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 -- GCC, Binutils, and Glibc -- are of
-the utmost importance due to their central role in a properly functioning
-system. But be warned, the test suites for GCC and Glibc can take a very long
-time to complete, especially on slower hardware.</para>
-
-<note><para>Experience has shown us 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 weird and inexplicable failures. Not only
-that, the tools built in <xref linkend="chapter-temporary-tools"/> are
-temporary and eventually discarded. For the average reader of this book we
-recommend <emphasis>not</emphasis> to run the test suites in <xref
-linkend="chapter-temporary-tools"/>. The instructions for running those test
-suites are still provided for the benefit of testers and developers, but they
-are strictly optional for everyone else.</para></note>
-
-<para>A common problem when running the test suites for Binutils and GCC is
-running out of pseudo terminals (PTYs for short). The symptom is a very high
-number of failing tests. This can happen for several reasons, but the most
-likely cause is that the host system doesn't have the
-<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
-more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
-
-<para>Sometimes package test suites will give false failures. You can
-consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
-failures are normal. This applies to all tests throughout the book.</para>
-
-</sect1>
-
diff --git a/chapter02/chapter02.xml b/chapter02/chapter02.xml
index 9d6956300..e1e6e74ec 100644
--- a/chapter02/chapter02.xml
+++ b/chapter02/chapter02.xml
@@ -1,10 +1,135 @@
-<chapter id="chapter-preparation" xreflabel="Chapter 2">
-<title>Important information</title>
+<chapter id="chapter-making-space" xreflabel="Chapter 2">
+<title>Preparing a new partition</title>
 <?dbhtml filename="chapter02.html" dir="chapter02"?>
 
-&c2-aboutlfs;
-&c2-aboutsbus;
-&c2-abouttestsuites;
-&c2-askforhelp;
+
+<sect1 id="space-introduction">
+<title>Introduction</title>
+<?dbhtml filename="introduction.html" dir="chapter02"?>
+
+<para>In this chapter the partition which will host the LFS system is
+prepared. We will create the partition itself, make a file system on it,
+and mount it.</para>
+
+</sect1>
+
+
+<sect1 id="space-creatingpartition">
+<title>Creating a new partition</title>
+<?dbhtml filename="creatingpartition.html" dir="chapter02"?>
+
+<para>In order to build our new Linux system, we will need some space:
+an empty disk partition. If you don't have a free partition, and no room
+on any of your hard disks to make one, then you could build LFS on the
+same partition as the one on which your current distribution is installed.
+This procedure is not recommended for your first LFS install, but if you
+are short on disk space, and you feel brave, take a look at the hint at
+<ulink url="&hints-root;lfs_next_to_existing_systems.txt"/>.</para>
+
+<para>For a minimal system you will need a partition of around 1.2 GB.
+This is enough to store all the source tarballs and compile all the packages.
+But if you intend to use the LFS system as your primary Linux system, you
+will probably want to install additional software, and will need more space
+than this, probably around 2 or 3 GB.</para>
+
+<para>As we almost never have enough RAM in our box, it is a good idea to
+use a small disk partition as swap space -- this space is used by the kernel
+to store seldom-used data to make room in memory for more urgent stuff.
+The swap partition for your LFS system can be the same one as for your host
+system, so you won't have to create another if your host system already uses
+a swap partition.</para>
+
+<para>Start a disk partitioning program such as <command>cfdisk</command>
+or <command>fdisk</command> with an argument naming the hard disk upon
+which the new partition must be created -- for example
+<filename>/dev/hda</filename> for the primary IDE disk. Create a Linux native
+partition and a swap partition, if needed. Please refer to the man pages of
+<command>cfdisk</command> or <command>fdisk</command> if you don't yet
+know how to use the programs.</para>
+
+<para>Remember the designation of your new partition -- something like
+<filename>hda5</filename>. This book will refer to it as the LFS partition.
+If you (now) also have a swap partition, remember its designation too. These
+names will later be needed for the <filename>/etc/fstab</filename> file.</para>
+
+</sect1>
+
+
+<sect1 id="space-creatingfilesystem">
+<title>Creating a file system on the new partition</title>
+<?dbhtml filename="creatingfilesystem.html" dir="chapter02"?>
+
+<para>Now that we have a blank partition, we can create a file system on it.
+Most widely used in the Linux world is the second extended file system (ext2),
+but with the high-capacity hard disks of today the so-called journaling
+file systems are becoming increasingly popular. Here we will create an ext2
+file system, but build instructions for other file systems can be found at
+<ulink url="&blfs-root;view/stable/postlfs/filesystems.html"/>.</para>
+
+<para>To create an ext2 file system on the LFS partition run the following:</para>
+
+<screen><userinput>mke2fs /dev/xxx</userinput></screen>
+
+<para>Replace <filename>xxx</filename> with the name of the LFS partition
+(something like <filename>hda5</filename>).</para>
+
+<para>If you created a (new) swap partition you need to initialize it as a
+swap partition too (also known as formatting, like you did above with
+<command>mke2fs</command>) by running:</para>
+
+<screen><userinput>mkswap /dev/yyy</userinput></screen>
+
+<para>Replace <filename>yyy</filename> with the name of the swap
+partition.</para>
+
+</sect1>
+
+
+<sect1 id="space-mounting">
+<title>Mounting the new partition</title>
+<?dbhtml filename="mounting.html" dir="chapter02"?>
+
+<para>Now that we've created a file system, we want to be able to access
+the partition. For that, we need to mount it, and have to choose a mount
+point. In this book we assume that the file system is mounted under
+<filename>/mnt/lfs</filename>, but it doesn't matter what directory
+you choose.</para>
+
+<para>Choose a mount point and assign it to the LFS environment variable
+by running:</para>
+
+<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
+
+<para>Now create the mount point and mount the LFS file system by running:</para>
+
+<screen><userinput>mkdir -p $LFS
+mount /dev/xxx $LFS</userinput></screen>
+
+<para>Replace <filename>xxx</filename> with the designation of the LFS
+partition.</para>
+
+<para>If you have decided to use multiple partitions for LFS (say one for
+<filename>/</filename> and another for <filename>/usr</filename>), mount
+them like this:</para>
+
+<screen><userinput>mkdir -p $LFS
+mount /dev/xxx $LFS
+mkdir $LFS/usr
+mount /dev/yyy $LFS/usr</userinput></screen>
+
+<para>Of course, replace <filename>xxx</filename> and <filename>yyy</filename>
+with the appropriate partition names.</para>
+
+<para>You should also ensure that this new partition is not mounted with
+permissions that are too restrictive (such as the nosuid, nodev or noatime
+options). You can run the <command>mount</command> command without any
+parameters to see with what options the LFS partition is mounted. If
+you see nosuid, nodev or noatime, you will need to remount it.</para>
+ 
+<para>Now that we've made ourselves a place to work in, we're ready to download
+the packages.</para>
+
+</sect1>
+
 
 </chapter>
diff --git a/chapter03/chapter03.xml b/chapter03/chapter03.xml
index 9da7ccf05..da14e970a 100644
--- a/chapter03/chapter03.xml
+++ b/chapter03/chapter03.xml
@@ -1,135 +1,326 @@
-<chapter id="chapter-making-space" xreflabel="Chapter 3">
-<title>Preparing a new partition</title>
+<chapter id="chapter-getting-materials" xreflabel="Chapter 3">
+<title>The materials: packages and patches</title>
 <?dbhtml filename="chapter03.html" dir="chapter03"?>
 
 
-<sect1 id="space-introduction">
+<sect1 id="materials-introduction">
 <title>Introduction</title>
 <?dbhtml filename="introduction.html" dir="chapter03"?>
 
-<para>In this chapter the partition which will host the LFS system is
-prepared. We will create the partition itself, make a file system on it,
-and mount it.</para>
+<para>Below is a list of packages you need to download for building a basic
+Linux system. The listed version numbers correspond to versions of the
+software that are <emphasis>known</emphasis> to work, and this book is
+based upon them. Unless you are an experienced LFS builder, we highly
+recommend not to try out newer versions, as the build commands for one
+version may not work with a newer version. Also, there is often a good
+reason for not using the latest version due to known problems that haven't
+been worked around yet.</para>
+
+<para>All the URLs, when possible, refer to the project's page at
+<ulink url="http://www.freshmeat.net/"/>. The Freshmeat
+pages will give you easy access to the official download sites as well as
+project websites, mailing lists, FAQs, changelogs and more.</para>
+
+<para>We can't guarantee that these download locations are always available.
+In case a download location has changed since this book was published, please
+try to google for the package. Should you remain unsuccessful with this, you
+can consult the book's errata page at <ulink url="&lfs-root;lfs/print/"/>
+or, better yet, try one of the alternative means of downloading listed on
+<ulink url="&lfs-root;lfs/packages.html"/>.</para>
+
+<para>You'll need to store all the downloaded packages and patches somewhere
+that is conveniently available throughout the entire build. You'll also need a
+working directory in which to unpack the sources and build them. A scheme that
+works well is to use <filename>$LFS/sources</filename> as the place to store
+the tarballs and patches, <emphasis>and</emphasis> as a working directory.
+This way everything you need will be located on the LFS partition and available
+during all stages of the building process.</para>
+
+<para>So you may want to execute, as <emphasis>root</emphasis>, the following
+command before starting your download session:</para>
+
+<screen><userinput>mkdir $LFS/sources</userinput></screen>
+
+<para>And make this directory writable (and sticky) for your normal user -- as
+you won't do the downloading as <emphasis>root</emphasis>, we guess:</para>
+
+<screen><userinput>chmod a+wt $LFS/sources</userinput></screen>
+
+<!--
+<para>For your convenience the top of the list contains a link to a file
+you can use with the <ulink url="http://wget.sunsite.dk">wget</ulink>
+program. Using this file and the <command>wget</command> program will
+make it easy to download all the files at once, rather than downloading each
+and every individual file manually.</para>
+-->
 
 </sect1>
 
 
-<sect1 id="space-creatingpartition">
-<title>Creating a new partition</title>
-<?dbhtml filename="creatingpartition.html" dir="chapter03"?>
-
-<para>In order to build our new Linux system, we will need some space:
-an empty disk partition. If you don't have a free partition, and no room
-on any of your hard disks to make one, then you could build LFS on the
-same partition as the one on which your current distribution is installed.
-This procedure is not recommended for your first LFS install, but if you
-are short on disk space, and you feel brave, take a look at the hint at
-<ulink url="&hints-root;lfs_next_to_existing_systems.txt"/>.</para>
-
-<para>For a minimal system you will need a partition of around 1.2 GB.
-This is enough to store all the source tarballs and compile all the packages.
-But if you intend to use the LFS system as your primary Linux system, you
-will probably want to install additional software, and will need more space
-than this, probably around 2 or 3 GB.</para>
-
-<para>As we almost never have enough RAM in our box, it is a good idea to
-use a small disk partition as swap space -- this space is used by the kernel
-to store seldom-used data to make room in memory for more urgent stuff.
-The swap partition for your LFS system can be the same one as for your host
-system, so you won't have to create another if your host system already uses
-a swap partition.</para>
-
-<para>Start a disk partitioning program such as <command>cfdisk</command>
-or <command>fdisk</command> with an argument naming the hard disk upon
-which the new partition must be created -- for example
-<filename>/dev/hda</filename> for the primary IDE disk. Create a Linux native
-partition and a swap partition, if needed. Please refer to the man pages of
-<command>cfdisk</command> or <command>fdisk</command> if you don't yet
-know how to use the programs.</para>
-
-<para>Remember the designation of your new partition -- something like
-<filename>hda5</filename>. This book will refer to it as the LFS partition.
-If you (now) also have a swap partition, remember its designation too. These
-names will later be needed for the <filename>/etc/fstab</filename> file.</para>
+<sect1 id="materials-packages">
+<title>All the packages</title>
+<?dbhtml filename="packages.html" dir="chapter03"?>
 
-</sect1>
+<para>Download or otherwise obtain the following packages:</para>
 
+<literallayout>
+Autoconf (&autoconf-version;) - &autoconf-size;:
+<ulink url="http://freshmeat.net/projects/autoconf/"/>
 
-<sect1 id="space-creatingfilesystem">
-<title>Creating a file system on the new partition</title>
-<?dbhtml filename="creatingfilesystem.html" dir="chapter03"?>
+Automake (&automake-version;) - &automake-size;:
+<ulink url="http://freshmeat.net/projects/automake/"/>
 
-<para>Now that we have a blank partition, we can create a file system on it.
-Most widely used in the Linux world is the second extended file system (ext2),
-but with the high-capacity hard disks of today the so-called journaling
-file systems are becoming increasingly popular. Here we will create an ext2
-file system, but build instructions for other file systems can be found at
-<ulink url="&blfs-root;view/stable/postlfs/filesystems.html"/>.</para>
+Bash (&bash-version;) - &bash-size;:
+<ulink url="http://freshmeat.net/projects/gnubash/"/>
 
-<para>To create an ext2 file system on the LFS partition run the following:</para>
+Binutils (&binutils-version;) - &binutils-size;:
+<ulink url="http://freshmeat.net/projects/binutils/"/>
 
-<screen><userinput>mke2fs /dev/xxx</userinput></screen>
+Bison (&bison-version;) - &bison-size;:
+<ulink url="http://freshmeat.net/projects/bison/"/>
 
-<para>Replace <filename>xxx</filename> with the name of the LFS partition
-(something like <filename>hda5</filename>).</para>
+Bzip2 (&bzip2-version;) - &bzip2-size;:
+<ulink url="http://freshmeat.net/projects/bzip2/"/>
 
-<para>If you created a (new) swap partition you need to initialize it as a
-swap partition too (also known as formatting, like you did above with
-<command>mke2fs</command>) by running:</para>
+Coreutils (&coreutils-version;) - &coreutils-size;:
+<ulink url="http://freshmeat.net/projects/coreutils/"/>
 
-<screen><userinput>mkswap /dev/yyy</userinput></screen>
+DejaGnu (&dejagnu-version;) - &dejagnu-size;:
+<ulink url="http://freshmeat.net/projects/dejagnu/"/>
 
-<para>Replace <filename>yyy</filename> with the name of the swap
-partition.</para>
+Diffutils (&diffutils-version;) - &diffutils-size;:
+<ulink url="http://freshmeat.net/projects/diffutils/"/>
 
-</sect1>
+E2fsprogs (&e2fsprogs-version;) - &e2fsprogs-size;:
+<ulink url="http://freshmeat.net/projects/e2fsprogs/"/>
+
+Ed (&ed-version;) - &ed-size;:
+<ulink url="http://freshmeat.net/projects/ed/"/>
+
+Expect (&expect-version;) - &expect-size;:
+<ulink url="http://freshmeat.net/projects/expect/"/>
+
+File (&file-version;) - &file-size;: -- <emphasis>(see Note 1 below)</emphasis>
+<ulink url="http://freshmeat.net/projects/file/"/>
+
+Findutils (&findutils-version;) - &findutils-size;:
+<ulink url="http://freshmeat.net/projects/findutils/"/>
+
+Flex (&flex-version;) - &flex-size;:
+<ulink url="ftp://ftp.gnu.org/gnu/non-gnu/flex/"/>
+
+Gawk (&gawk-version;) - &gawk-size;:
+<ulink url="http://freshmeat.net/projects/gnuawk/"/>
+
+GCC-core (&gcc-version;) - &gcc-core-size;:
+<ulink url="http://freshmeat.net/projects/gcc/"/>
+GCC-g++ (&gcc-version;) - &gcc-gpp-size;:
+<ulink url="http://freshmeat.net/projects/gcc/"/>
+GCC-testsuite (&gcc-version;) - &gcc-testsuite-size;:
+<ulink url="http://freshmeat.net/projects/gcc/"/>
+
+GCC-2 (&gcc-2953-version;) - &gcc-2953-size;:
+<ulink url="http://freshmeat.net/projects/gcc/"/>
+
+Gettext (&gettext-version;) - &gettext-size;:
+<ulink url="http://freshmeat.net/projects/gettext/"/>
+
+Glibc (&glibc-version;) - &glibc-size;: -- <emphasis>(see Note 2 below)</emphasis>
+<ulink url="http://freshmeat.net/projects/glibc/"/>
+
+Grep (&grep-version;) - &grep-size;:
+<ulink url="http://freshmeat.net/projects/grep/"/>
+
+Groff (&groff-version;) - &groff-size;:
+<ulink url="http://freshmeat.net/projects/groff/"/>
+
+Grub (&grub-version;) - &grub-size;:
+<ulink url="ftp://alpha.gnu.org/pub/gnu/grub/"/>
+
+Gzip (&gzip-version;) - &gzip-size;:
+<ulink url="ftp://alpha.gnu.org/gnu/gzip/"/>
+
+Inetutils (&inetutils-version;) - &inetutils-size;:
+<ulink url="http://freshmeat.net/projects/inetutils/"/>
+
+Kbd (&kbd-version;) - &kbd-size;:
+<ulink url="http://freshmeat.net/projects/kbd/"/>
+
+Less (&less-version;) - &less-size;:
+<ulink url="http://freshmeat.net/projects/less/"/>
+
+LFS-Bootscripts (&bootscripts-version;) - &bootscripts-size;:
+<ulink url="&http-down;lfs-bootscripts-&bootscripts-version;.tar.bz2"/>
+
+Lfs-Utils (&lfs-utils-version;) - &lfs-utils-size;:
+<ulink url="&lfs-root;~winkie/downloads/lfs-utils/"/>
+
+Libtool (&libtool-version;) - &libtool-size;:
+<ulink url="http://freshmeat.net/projects/libtool/"/>
+
+Linux (&kernel-version;) - &kernel-size;:
+<ulink url="http://freshmeat.net/projects/linux/"/>
+
+M4 (&m4-version;) - &m4-size;:
+<ulink url="http://freshmeat.net/projects/gnum4/"/>
+
+Make (&make-version;) - &make-size;:
+<ulink url="http://freshmeat.net/projects/gnumake/"/>
+
+Make_devices (&makedev-version;) - &makedev-size;:
+<ulink url="&lfs-root;~alex/make_devices-&makedev-version;.bz2"/>
+
+Man (&man-version;) - &man-size;:
+<ulink url="http://freshmeat.net/projects/man/"/>
+
+Man-pages (&man-pages-version;) - &man-pages-size;:
+<ulink url="http://freshmeat.net/projects/man-pages/"/>
+
+Modutils (&modutils-version;) - &modutils-size;:
+<ulink url="http://freshmeat.net/projects/modutils/"/>
 
+Ncurses (&ncurses-version;) - &ncurses-size;:
+<ulink url="http://freshmeat.net/projects/ncurses/"/>
 
-<sect1 id="space-mounting">
-<title>Mounting the new partition</title>
-<?dbhtml filename="mounting.html" dir="chapter03"?>
+Net-tools (&net-tools-version;) - &net-tools-size;:
+<ulink url="http://freshmeat.net/projects/net-tools/"/>
 
-<para>Now that we've created a file system, we want to be able to access
-the partition. For that, we need to mount it, and have to choose a mount
-point. In this book we assume that the file system is mounted under
-<filename>/mnt/lfs</filename>, but it doesn't matter what directory
-you choose.</para>
+Patch (&patch-version;) - &patch-size;:
+<ulink url="http://freshmeat.net/projects/patch/"/>
 
-<para>Choose a mount point and assign it to the LFS environment variable
-by running:</para>
+Perl (&perl-version;) - &perl-size;:
+<ulink url="http://freshmeat.net/projects/perl/"/>
 
-<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
+Procinfo (&procinfo-version;) - &procinfo-size;:
+<ulink url="http://freshmeat.net/projects/procinfo/"/>
 
-<para>Now create the mount point and mount the LFS file system by running:</para>
+Procps (&procps-version;) - &procps-size;:
+<ulink url="http://freshmeat.net/projects/procps/"/>
 
-<screen><userinput>mkdir -p $LFS
-mount /dev/xxx $LFS</userinput></screen>
+Psmisc (&psmisc-version;) - &psmisc-size;:
+<ulink url="http://freshmeat.net/projects/psmisc/"/>
 
-<para>Replace <filename>xxx</filename> with the designation of the LFS
-partition.</para>
+Sed (&sed-version;) - &sed-size;:
+<ulink url="http://freshmeat.net/projects/sed/"/>
 
-<para>If you have decided to use multiple partitions for LFS (say one for
-<filename>/</filename> and another for <filename>/usr</filename>), mount
-them like this:</para>
+Shadow (&shadow-version;) - &shadow-size;:
+<ulink url="http://freshmeat.net/projects/shadow/"/>
 
-<screen><userinput>mkdir -p $LFS
-mount /dev/xxx $LFS
-mkdir $LFS/usr
-mount /dev/yyy $LFS/usr</userinput></screen>
+Sysklogd (&sysklogd-version;) - &sysklogd-size;:
+<ulink url="http://freshmeat.net/projects/sysklogd/"/>
 
-<para>Of course, replace <filename>xxx</filename> and <filename>yyy</filename>
-with the appropriate partition names.</para>
+Sysvinit (&sysvinit-version;) - &sysvinit-size;:
+<ulink url="http://freshmeat.net/projects/sysvinit/"/>
 
-<para>You should also ensure that this new partition is not mounted with
-permissions that are too restrictive (such as the nosuid, nodev or noatime
-options). You can run the <command>mount</command> command without any
-parameters to see with what options the LFS partition is mounted. If
-you see nosuid, nodev or noatime, you will need to remount it.</para>
- 
-<para>Now that we've made ourselves a place to work in, we're ready to download
-the packages.</para>
+Tar (&tar-version;) - &tar-size;:
+<ulink url="ftp://alpha.gnu.org/gnu/tar/"/>
+
+Tcl (&tcl-version;) - &tcl-size;:
+<ulink url="http://freshmeat.net/projects/tcltk/"/>
+
+Texinfo (&texinfo-version;) - &texinfo-size;:
+<ulink url="http://freshmeat.net/projects/texinfo/"/>
+
+Util-linux (&util-linux-version;) - &util-linux-size;:
+<ulink url="http://freshmeat.net/projects/util-linux/"/>
+
+Vim (&vim-version;) - &vim-size;:
+<ulink url="http://freshmeat.net/projects/vim/"/>
+
+Zlib (&zlib-version;) - &zlib-size;:
+<ulink url="http://freshmeat.net/projects/zlib/"/>
+
+Total size of these packages: &all-size-mb;
+</literallayout>
+
+<note><para>1) File (&file-version;) may not be available by the time you read
+this. The site admins of the master download location are known to occasionally
+remove old versions when new ones are released. Please refer to the
+<xref linkend="ch-system-file"/> section for an alternate download
+location.</para></note>
+
+<note><para>2) As of this writing, the Glibc maintainers have decided in their
+wisdom not to make available new release tarballs for download. The only way to
+obtain the current Glibc release from pristine upstream sources is to pull it
+from the Glibc CVS repository. The following commands will download the current
+release and make a tarball from it:</para>
+
+<screen><userinput>cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \
+&nbsp;&nbsp;&nbsp;&nbsp;export -d &glibc-dir; -D "2003-12-02 UTC" libc
+tar jcvf &glibc-package; &glibc-dir;</userinput></screen>
+
+<para>Alternatively, we've made our own tarball available which you can
+download courtesy of the generous LFS mirror sites. Please refer to the
+<xref linkend="ch-tools-glibc"/> section for the download links.</para></note>
 
 </sect1>
 
 
+<sect1 id="materials-patches">
+<title>Needed patches</title>
+<?dbhtml filename="patches.html" dir="chapter03"?>
+
+<para>Besides all those packages, you'll also need several patches. These
+correct tiny mistakes in the packages that should be fixed by the maintainer,
+or just make some small modifications to bend things our way. You'll need the
+following:</para>
+
+<literallayout>
+Bash Patch - &bash-patch-size;:
+<ulink url="&patches-root;&bash-patch;"/>
+
+Bison Attribute Patch - &bison-patch-size;:
+<ulink url="&patches-root;&bison-patch;"/>
+
+Coreutils Hostname Patch - &coreutils-hostname-patch-size;:
+<ulink url="&patches-root;&coreutils-hostname-patch;"/>
+Coreutils Posixver Patch - &coreutils-posixver-patch-size;:
+<ulink url="&patches-root;&coreutils-posixver-patch;"/>
+Coreutils Uname Patch - &coreutils-uname-patch-size;:
+<ulink url="&patches-root;&coreutils-uname-patch;"/>
+
+Ed Mkstemp Patch - &ed-patch-size;:
+<ulink url="&patches-root;&ed-patch;"/>
+
+Expect Spawn Patch - &expect-patch-size;:
+<ulink url="&patches-root;&expect-patch;"/>
+
+GCC No-Fixincludes Patch - &gcc-nofixincludes-patch-size;:
+<ulink url="&patches-root;&gcc-nofixincludes-patch;"/>
+GCC Specs Patch - &gcc-specs-patch-size;:
+<ulink url="&patches-root;&gcc-specs-patch;"/>
+
+GCC-2 Patch - &gcc-2953-patch-size;:
+<ulink url="&patches-root;&gcc-2953-patch;"/>
+GCC-2 No-Fixincludes Patch - &gcc-2953-no-fixinc-patch-size;:
+<ulink url="&patches-root;&gcc-2953-no-fixinc-patch;"/>
+GCC-2 Return-Type Patch - &gcc-2953-returntype-fix-patch-size;:
+<ulink url="&patches-root;&gcc-2953-returntype-fix-patch;"/>
+
+Inetutils No-Server-Man-Pages Patch - &inetutils-no-server-man-pages-patch-size;:
+<ulink url="&patches-root;&inetutils-no-server-man-pages-patch;"/>
+
+Kbd More-Programs Patch - &kbd-patch-size;:
+<ulink url="&patches-root;&kbd-patch;"/>
+
+Man 80-Columns Patch - &man-80cols-patch-size;:
+<ulink url="&patches-root;&man-80cols-patch;"/>
+
+Net-tools Mii-Tool-Gcc33 Patch - &net-tools-mii-patch-size;:
+<ulink url="&patches-root;&net-tools-mii-patch;"/>
+
+Perl Libc Patch - &perl-libc-patch-size;:
+<ulink url="&patches-root;&perl-libc-patch;"/>
+</literallayout>
+
+<para>In addition to the above required patches, there exist a number of
+optional ones created by the LFS community. Most of these solve slight
+problems, or enable some functionality that's not enabled by default.
+Feel free to examine the patches database, located at <ulink
+url="&lfs-root;patches/"/>, and pick any additional patches you wish to
+use.</para>
+
+</sect1>
+
 </chapter>
+
diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml
index 79383efb0..07d13156e 100644
--- a/chapter04/chapter04.xml
+++ b/chapter04/chapter04.xml
@@ -1,333 +1,284 @@
-<chapter id="chapter-getting-materials" xreflabel="Chapter 4">
-<title>The materials: packages and patches</title>
+<chapter id="chapter-preparation" xreflabel="Chapter 4">
+<title>Last preparations</title>
 <?dbhtml filename="chapter04.html" dir="chapter04"?>
 
 
-<sect1 id="materials-introduction">
-<title>Introduction</title>
-<?dbhtml filename="introduction.html" dir="chapter04"?>
-
-<para>Below is a list of packages you need to download for building a basic
-Linux system. The listed version numbers correspond to versions of the
-software that are <emphasis>known</emphasis> to work, and this book is
-based upon them. Unless you are an experienced LFS builder, we highly
-recommend not to try out newer versions, as the build commands for one
-version may not work with a newer version. Also, there is often a good
-reason for not using the latest version due to known problems that haven't
-been worked around yet.</para>
-
-<para>All the URLs, when possible, refer to the project's page at
-<ulink url="http://www.freshmeat.net/"/>. The Freshmeat
-pages will give you easy access to the official download sites as well as
-project websites, mailing lists, FAQs, changelogs and more.</para>
-
-<para>We can't guarantee that these download locations are always available.
-In case a download location has changed since this book was published, please
-try to google for the package. Should you remain unsuccessful with this, you
-can consult the book's errata page at <ulink url="&lfs-root;lfs/print/"/>
-or, better yet, try one of the alternative means of downloading listed on
-<ulink url="&lfs-root;lfs/packages.html"/>.</para>
-
-<para>You'll need to store all the downloaded packages and patches somewhere
-that is conveniently available throughout the entire build. You'll also need a
-working directory in which to unpack the sources and build them. A scheme that
-works well is to use <filename>$LFS/sources</filename> as the place to store
-the tarballs and patches, <emphasis>and</emphasis> as a working directory.
-This way everything you need will be located on the LFS partition and available
-during all stages of the building process.</para>
-
-<para>So you may want to execute, as <emphasis>root</emphasis>, the following
-command before starting your download session:</para>
-
-<screen><userinput>mkdir $LFS/sources</userinput></screen>
-
-<para>And make this directory writable (and sticky) for your normal user -- as
-you won't do the downloading as <emphasis>root</emphasis>, we guess:</para>
-
-<screen><userinput>chmod a+wt $LFS/sources</userinput></screen>
-
-<!--
-<para>For your convenience the top of the list contains a link to a file
-you can use with the <ulink url="http://wget.sunsite.dk">wget</ulink>
-program. Using this file and the <command>wget</command> program will
-make it easy to download all the files at once, rather than downloading each
-and every individual file manually.</para>
--->
+<sect1 id="prepare-aboutlfs">
+<title>About $LFS</title>
+<?dbhtml filename="aboutlfs.html" dir="chapter04"?>
 
-</sect1>
-
-
-<sect1 id="materials-packages">
-<title>All the packages</title>
-<?dbhtml filename="packages.html" dir="chapter04"?>
-
-<para>Download or otherwise obtain the following packages:</para>
-
-<literallayout>
-Autoconf (&autoconf-version;) - &autoconf-size;:
-<ulink url="http://freshmeat.net/projects/autoconf/"/>
-
-Automake (&automake-version;) - &automake-size;:
-<ulink url="http://freshmeat.net/projects/automake/"/>
-
-Bash (&bash-version;) - &bash-size;:
-<ulink url="http://freshmeat.net/projects/gnubash/"/>
-
-Binutils (&binutils-version;) - &binutils-size;:
-<ulink url="http://freshmeat.net/projects/binutils/"/>
-
-Bison (&bison-version;) - &bison-size;:
-<ulink url="http://freshmeat.net/projects/bison/"/>
-
-Bzip2 (&bzip2-version;) - &bzip2-size;:
-<ulink url="http://freshmeat.net/projects/bzip2/"/>
-
-Coreutils (&coreutils-version;) - &coreutils-size;:
-<ulink url="http://freshmeat.net/projects/coreutils/"/>
-
-DejaGnu (&dejagnu-version;) - &dejagnu-size;:
-<ulink url="http://freshmeat.net/projects/dejagnu/"/>
-
-Diffutils (&diffutils-version;) - &diffutils-size;:
-<ulink url="http://freshmeat.net/projects/diffutils/"/>
-
-E2fsprogs (&e2fsprogs-version;) - &e2fsprogs-size;:
-<ulink url="http://freshmeat.net/projects/e2fsprogs/"/>
-
-Ed (&ed-version;) - &ed-size;:
-<ulink url="http://freshmeat.net/projects/ed/"/>
-
-Expect (&expect-version;) - &expect-size;:
-<ulink url="http://freshmeat.net/projects/expect/"/>
-
-File (&file-version;) - &file-size;: -- <emphasis>(see Note 1 below)</emphasis>
-<ulink url="http://freshmeat.net/projects/file/"/>
-
-Findutils (&findutils-version;) - &findutils-size;:
-<ulink url="http://freshmeat.net/projects/findutils/"/>
-
-Flex (&flex-version;) - &flex-size;:
-<ulink url="ftp://ftp.gnu.org/gnu/non-gnu/flex/"/>
-
-Gawk (&gawk-version;) - &gawk-size;:
-<ulink url="http://freshmeat.net/projects/gnuawk/"/>
-
-GCC (&gcc-2953-version;) - &gcc-2953-size;:
-<ulink url="http://freshmeat.net/projects/gcc/"/>
-
-GCC-core (&gcc-version;) - &gcc-core-size;:
-<ulink url="http://freshmeat.net/projects/gcc/"/>
-
-GCC-g++ (&gcc-version;) - &gcc-gpp-size;:
-<ulink url="http://freshmeat.net/projects/gcc/"/>
+<para>Throughout this book the environment variable LFS will be used several
+times. It is paramount that this variable is always defined. It should be set
+to the mount point you chose for your LFS partition. Check that your LFS
+variable is set up properly with:</para>
 
-GCC-testsuite (&gcc-version;) - &gcc-testsuite-size;:
-<ulink url="http://freshmeat.net/projects/gcc/"/>
+<screen><userinput>echo $LFS</userinput></screen>
 
-Gettext (&gettext-version;) - &gettext-size;:
-<ulink url="http://freshmeat.net/projects/gettext/"/>
+<para>Make sure the output shows the path to your LFS partition's mount
+point, which is <filename class="directory">/mnt/lfs</filename> if you
+followed our example. If the output is wrong, you can always set the variable
+with:</para>
 
-Glibc (&glibc-version;) - &glibc-size;: -- <emphasis>(see Note 2 below)</emphasis>
-<ulink url="http://freshmeat.net/projects/glibc/"/>
+<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
 
-Grep (&grep-version;) - &grep-size;:
-<ulink url="http://freshmeat.net/projects/grep/"/>
+<para>Having this variable set means that if you are told to run a command like
+<userinput>mkdir $LFS/tools</userinput>, you can type it literally. Your shell
+will replace "$LFS" with "/mnt/lfs" (or whatever you set the variable to) when
+it processes the command line.</para>
 
-Groff (&groff-version;) - &groff-size;:
-<ulink url="http://freshmeat.net/projects/groff/"/>
-
-Grub (&grub-version;) - &grub-size;:
-<ulink url="ftp://alpha.gnu.org/pub/gnu/grub/"/>
-
-Gzip (&gzip-version;) - &gzip-size;:
-<ulink url="ftp://alpha.gnu.org/gnu/gzip/"/>
-
-Inetutils (&inetutils-version;) - &inetutils-size;:
-<ulink url="http://freshmeat.net/projects/inetutils/"/>
-
-Kbd (&kbd-version;) - &kbd-size;:
-<ulink url="http://freshmeat.net/projects/kbd/"/>
-
-Less (&less-version;) - &less-size;:
-<ulink url="http://freshmeat.net/projects/less/"/>
-
-LFS-Bootscripts (&bootscripts-version;) - &bootscripts-size;:
-<ulink url="&http-down;lfs-bootscripts-&bootscripts-version;.tar.bz2"/>
-
-Lfs-Utils (&lfs-utils-version;) - &lfs-utils-size;:
-<ulink url="&lfs-root;~winkie/downloads/lfs-utils/"/>
-
-Libtool (&libtool-version;) - &libtool-size;:
-<ulink url="http://freshmeat.net/projects/libtool/"/>
-
-Linux (&kernel-version;) - &kernel-size;:
-<ulink url="http://freshmeat.net/projects/linux/"/>
-
-M4 (&m4-version;) - &m4-size;:
-<ulink url="http://freshmeat.net/projects/gnum4/"/>
+</sect1>
 
-Make (&make-version;) - &make-size;:
-<ulink url="http://freshmeat.net/projects/gnumake/"/>
 
-Make_devices (&makedev-version;) - &makedev-size;:
-<ulink url="&lfs-root;~alex/make_devices-&makedev-version;.bz2"/>
+<sect1 id="prepare-creatingtoolsdir">
+<title>Creating the $LFS/tools directory</title>
+<?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?>
 
-Man (&man-version;) - &man-size;:
-<ulink url="http://freshmeat.net/projects/man/"/>
+<para>All programs compiled in this chapter will be installed under <filename
+class="directory">$LFS/tools</filename> to keep them separate from the
+programs compiled in the next chapter. The programs compiled here are only
+temporary tools and won't be a part of the final LFS system and by keeping them
+in a separate directory, we can later easily throw them away.</para>
 
-Man-pages (&man-pages-version;) - &man-pages-size;:
-<ulink url="http://freshmeat.net/projects/man-pages/"/>
+<para>Later on you might wish to search through the binaries of your system to
+see what files they make use of or link against. To make this searching easier
+you may want to choose a unique name for the directory in which the temporary
+tools are stored. Instead of the simple "tools" you could use something like
+"tools-for-lfs". However, you'll need to be careful to adjust all references to
+"tools" throughout the book -- including those in any patches, notably the
+GCC Specs Patch.</para>
 
-Modutils (&modutils-version;) - &modutils-size;:
-<ulink url="http://freshmeat.net/projects/modutils/"/>
+<para>Create the required directory by running the following:</para>
 
-Ncurses (&ncurses-version;) - &ncurses-size;:
-<ulink url="http://freshmeat.net/projects/ncurses/"/>
+<screen><userinput>mkdir $LFS/tools</userinput></screen>
 
-Net-tools (&net-tools-version;) - &net-tools-size;:
-<ulink url="http://freshmeat.net/projects/net-tools/"/>
+<para>The next step is to create a <filename>/tools</filename> symlink on
+your host system. It will point to the directory we just created on the LFS
+partition:</para>
 
-Patch (&patch-version;) - &patch-size;:
-<ulink url="http://freshmeat.net/projects/patch/"/>
+<screen><userinput>ln -s $LFS/tools /</userinput></screen>
 
-Perl (&perl-version;) - &perl-size;:
-<ulink url="http://freshmeat.net/projects/perl/"/>
+<note><para>The above command is correct. The <command>ln</command> command
+has a few syntactic variations, so be sure to check the info page before
+reporting what you may think is an error.</para></note>
 
-Procinfo (&procinfo-version;) - &procinfo-size;:
-<ulink url="http://freshmeat.net/projects/procinfo/"/>
+<para>The created symlink enables us to compile our toolchain so that it always
+refers to <filename>/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) <emphasis>and</emphasis> in the next (when we are chrooted to
+the LFS partition).</para>
 
-Procps (&procps-version;) - &procps-size;:
-<ulink url="http://freshmeat.net/projects/procps/"/>
+</sect1>
 
-Psmisc (&psmisc-version;) - &psmisc-size;:
-<ulink url="http://freshmeat.net/projects/psmisc/"/>
 
-Sed (&sed-version;) - &sed-size;:
-<ulink url="http://freshmeat.net/projects/sed/"/>
+<sect1 id="prepar-addinguser">
+<title>Adding the user lfs</title>
+<?dbhtml filename="addinguser.html" dir="chapter05"?>
 
-Shadow (&shadow-version;) - &shadow-size;:
-<ulink url="http://freshmeat.net/projects/shadow/"/>
+<para>When logged in as <emphasis>root</emphasis>, making a single mistake
+can damage or even wreck your system. Therefore we recommend that you
+build the packages in this chapter as an unprivileged user. You could
+of course use your own user name, but to make it easier to set up a clean
+work environment we'll create a new user <emphasis>lfs</emphasis> and
+use this one during the installation process. As <emphasis>root</emphasis>,
+issue the following command to add the new user:</para>
 
-Sysklogd (&sysklogd-version;) - &sysklogd-size;:
-<ulink url="http://freshmeat.net/projects/sysklogd/"/>
+<screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen>
 
-Sysvinit (&sysvinit-version;) - &sysvinit-size;:
-<ulink url="http://freshmeat.net/projects/sysvinit/"/>
+<para>The meaning of the switches:</para>
 
-Tar (&tar-version;) - &tar-size;:
-<ulink url="ftp://alpha.gnu.org/gnu/tar/"/>
+<itemizedlist>
+<listitem><para><userinput>-s /bin/bash</userinput>: This makes
+<userinput>bash</userinput> the default shell for user
+<emphasis>lfs</emphasis>.</para></listitem>
 
-Tcl (&tcl-version;) - &tcl-size;:
-<ulink url="http://freshmeat.net/projects/tcltk/"/>
+<listitem><para><userinput>-m -k /dev/null</userinput>: These create a home
+directory for <emphasis>lfs</emphasis>, while preventing the files from a
+possible <filename>/etc/skel</filename> being copied into it.</para></listitem>
+</itemizedlist>
 
-Texinfo (&texinfo-version;) - &texinfo-size;:
-<ulink url="http://freshmeat.net/projects/texinfo/"/>
+<para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
+this new user a password:</para>
 
-Util-linux (&util-linux-version;) - &util-linux-size;:
-<ulink url="http://freshmeat.net/projects/util-linux/"/>
+<screen><userinput>passwd lfs</userinput></screen>
 
-Vim (&vim-version;) - &vim-size;:
-<ulink url="http://freshmeat.net/projects/vim/"/>
+<para>Now grant this new user <emphasis>lfs</emphasis> full access to
+<filename class="directory">$LFS/tools</filename> by giving it ownership
+of the directory:</para>
 
-Zlib (&zlib-version;) - &zlib-size;:
-<ulink url="http://freshmeat.net/projects/zlib/"/>
+<screen><userinput>chown lfs $LFS/tools</userinput></screen>
 
-Total size of these packages: &all-size-mb;
-</literallayout>
+<para>If you made a separate working directory as suggested, give user
+<emphasis>lfs</emphasis> ownership of this directory too:</para>
 
-<note><para>1) File (&file-version;) may not be available by the time you read
-this. The site admins of the master download location are known to occasionally
-remove old versions when new ones are released. Please refer to the
-<xref linkend="ch-system-file"/> section for an alternate download
-location.</para></note>
+<screen><userinput>chown lfs $LFS/sources</userinput></screen>
 
-<note><para>2) As of this writing, the Glibc maintainers have decided in their
-wisdom not to make available new release tarballs for download. The only way to
-obtain the current Glibc release from pristine upstream sources is to pull it
-from the Glibc CVS repository. The following commands will download the current
-release and make a tarball from it:</para>
+<para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
+virtual console, through a display manager, or with the following substitute
+user command:</para>
 
-<screen><userinput>cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \
-&nbsp;&nbsp;&nbsp;&nbsp;export -d &glibc-dir; -D "2003-12-02 UTC" libc
-tar jcvf &glibc-package; &glibc-dir;</userinput></screen>
+<screen><userinput>su - lfs</userinput></screen>
 
-<para>Alternatively, we've made our own tarball available which you can
-download courtesy of the generous LFS mirror sites. Please refer to the
-<xref linkend="ch-tools-glibc"/> section for the download links.</para></note>
+<para>The "<command>-</command>" instructs <command>su</command> to start a
+<emphasis>login</emphasis> shell.</para>
 
 </sect1>
 
 
-<sect1 id="materials-patches">
-<title>Needed patches</title>
-<?dbhtml filename="patches.html" dir="chapter04"?>
+<sect1 id="prepare-settingenvironment">
+<title>Setting up the environment</title>
+<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
+
+<para>We're going to set up a good working environment by creating two new
+startup files for the <command>bash</command> shell. While logged in as
+user <emphasis>lfs</emphasis>, issue the following command to create a new
+<filename>.bash_profile</filename>:</para>
+
+<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
+exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
+<userinput>EOF</userinput></screen>
+
+<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
+the initial shell is a <emphasis>login</emphasis> shell which reads the
+<filename>/etc/profile</filename> of your host (probably containing some
+settings of environment variables) and then <filename>.bash_profile</filename>.
+The <command>exec env -i ... /bin/bash</command> command in the latter file
+replaces the running shell with a new one with a completely empty environment,
+except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
+potentially hazardous environment variables from the host system leak into our
+build environment. The technique used here is a little strange, but it achieves
+the goal of enforcing a clean environment.</para>
+
+<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
+which doesn't read the <filename>/etc/profile</filename> or
+<filename>.bash_profile</filename> files, but reads the
+<filename>.bashrc</filename> file instead. Create this latter file now:</para>
+
+<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
+set +h
+umask 022
+LFS=/mnt/lfs
+LC_ALL=POSIX
+PATH=/tools/bin:/bin:/usr/bin
+export LFS LC_ALL PATH
+<userinput>EOF</userinput></screen>
+
+<para>The <command>set +h</command> command turns off
+<command>bash</command>'s hash function. Normally hashing is a useful
+feature: <command>bash</command> uses a hash table to remember the
+full pathnames of executable files to avoid searching the PATH time and time
+again to find the same executable. However, we'd like the new tools to be
+used as soon as they are installed. By switching off the hash function, our
+"interactive" commands (<command>make</command>,
+<command>patch</command>, <command>sed</command>,
+<command>cp</command> and so forth) will always use
+the newest available version during the build process.</para>
+
+<para>Setting the user file-creation mask to 022 ensures that newly created
+files and directories are only writable for their owner, but readable and
+executable for anyone.</para>
+
+<para>The LFS variable should of course be set to the mount point you
+chose.</para>
+
+<para>The LC_ALL variable controls the localization of certain programs,
+making their messages follow the conventions of a specified country. If your
+host system uses a version of Glibc older than 2.2.4,
+having LC_ALL set to something other than "POSIX" or "C" during this chapter
+may cause trouble if you exit the chroot environment and wish to return later.
+By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that
+everything will work as expected in the chroot environment.</para>
+
+<para>We prepend <filename>/tools/bin</filename> to the standard PATH so
+that, as we move along through this chapter, the tools we build will get used
+during the rest of the building process.</para>
+
+<para>Finally, to have our environment fully prepared for building the
+temporary tools, source the just-created profile:</para>
+
+<screen><userinput>source ~/.bash_profile</userinput></screen>
 
-<para>Besides all those packages, you'll also need several patches. These
-correct tiny mistakes in the packages that should be fixed by the maintainer,
-or just make some small modifications to bend things our way. You'll need the
-following:</para>
-
-<literallayout>
-Bash Patch - &bash-patch-size;:
-<ulink url="&patches-root;&bash-patch;"/>
-
-Bison Attribute Patch - &bison-patch-size;:
-<ulink url="&patches-root;&bison-patch;"/>
-
-Coreutils Hostname Patch - &coreutils-hostname-patch-size;:
-<ulink url="&patches-root;&coreutils-hostname-patch;"/>
-
-Coreutils Posixver Patch - &coreutils-posixver-patch-size;:
-<ulink url="&patches-root;&coreutils-posixver-patch;"/>
-
-Coreutils Uname Patch - &coreutils-uname-patch-size;:
-<ulink url="&patches-root;&coreutils-uname-patch;"/>
-
-Ed Mkstemp Patch - &ed-patch-size;:
-<ulink url="&patches-root;&ed-patch;"/>
-
-Expect Spawn Patch - &expect-patch-size;:
-<ulink url="&patches-root;&expect-patch;"/>
+</sect1>
 
-GCC No-Fixincludes Patch - &gcc-nofixincludes-patch-size;:
-<ulink url="&patches-root;&gcc-nofixincludes-patch;"/>
 
-GCC Specs Patch - &gcc-specs-patch-size;:
-<ulink url="&patches-root;&gcc-specs-patch;"/>
+<sect1 id="prepare-aboutsbus">
+<title>About SBUs</title>
+<?dbhtml filename="aboutsbus.html" dir="chapter04"?>
 
-GCC-2 Patch - &gcc-2953-patch-size;:
-<ulink url="&patches-root;&gcc-2953-patch;"/>
+<para>Most people would like to know beforehand how long it approximately
+takes to compile and install each package. But "Linux from Scratch" is built
+on so many different systems, it is not possible to give actual times that are
+anywhere near accurate: the biggest package (Glibc) won't take more than
+twenty minutes on the fastest systems, but will take something like three days
+on the slowest -- no kidding. So instead of giving actual times, we've come up
+with the idea of using the <emphasis>Static Binutils Unit</emphasis>
+(abbreviated to <emphasis>SBU</emphasis>).</para>
 
-GCC-2 No-Fixincludes Patch - &gcc-2953-no-fixinc-patch-size;:
-<ulink url="&patches-root;&gcc-2953-no-fixinc-patch;"/>
+<para>It works like this: the first package you compile in this book is the
+statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
+takes to compile this package is what we call the "Static Binutils Unit" or
+"SBU". All other compile times will be expressed relative to this time.</para>
 
-GCC-2 Return-Type Patch - &gcc-2953-returntype-fix-patch-size;:
-<ulink url="&patches-root;&gcc-2953-returntype-fix-patch;"/>
+<para>For example, the time it takes to build the static version of GCC is
+&gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
+to compile and install the static Binutils, then you know it will take
+approximately 45 minutes to build the static GCC. Fortunately, most build times
+are much shorter than the one of Binutils.</para>
 
-Inetutils No-Server-Man-Pages Patch - &inetutils-no-server-man-pages-patch-size;:
-<ulink url="&patches-root;&inetutils-no-server-man-pages-patch;"/>
+<para>Note that if the system compiler on your host is GCC-2 based, the SBUs
+listed may end up being 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% slower.</para>
 
-Kbd More-Programs Patch - &kbd-patch-size;:
-<ulink url="&patches-root;&kbd-patch;"/>
+<para>Also note that SBUs don't work well for SMP-based machines. But if you're
+so lucky as to have multiple processors, chances are that your system is so fast
+that you won't mind.</para>
 
-Man 80-Columns Patch - &man-80cols-patch-size;:
-<ulink url="&patches-root;&man-80cols-patch;"/>
+<para>If you wish to see actual timings for specific machines, have a look at
+<ulink url="&lfs-root;~bdubbs/"/>.</para>
 
-Net-tools Mii-Tool-Gcc33 Patch - &net-tools-mii-patch-size;:
-<ulink url="&patches-root;&net-tools-mii-patch;"/>
+</sect1>
 
-Perl Libc Patch - &perl-libc-patch-size;:
-<ulink url="&patches-root;&perl-libc-patch;"/>
-</literallayout>
 
-<para>In addition to the above required patches, there exist a number of
-optional ones created by the LFS community. Most of these solve slight
-problems, or enable some functionality that's not enabled by default.
-Feel free to examine the patches database, located at <ulink
-url="&lfs-root;patches/"/>, and pick any additional patches you wish to
-use.</para>
+<sect1 id="prepare-abouttestsuites">
+<title>About the test suites</title>
+<?dbhtml filename="abouttestsuites.html" dir="chapter04"?>
+
+<para>Most packages provide a test suite. Running the test suite for a newly
+built package is generally a good idea, as it can provide a nice sanity check
+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 -- GCC, Binutils, and Glibc -- are of
+the utmost importance due to their central role in a properly functioning
+system. But be warned, the test suites for GCC and Glibc can take a very long
+time to complete, especially on slower hardware.</para>
+
+<note><para>Experience has shown us 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 weird and inexplicable failures. Not only
+that, the tools built in <xref linkend="chapter-temporary-tools"/> are
+temporary and eventually discarded. For the average reader of this book we
+recommend <emphasis>not</emphasis> to run the test suites in <xref
+linkend="chapter-temporary-tools"/>. The instructions for running those test
+suites are still provided for the benefit of testers and developers, but they
+are strictly optional for everyone else.</para></note>
+
+<para>A common problem when running the test suites for Binutils and GCC is
+running out of pseudo terminals (PTYs for short). The symptom is a very high
+number of failing tests. This can happen for several reasons, but the most
+likely cause is that the host system doesn't have the
+<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
+more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
+
+<para>Sometimes package test suites will give false failures. You can
+consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
+failures are normal. This applies to all tests throughout the book.</para>
 
 </sect1>
 
-</chapter>
 
+</chapter>
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index 9217c1831..f8724b46b 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -23,9 +23,9 @@ Since the packages compiled here are merely temporary, we don't want
 them to pollute the soon-to-be LFS system.</para>
 
 <para>Before issuing the build instructions for a package you are expected to
-have already unpacked it as user <emphasis>lfs</emphasis> (explained shortly),
-and to have performed a <userinput>cd</userinput> into the created directory.
-The build instructions assume that you are using the <command>bash</command>
+have already unpacked it as user <emphasis>lfs</emphasis>, and to have
+performed a <userinput>cd</userinput> into the created directory. The build
+instructions assume that you are using the <command>bash</command>
 shell.</para>
 
 <para>Several of the packages are patched before compilation, but only when
@@ -50,21 +50,12 @@ reinstalled further on. Only for three packages you will need to keep the
 source and build directories around for a while, so their contents can be used
 by later commands. Do not miss the reminders.</para>
 
-<para>Now first check that your LFS environment variable is set up
-properly:</para>
-
-<screen><userinput>echo $LFS</userinput></screen>
-
-<para>Make sure the output shows the path to your LFS partition's mount
-point, which is <filename class="directory">/mnt/lfs</filename> if you
-followed our example.</para>
-
 </sect1>
 
 
-<sect1 id="ch-tools-toolchaintechnotes">
-<title>Toolchain technical notes</title>
-<?dbhtml filename="toolchaintechnotes.html" dir="chapter05"?>
+<sect1 id="tools-technicalnotes">
+<title>Technical notes</title>
+<?dbhtml filename="technicalnotes.html" dir="chapter05"?>
 
 <para>This section attempts to explain some of the rationale and technical
 details behind the overall build method. It's not essential that you understand
@@ -217,8 +208,12 @@ we mentioned above. Once this Glibc is installed into
 the toolchain defaults, then proceed for real in building the rest of the
 target LFS system.</para>
 
-<sect2>
+</sect1>
+
+
+<sect1 id="tools-aboutlinking">
 <title>Notes on static linking</title>
+<?dbhtml filename="aboutlinking.html" dir="chapter05"?>
 
 <para>Most programs have to perform, beside their specific task, many rather
 common and sometimes trivial operations. These include allocating memory,
@@ -257,179 +252,6 @@ independently of the host system. However, it's worth noting that an overall
 successful LFS build can still be achieved when the first two packages are
 built dynamically.</para>
 
-</sect2>
-
-</sect1>
-
-
-<sect1 id="ch-tools-creatingtoolsdir">
-<title>Creating the $LFS/tools directory</title>
-<?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?>
-
-<para>All programs compiled in this chapter will be installed under <filename
-class="directory">$LFS/tools</filename> to keep them separate from the
-programs compiled in the next chapter. The programs compiled here are only
-temporary tools and won't be a part of the final LFS system and by keeping them
-in a separate directory, we can later easily throw them away.</para>
-
-<para>Later on you might wish to search through the binaries of your system to
-see what files they make use of or link against. To make this searching easier
-you may want to choose a unique name for the directory in which the temporary
-tools are stored. Instead of the simple "tools" you could use something like
-"tools-for-lfs". However, you'll need to be careful to adjust all references to
-"tools" throughout the book -- including those in any patches, notably the
-GCC Specs Patch.</para>
-
-<para>Create the required directory by running the following:</para>
-
-<screen><userinput>mkdir $LFS/tools</userinput></screen>
-
-<para>The next step is to create a <filename>/tools</filename> symlink on
-your host system. It will point to the directory we just created on the LFS
-partition:</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 the info page before
-reporting what you may think is an error.</para></note>
-
-<para>The created symlink enables us to compile our toolchain so that it always
-refers to <filename>/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) <emphasis>and</emphasis> in the next (when we are chrooted to
-the LFS partition).</para>
-
-</sect1>
-
-
-<sect1 id="ch-tools-addinguser">
-<title>Adding the user lfs</title>
-<?dbhtml filename="addinguser.html" dir="chapter05"?>
-
-<para>When logged in as <emphasis>root</emphasis>, making a single mistake
-can damage or even wreck your system. Therefore we recommend that you
-build the packages in this chapter as an unprivileged user. You could
-of course use your own user name, but to make it easier to set up a clean
-work environment we'll create a new user <emphasis>lfs</emphasis> and
-use this one during the installation process. As <emphasis>root</emphasis>,
-issue the following command to add the new user:</para>
-
-<screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen>
-
-<para>The meaning of the switches:</para>
-
-<itemizedlist>
-<listitem><para><userinput>-s /bin/bash</userinput>: This makes
-<userinput>bash</userinput> the default shell for user
-<emphasis>lfs</emphasis>.</para></listitem>
-
-<listitem><para><userinput>-m -k /dev/null</userinput>: These create a home
-directory for <emphasis>lfs</emphasis>, while preventing the files from a
-possible <filename>/etc/skel</filename> being copied into it.</para></listitem>
-</itemizedlist>
-
-<para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
-this new user a password:</para>
-
-<screen><userinput>passwd lfs</userinput></screen>
-
-<para>Now grant this new user <emphasis>lfs</emphasis> full access to
-<filename class="directory">$LFS/tools</filename> by giving it ownership
-of the directory:</para>
-
-<screen><userinput>chown lfs $LFS/tools</userinput></screen>
-
-<para>If you made a separate working directory as suggested, give user
-<emphasis>lfs</emphasis> ownership of this directory too:</para>
-
-<screen><userinput>chown lfs $LFS/sources</userinput></screen>
-
-<para>Next, login as user <emphasis>lfs</emphasis>. 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 "<command>-</command>" instructs <command>su</command> to start a
-<emphasis>login</emphasis> shell.</para>
-
-</sect1>
-
-
-<sect1 id="ch-tools-settingenviron">
-<title>Setting up the environment</title>
-<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
-
-<para>We're going to set up a good working environment by creating two new
-startup files for the <command>bash</command> shell. While logged in as
-user <emphasis>lfs</emphasis>, issue the following command to create a new
-<filename>.bash_profile</filename>:</para>
-
-<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
-exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
-<userinput>EOF</userinput></screen>
-
-<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
-the initial shell is a <emphasis>login</emphasis> shell which reads the
-<filename>/etc/profile</filename> of your host (probably containing some
-settings of environment variables) and then <filename>.bash_profile</filename>.
-The <command>exec env -i ... /bin/bash</command> command in the latter file
-replaces the running shell with a new one with a completely empty environment,
-except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
-potentially hazardous environment variables from the host system leak into our
-build environment. The technique used here is a little strange, but it achieves
-the goal of enforcing a clean environment.</para>
-
-<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
-which doesn't read the <filename>/etc/profile</filename> or
-<filename>.bash_profile</filename> files, but reads the
-<filename>.bashrc</filename> file instead. Create this latter file now:</para>
-
-<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
-set +h
-umask 022
-LFS=/mnt/lfs
-LC_ALL=POSIX
-PATH=/tools/bin:/bin:/usr/bin
-export LFS LC_ALL PATH
-<userinput>EOF</userinput></screen>
-
-<para>The <command>set +h</command> command turns off
-<command>bash</command>'s hash function. Normally hashing is a useful
-feature: <command>bash</command> uses a hash table to remember the
-full pathnames of executable files to avoid searching the PATH time and time
-again to find the same executable. However, we'd like the new tools to be
-used as soon as they are installed. By switching off the hash function, our
-"interactive" commands (<command>make</command>,
-<command>patch</command>, <command>sed</command>,
-<command>cp</command> and so forth) will always use
-the newest available version during the build process.</para>
-
-<para>Setting the user file-creation mask to 022 ensures that newly created
-files and directories are only writable for their owner, but readable and
-executable for anyone.</para>
-
-<para>The LFS variable should of course be set to the mount point you
-chose.</para>
-
-<para>The LC_ALL variable controls the localization of certain programs,
-making their messages follow the conventions of a specified country. If your
-host system uses a version of Glibc older than 2.2.4,
-having LC_ALL set to something other than "POSIX" or "C" during this chapter
-may cause trouble if you exit the chroot environment and wish to return later.
-By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that
-everything will work as expected in the chroot environment.</para>
-
-<para>We prepend <filename>/tools/bin</filename> to the standard PATH so
-that, as we move along through this chapter, the tools we build will get used
-during the rest of the building process.</para>
-
-<para>Finally, to have our environment fully prepared for building the
-temporary tools, source the just-created profile:</para>
-
-<screen><userinput>source ~/.bash_profile</userinput></screen>
-
 </sect1>
 
 
@@ -490,7 +312,7 @@ made.</para>
 linker is something other than <filename>ld-linux.so.2</filename>, you
 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
 name of your platform's dynamic linker in the above commands. Refer back to
-<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
+<xref linkend="tools-technicalnotes"/> if necessary.</para></important>
 
 <para>Lastly, there is a possibility that some include files from the host
 system have found their way into GCC's private include dir. This can happen
@@ -531,9 +353,9 @@ First, redo the sanity check using <command>gcc</command> instead of
 is correct. You can check this by running <userinput>echo $PATH</userinput> and
 verifying that <filename class="directory">/tools/bin</filename> is at the head
 of the list. If the PATH is wrong it could mean you're not logged in as user
-<emphasis>lfs</emphasis> or something went wrong back in
-<xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
-the specs file amendment above. In this case redo the specs file amendment
+<emphasis>lfs</emphasis> or something went wrong back in <xref
+linkend="prepare-settingenvironment"/>. Third, something may have gone wrong
+with the specs file amendment above. In this case redo the specs file amendment
 ensuring to cut-and-paste the commands as was recommended.</para>
 
 <para>Once you are satisfied that all is well, clean up the test files:</para>
diff --git a/chapter06/chapter06.xml b/chapter06/chapter06.xml
index 6bb1b5bf4..b8ab3f3a9 100644
--- a/chapter06/chapter06.xml
+++ b/chapter06/chapter06.xml
@@ -424,7 +424,7 @@ intended change was actually made.</para>
 linker is something other than <filename>ld-linux.so.2</filename>, you
 <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
 name of your platform's dynamic linker in the above commands. Refer back to
-<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
+<xref linkend="tools-technicalnotes"/> if necessary.</para></important>
 
 <!-- HACK - Force some whitespace to appease tidy -->
 <literallayout></literallayout>
diff --git a/entities/book-structure.xml b/entities/book-structure.xml
index 08fc8c9bb..7b1d8fd01 100644
--- a/entities/book-structure.xml
+++ b/entities/book-structure.xml
@@ -10,28 +10,19 @@
 <!ENTITY c1-how SYSTEM "../chapter01/how.xml">
 <!ENTITY c1-changelog SYSTEM "../chapter01/changelog.xml">
 <!ENTITY c1-resources SYSTEM "../chapter01/contactinfo.xml">
+<!ENTITY c1-askforhelp SYSTEM "../chapter01/askforhelp.xml">
 
 <!ENTITY chapter02 SYSTEM "../chapter02/chapter02.xml">
-<!ENTITY c2-aboutlfs SYSTEM "../chapter02/aboutlfs.xml">
-<!ENTITY c2-aboutsbus SYSTEM "../chapter02/aboutsbus.xml">
-<!ENTITY c2-abouttestsuites SYSTEM "../chapter02/abouttestsuites.xml">
-<!ENTITY c2-askforhelp SYSTEM "../chapter02/askforhelp.xml">
 
 <!ENTITY chapter03 SYSTEM "../chapter03/chapter03.xml">
-<!ENTITY c3-introduction SYSTEM "../chapter03/introduction.xml">
-<!ENTITY c3-creatingpart SYSTEM "../chapter03/creatingpart.xml">
-<!ENTITY c3-creatingfs SYSTEM "../chapter03/creatingfs.xml">
-<!ENTITY c3-mounting SYSTEM "../chapter03/mounting.xml">
 
 <!ENTITY chapter04 SYSTEM "../chapter04/chapter04.xml">
 
 <!ENTITY chapter05 SYSTEM "../chapter05/chapter05.xml">
 
 <!ENTITY chapter06 SYSTEM "../chapter06/chapter06.xml">
-<!ENTITY c6-aboutdebug SYSTEM "../chapter06/aboutdebug.xml">
 
 <!ENTITY chapter07 SYSTEM "../chapter07/chapter07.xml">
-<!ENTITY c7-introduction SYSTEM "../chapter07/introduction.xml">
 <!ENTITY c7-usage SYSTEM "../chapter07/usage.xml">
 <!ENTITY c7-setclock SYSTEM "../chapter07/setclock.xml">
 <!ENTITY c7-loadkeys SYSTEM "../chapter07/loadkeys.xml">
diff --git a/preface/organization.xml b/preface/organization.xml
index 33fd4002c..474f33773 100644
--- a/preface/organization.xml
+++ b/preface/organization.xml
@@ -4,37 +4,34 @@
 
 <para>This book is divided into the following four parts:</para>
 
-<sect2>
-<title>Part I - Introduction</title>
+<itemizedlist>
 
-<para>Part I explains a few important things on how to proceed with the
-installation, and gives meta information about the book (version, changelog,
-acknowledgments, associated mailing lists, and so on).</para>
-</sect2>
-
-<sect2>
-<title>Part II - Preparing for the build</title>
+<listitem>
+<para>Part I explains in some detail how the LFS system is built, lists the
+changes made to the book since the last version, and gives hints on how to
+find help in case you run into trouble.</para>
+</listitem>
 
+<listitem>
 <para>Part II describes how to prepare for the building process: making a
-partition, downloading the packages, and compiling temporary tools.</para>
-</sect2>
-
-<sect2>
-<title>Part III - Building the LFS system</title>
+partition, downloading the packages, setting up a good working environment,
+and compiling temporary tools.</para>
+</listitem>
 
+<listitem>
 <para>Part III guides you through the building of the LFS system: compiling
 and installing all the packages one by one, setting up the boot scripts, and
 installing the kernel. The resulting basic Linux system is the foundation
 upon which you can build other software, to extend your system in the way
 you like.</para>
-</sect2>
-
-<sect2>
-<title>Part IV - Appendices</title>
+</listitem>
 
+<listitem>
 <para>Part IV consists of two appendices. The first is an alphabetical list of
 all the installed packages, and the second an alphabetical list of all the
 installed programs and libraries, mentioning which package installed it.</para>
-</sect2>
+</listitem>
+
+</itemizedlist>
 
 </sect1>