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

5 files changed, 131 insertions, 174 deletions

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>