Index: BOOK/bootable/alpha/aboot.xml
===================================================================
--- BOOK/bootable/alpha/aboot.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/alpha/aboot.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -16,5 +16,5 @@
   </indexterm>
 
-  <para os="a">Create a <filename>aboot.conf</filename> file defining aboot's boot
+  <para os="a">Create an <filename>aboot.conf</filename> file defining aboot's boot
   menu:</para>
 
Index: BOOK/bootable/alpha/kernel.xml
===================================================================
--- BOOK/bootable/alpha/kernel.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/alpha/kernel.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -27,5 +27,5 @@
 
     <para os="a3">The following sed prevents GCC from treating warnings as
-    errors when the kernel is compiled.</para>
+    errors when the kernel is compiled:</para>
 
 <screen os="a4"><userinput>sed -i "s/-Werror//" arch/alpha/kernel/Makefile</userinput></screen>
Index: BOOK/bootable/mips/arcload.xml
===================================================================
--- BOOK/bootable/mips/arcload.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/mips/arcload.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -43,5 +43,6 @@
 EOF</userinput></screen>
 
-  <para os="c">Now we use dvhtool to make the system bootable:</para>
+  <para os="c">Now we use <command>dvhtool</command> to make the system
+  bootable:</para>
 
 <screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash sash
Index: BOOK/bootable/mips64/arcload.xml
===================================================================
--- BOOK/bootable/mips64/arcload.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/mips64/arcload.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -43,5 +43,6 @@
 EOF</userinput></screen>
 
-  <para os="c">Now we use dvhtool to make the system bootable:</para>
+  <para os="c">Now we use <command>dvhtool</command> to make the system
+  bootable:</para>
 
 <screen os="d"><userinput>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64
Index: BOOK/bootable/ppc/yaboot.xml
===================================================================
--- BOOK/bootable/ppc/yaboot.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/ppc/yaboot.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -29,33 +29,35 @@
   in preparation for this step. The procedure involves writing the bootloader
   to a bootstrap partition and blessing it so that Open Firmware will boot from
-  it.  This is all handled by <command>ybin</command> the yaboot installer.</para>
+  it.  This is all handled by <command>ybin</command>, the yaboot installer.</para>
 
   <para os="d">Ybin writes an optional 'OS selector' menu into Open Firmware,
-  then writes yaboot and yaboot.conf to the bootstrap partition, blesses this,
-  and updates the boot device recorded in nvram. When booted, the OF provides
-  the initial menu to choose between linux, boot from CD, and e.g. OSX
-  (depending on what was in yaboot.conf). If you boot to 'linux', yaboot is
-  executed and lets you select which kernel to use.</para>
+  then writes yaboot and <filename>yaboot.conf</filename> to the bootstrap
+  partition, blesses this, and updates the boot device recorded in nvram. When
+  booted, the OF provides the initial menu to choose between linux, boot from
+  CD, and e.g. OSX (depending on what was in <filename>yaboot.conf</filename>).
+  If you boot to 'linux', yaboot is executed and lets you select which kernel
+  to use.</para>
 
   <para os="e">Images (kernels) are specified, together with any necessary path,
-  in yaboot.conf - the details are incorporated into the bootloader, but no attempt
-  is made to access or validate the paths until they are selected.  There are many
-  possible options that can be specified in yaboot.conf, see the man page for the
-  details.  Most people will be able to specify device=hd: (for a single hard disk),
-  but if you have multiple disks, or if you wish to be pedantic, you can specify the
+  in <filename>yaboot.conf</filename> - the details are incorporated into the
+  bootloader, but no attempt is made to access or validate the paths until
+  they are selected. There are many possible options that can be specified in
+  <filename>yaboot.conf</filename>, see the man page for the details. Most
+  people will be able to specify device=hd: (for a single hard disk), but if
+  you have multiple disks, or if you wish to be pedantic, you can specify the
   full OF path to the device, obtained by running <command>ofpath /dev/hdX</command>
   .</para>
 
   <para os="h">Using the above information, determine the appropriate designators
-  for the bootstrap partition and the root partition.  For the following example,
+  for the bootstrap partition and the root partition. For the following example,
   it is assumed that the bootstrap partition is <filename class="partition">hda2
-  </filename> and the root partition is <filename class="partition">hda7</filename>
-  .  We will also assume that you wish to be able to boot an OSX installation on
-  <filename class="partition">hda4</filename>.  Change these items as necessary
+  </filename> and the root partition is <filename class="partition">hda7</filename>.
+  We will also assume that you wish to be able to boot an OSX installation on
+  <filename class="partition">hda4</filename>. Change these items as necessary
   for your machine.</para>
 
   <para os="i">If your machine has a SATA disk, specify the partitions using
   <filename class="devicefile">/dev/sda7</filename> and so forth in the usual
-  way.  At least some of the distros specify a full OF path to the 'device' and
+  way. At least some of the distros specify a full OF path to the 'device' and
   to the image(s), such as
   <parameter>device=/ht@0,f2000000/pci@3/k2-sata-root@c/k2-sata@0/disk@0:</parameter>
Index: BOOK/bootable/x86_64-64/lilo.xml
===================================================================
--- BOOK/bootable/x86_64-64/lilo.xml	(revision 984ac82b4ebf1e608f83e8ff6d6671e1b068f866)
+++ BOOK/bootable/x86_64-64/lilo.xml	(revision 968933dadcbd0c345fa2a1795af2208c735790e2)
@@ -17,10 +17,9 @@
 
     <para os="a">Your shiny new CLFS system is almost complete. One of the
-      last things to do is to ensure that the system can be properly
-      booted. The instructions below apply only to computers using Lilo,
-      which in the context of this book means x86_64 Pure64 systems.
-      Information on <quote>boot loading</quote> for other architectures
-      should be available in the usual resource-specific locations for
-      those architectures.</para>
+    last things to do is to ensure that the system can be properly booted. The
+    instructions below apply only to computers using Lilo, which in the
+    context of this book means x86_64 Pure64 systems. Information on
+    <quote>boot loading</quote> for other architectures should be available in
+    the usual resource-specific locations for those architectures.</para>
 
   <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -28,45 +27,45 @@
   xpointer="xpointer(//*[@os='b'])"/>
 
-    <para os="c">If you have multiple systems on your machine using a
-      different bootloader such as GRUB, you may prefer to use that
-      instead - consult the appropriate documentation.  The rest of
-      this section assumes you are going to use Lilo.</para> 
+    <para os="c">If you have multiple systems on your machine using a different
+    bootloader such as GRUB, you may prefer to use that instead - consult the
+    appropriate documentation. The rest of this section assumes you are going
+    to use Lilo.</para> 
 
     <para os="d">Earlier, we compiled and installed the Lilo boot loader
-      software in preparation for this step. The procedure involves
-      writing a boot image to a specific location on the hard drive.
-      We highly recommend using mkrescue to create a Lilo boot CD
-      (using e.g. dvdrecord from dvdrtools) as a backup (this requires
-      loopback block device support in the kernel).</para>
+    software in preparation for this step. The procedure involves writing a
+    boot image to a specific location on the hard drive. We highly recommend
+    using <command>mkrescue</command> to create a Lilo boot CD (using e.g.
+    <command>dvdrecord</command> from dvdrtools) as a backup (this requires
+    loopback block device support in the kernel).</para>
 
-    <para os="e">Normally, you interact with Lilo by using the cursor
-      and <literal>enter</literal> keys to select from the available
-      option(s), but sometimes it is necessary to add other boot
-      options, such as e.g. 'init=/bin/bash' to debug boot failures.
-      The more your keyboard layout differs from the US qwerty layout,
-      the harder it becomes to type boot options unless Lilo knows
-      about your keyboard layout. So, we will create a key table for
-      Lilo (.ktl) file - at one point in the documentation these are
-      referred to as .klt files, which may be a typo, but has been
-      followed by some distros.  The name, and location, are not
-      important but it is conventional to put these in /boot with
-      the name representing the key layout.  For a British keyboard
-      layout, the following command will achieve this:</para> 
+    <para os="e">Normally, you interact with Lilo by using the cursor and
+    <literal>enter</literal> keys to select from the available option(s), but
+    sometimes it is necessary to add other boot options, such as e.g.
+    'init=/bin/bash' to debug boot failures. The more your keyboard layout
+    differs from the US qwerty layout, the harder it becomes to type boot
+    options unless Lilo knows about your keyboard layout. So, we will create a
+    key table for Lilo (.ktl) file - at one point in the documentation these
+    are referred to as .klt files, which may be a typo, but has been followed
+    by some distros. The name, and location, are not important but it is
+    conventional to put these in <filename class="directory">/boot</filename>
+    with the name representing the key layout. For a British keyboard layout,
+    the following command will achieve this:</para> 
 
 <screen os="f" role="nodump"><userinput>keytab-lilo.pl uk >/boot/uk.ktl</userinput></screen>
 
-    <para os="g">The argument to the command is the name of the keymap,
-      or if necessary you can specify the full path to the keymap.  Use
-      whatever is appropriate for your keyboard.</para>
+    <para os="g">The argument to the command is the name of the keymap, or if
+    necessary you can specify the full path to the keymap. Use whatever is
+    appropriate for your keyboard.</para>
 
-    <para os="h">When the x86 CLFS book used to include Lilo, it
-    advised against running it from chroot in case the MBR became
-    corrupted. Provided you have /proc mounted and have device special
-    files for the disks, it seems to be safe to run recent versions of
-    Lilo in chroot, although it is always possible that an updated
-    bootloader, or defective configuration file, may render the system
-    unbootable.</para>  
+    <para os="h">When the x86 CLFS book used to include Lilo, it advised
+    against running it from chroot in case the MBR became corrupted.
+    Provided you have <filename class="directory">/proc</filename> mounted
+    and have device special files for the disks, it seems to be safe to run
+    recent versions of Lilo in chroot, although it is always possible that
+    an updated bootloader, or defective configuration file, may render the
+    system unbootable.</para>  
 
-    <para os="i">The next step is to create /etc/lilo.conf:</para>
+    <para os="i">The next step is to create
+    <filename>/etc/lilo.conf</filename>:</para>
 
 <screen os="j" role="nodump"><userinput>cat &gt; /etc/lilo.conf &lt;&lt; "EOF"
@@ -100,8 +99,8 @@
 
     <para os="k">Replace &lt;bootdisk&gt; with the name of the disk (or
-      partition) on which the boot sector is to be written, e.g. sda.
-      Replace &lt;keytable&gt; with the name of the keytable file you
-      created, and &lt;partition&gt; with the name of the root partition
-      for the new system.
+    partition) on which the boot sector is to be written, e.g. sda.
+    Replace &lt;keytable&gt; with the name of the keytable file you
+    created, and &lt;partition&gt; with the name of the root partition
+    for the new system.
     </para>
 
@@ -116,21 +115,22 @@
 
   <note os='o'>
-    <para>People who have been used to GRUB need to be aware that
-      Lilo works differently - in particular, you cannot edit the
-      available choices as you can in the <command>grub</command> shell,
-      and Lilo records the block addresses of the kernels into the boot
-      blocks each time /sbin/lilo is run. This means that when you
-      compile a new kernel, you have to add it to /etc/lilo.conf and
-      rerun /sbin/lilo.  It also means that if you recompile an existing
-      kernel and save it to the same name you still have to rerun /sbin/lilo
-      in case it now occupies different blocks on the filesystem.</para>
+    <para>People who have been used to GRUB need to be aware that Lilo works
+    differently - in particular, you cannot edit the available choices as you
+    can in the <command>grub</command> shell, and Lilo records the block
+    addresses of the kernels into the boot blocks each time
+    <command>/sbin/lilo</command> is run. This means that when you compile a
+    new kernel, you have to add it to <filename>/etc/lilo.conf</filename> and
+    rerun <command>/sbin/lilo</command>. It also means that if you recompile
+    an existing kernel and save it to the same name you still have to rerun
+    <command>/sbin/lilo</command> in case it now occupies different blocks on
+    the filesystem.</para>
   </note>
 
-    <para os="p">If you are running multiple systems on this box and
-    using Lilo, it is a good idea to ensure that each system is running
-    the same version of Lilo, otherwise an old version may not be able
-    to overwrite the bootloader from a newer version.  You will also
-    need to ensure that the copies of /etc/lilo.conf on each system are
-    kept synchronised.</para>
+    <para os="p">If you are running multiple systems on this box and using
+    Lilo, it is a good idea to ensure that each system is running the same
+    version of Lilo, otherwise an old version may not be able to overwrite
+    the bootloader from a newer version. You will also need to ensure that the
+    copies of <filename>/etc/lilo.conf</filename> on each system are kept
+    synchronised.</para>
 
 </sect1>
