Index: BOOK/chroot/x86/before-chroot.xml
===================================================================
--- BOOK/chroot/x86/before-chroot.xml	(revision 42a32ea2f421ea5597e9bd00c358fd98f0e39a2b)
+++ BOOK/chroot/x86/before-chroot.xml	(revision 42a32ea2f421ea5597e9bd00c358fd98f0e39a2b)
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../../general.ent">
+  %general-entities;
+]>
+
+<sect1 id="ch-chroot-before-chroot">
+  <?dbhtml filename="before-chroot.html"?>
+  <title>Before Entering the Chroot Environment</title>
+
+  <sect2 role="determining-ifneeded">
+    <title>Determining if steps need to be taken</title>
+
+    <para>Before we can enter the chroot we have to make sure that the system is
+    in the proper state. From this point on the <envar>${CLFS_TARGET}</envar>
+    enviornment variable will no longer exist, so it will have no bearing on the
+    rest of the book. From this point on, most packages will rely on
+    <command>config.guess</command> provided by
+    <xref linkend="ch-system-automake"/>. Packages that do not use autotools
+    either do not care about the target triplet, or they have their own means
+    of determining it's value.</para>
+
+    <para>In both cases, The information about the host cpu used to determine
+    the target triplet is gathered from the same place,
+    <command>uname -m</command>. Executing this command outside of the chroot
+    aswell as inside the chroot will have the exact same output.</para>
+
+   <para>If you're unsure if you're host and target have the same target
+    triplet, you can use this test to determine what the hosts target triplet
+    is and if you need to take any steps to ensure that you don't build for the
+    wrong architecture. Extract the <xref linkend="ch-system-automake"/> tarball
+    and <command>cd</command> into the created directory. Then execute the
+    following to see what they detected target triplet is by
+    <command>config.guess</command>.</para>
+
+<screen><userinput>lib/config.guess</userinput></screen>
+
+    <para>If the output of that command does not equal what is in
+    <envar>${CLFS_TARGET}</envar> then you need to read on. If it does then you
+    can safely continue onto <xref linkend="ch-chroot-chroot"/>.</para>
+
+  </sect2>
+
+  <sect2 role="using-setarch">
+    <title>Using Setarch</title>
+
+    <para>If your host has a tool called <command>setarch</command> this may
+    solve your problems. The reason for saying may is because on a architecture
+    such as x86_64, using <command>setarch linux32 uname -m</command> will only
+    ever output i686. It is not possible to get an output of i486 or i586.</para>
+
+    <para>To test if setarch does everything you need it to, execute the
+    following command from inside of the <xref linkend="ch-system-automake"/>
+    directory:</para>
+
+<screen><userinput>setarch linux32 lib/config.guess</userinput></screen>
+
+    <para>If the output of the command above equals what is in
+    <envar>${CLFS_TARGET}</envar> then you have a viable solution. You can
+    wrap the chroot command on the next page with
+    <command>setarch linux32</command>. It will look like the following:</para>
+
+<screen><userinput>setarch linux32 chroot "${CLFS}" /tools/bin/env -i \
+    HOME=/root TERM="${TERM}" PS1='\u:\w\$ ' \
+    PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
+    /tools/bin/bash --login +h</userinput></screen>
+
+    <para>If setarch works for you then you can safely continue onto
+    <xref linkend="ch-chroot-chroot"/>. If not, there is one more option
+    covered in this book.</para>
+
+  </sect2>
+
+  <sect2 role="using-uname_hack">
+    <title>Using a Uname Hack</title>
+
+    <para os="uua">The Uname Hack is a kernel module that modifies the output of
+    <command>uname -m</command> by directly changing the value of the
+    detected machine type. The kernel module will save the original value
+    and restore it when the module is unloaded.</para>
+
+    <variablelist os="uub" role="materials">
+      <varlistentry>
+        <term>Uname Hack (&uname_hack-version;) - &uname_hack-size;:</term>
+
+        <listitem>
+          <para>Home page: <ulink url="&uname_hack-home;"/></para>
+          <para>Download: <ulink url="&uname_hack-url;"/></para>
+          <para>MD5 sum: <literal>&uname_hack-md5;</literal></para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para os="uuc">Extract the tarball and <command>cd</command> into the
+    created directory. To build the Uname Hack you must have the kernel sources
+    for you currently running kernel available. Build the Uname Hack with the
+    following or similar command:</para>
+
+<screen os="uud"><userinput>make uname_hack_fake_machine=i486</userinput></screen>
+
+    <para os="uue">In the top level directory of the Uname Hack pacakage you
+    should see a file named uname_hack.ko. As soon as that module is loaded
+    into the running kernel the output of <command>uname -m</command> will be
+    affected immediately system-wide. Load the kernel module with the following
+    command:</para>
+
+<screen os="uuf"><userinput>insmod uname_hack.ko</userinput></screen>
+
+    <para os="uug">To test if the Uname Hack is working properly, execute the
+    following command from inside of the <xref linkend="ch-system-automake"/>
+    directory:</para>
+
+<screen os="uuh"><userinput>lib/config.guess</userinput></screen>
+
+    <para os="uui">The output of the above command should be the same as the
+    <envar>${CLFS_TARGET}</envar> enviornment variable. If this is not the
+    case, You can try and get help on the CLFS Support Mailing List or the
+    IRC Channel. See <xref linkend="ch-intro-askforhelp"/> for more
+    information.</para>
+
+  </sect2>
+
+</sect1>
