diff --git a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
index caa54f5984..ef2711bbc4 100644
--- a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
+++ b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
@@ -21,6 +21,12 @@ $FreeBSD$
   <sect1 id="boot-synopsis">
     <title>Synopsis</title>
 
+    <indexterm><primary>BIOS</primary></indexterm>
+    <indexterm><primary>firmware</primary></indexterm>
+    <indexterm><primary>POST</primary></indexterm>
+    <indexterm><primary>IA-32</primary></indexterm>
+    <indexterm><primary>booting</primary></indexterm>
+    <indexterm><primary>system initialization</primary></indexterm>
     <para>This chapter is an overview of the boot and system
       initialization process, starting from the BIOS (firmware) POST,
       to the first user process creation.  Since the initial steps of
@@ -44,6 +50,10 @@ $FreeBSD$
       <listitem><para>kernel initialization</para></listitem>
     </itemizedlist>
 
+    <indexterm><primary>BIOS POST</primary></indexterm>
+    <indexterm><primary>boot0</primary></indexterm>
+    <indexterm><primary>boot2</primary></indexterm>
+    <indexterm><primary>loader</primary></indexterm>
     <para>The <literal>boot0</literal> and <literal>boot2</literal>
       stages are also referred to as <emphasis>bootstrap stages 1 and
       2</emphasis> in &man.boot.8; as the first steps in FreeBSD's
@@ -176,6 +186,7 @@ Timecounter "i8254"  frequency 1193182 Hz</screen></para></entry>
   <sect1 id="boot-boot0">
     <title><literal>boot0</literal> stage</title>
 
+    <indexterm><primary>MBR</primary></indexterm>
     <para>Take a look at the file <filename>/boot/boot0</filename>.
       This is a small 512-byte file, and it is exactly what FreeBSD's
       installation procedure wrote to your harddisk's MBR if you chose
@@ -310,6 +321,7 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
 	btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \
 		-o boot2.ld -P 1 boot2.bin</programlisting>
 
+    <indexterm><primary>BTX</primary></indexterm>
     <para>This Makefile snippet shows that &man.btxld.8; is used to
       link the binary.  BTX, which stands for BooT eXtender, is a
       piece of code that provides a protected mode environment for the
@@ -317,6 +329,7 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
       <literal>boot2</literal> is a BTX client, i.e. it uses the
       service provided by BTX.</para>
 
+    <indexterm><primary>linker</primary></indexterm>
     <para>The <application>btxld</application> utility is the linker.
       It links two binaries together.  The difference between
       &man.btxld.8; and &man.ld.1; is that
@@ -331,6 +344,7 @@ boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
       prepares a simple environment before calling the client.  This
       includes:</para>
 
+    <indexterm><primary>virtual v86 mode</primary></indexterm>
     <itemizedlist>
       <listitem><para>virtual v86 mode.  That means, the BTX is a v86
         monitor.  Real mode instructions like pushf, popf, cli, sti, if
@@ -473,6 +487,7 @@ ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386  -export-dynamic \
 -dynamic-linker /red/herring -o kernel -X locore.o \
 &lt;lots of kernel .o files&gt;</programlisting>
 
+    <indexterm><primary>ELF</primary></indexterm>
     <para>A few interesting things can be seen in this line.  First,
       the kernel is an ELF dynamically linked binary, but the dynamic
       linker for kernel is <filename>/red/herring</filename>, which is
@@ -645,6 +660,7 @@ begin:</programlisting>
 	</listitem>
       </itemizedlist>
 
+    <indexterm><primary>parameters</primary></indexterm>
       <para>What <function>init386()</function> first does is
         initialize the tunable parameters passed from bootstrap.  This
         is done by setting the environment pointer (envp) and calling
@@ -682,6 +698,7 @@ begin:</programlisting>
         kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.dflssiz,
         kern.maxssiz, kern.sgrowsiz</literal>.</para>
 
+    <indexterm><primary>Global Descriptors Table (GDT)</primary></indexterm>
       <para>Then <function>init386()</function> prepares the Global
         Descriptors Table (GDT).  Every task on an x86 is running in
         its own virtual address space, and this space is addressed by
@@ -726,6 +743,7 @@ union descriptor gdt[NGDT * MAXCPU];	/* global descriptor table */
         indices of the GDT.  for example, an actual selector for the
         kernel code (GCODE_SEL) has the value 0x08.</para>
 
+    <indexterm><primary>Interrupt Descriptor Table (IDT)</primary></indexterm>
       <para>The next step is to initialize the Interrupt Descriptor
         Table (IDT).  This table is to be referenced by the processor
         when a software or hardware interrupt occurs.  For example, to
@@ -758,6 +776,7 @@ struct gate_descriptor *idt = &amp;idt0[0];	/* interrupt descriptor table */
         privileges.</para>
 
       <para>Console and DDB are then initialized:</para>
+      <indexterm><primary>DDB</primary></indexterm>
 
       <programlisting><filename>sys/i386/i386/machdep.c:</filename>
 	cninit();
@@ -826,6 +845,7 @@ struct gate_descriptor *idt = &amp;idt0[0];	/* interrupt descriptor table */
     <para>Although the sysinit framework is described in the
       Developers' Handbook, I will discuss the internals of it.</para>
 
+    <indexterm><primary>sysinit objects</primary></indexterm>
     <para>Every system initialization object (sysinit object) is
       created by calling a SYSINIT() macro.  Let us take as example an
       <literal>announce</literal> sysinit object.  This object prints