some whitespacing in the general bootloader info

1 files changed, 8 insertions, 1 deletions

diff --git a/en-US/BOOT-general.xml b/en-US/BOOT-general.xml
index cff1e18..c4833a9 100644
--- a/en-US/BOOT-general.xml
+++ b/en-US/BOOT-general.xml
@@ -9,6 +9,7 @@
   <para>
     To boot a modern operating system, a computer must identify the kernel, storage, and various options at the time of booting.  Software called a bootloader keeps track of these parameters, manages settings for different operating systems, and loads the kernel.
   </para>
+  <bridgehead>Bootloaders on BIOS systems</bridgehead>
   <para>
     Historically, bootloaders have been installed into the first part of a drive, known as the Master Boot Record (MBR) or Boot Sector.  The computer's firmware, or BIOS, would check the boot sector for bootable code on startup, and load whatever it found.  As bootloaders became more complex, and therefore required more space, the MBR came to contain only a pointer to the second stage of the bootloader.
   </para>
@@ -18,9 +19,15 @@
   <para>
     BIOS is short for Basic Input Output System, and the software is indeed very simple. BIOS systems had a number of technical limitations, such as being unable to boot from disks larger than 2 TB and extremely limited interfaces.  GUID Partition Table (GPT) partitioning schemes also came with larger drives, overcoming the MBR partitioning scheme's 4 partition limit. To overcome these issues and add new features, a newer firmware implementation was developed, called the Unified Extensible Firmware Interface.
   </para>
+
+  <bridgehead>Bootloaders on EFI systems</bridgehead>
+  <para>
+    Instead of reading the bootloader from the drive, UEFI systems store information about available bootloaders right on the system firmware. Each boot entry is persistently stored on the firmware, and describes the location of the entry's bootloader.
+  </para>
   <para>
-    Instead of reading the bootloader from the drive, UEFI systems store information about available bootloaders right on the system firmware. The bootloaders themselves and sometimes small applications such as memory testing utilites are stored on the UEFI system partition. This partition is usually a FAT filesystem, has a standardized partition identifier, and is mounted at <filename>/boot/efi</filename>. Each operating system places files required for booting in a dedicated directory of this partition, and the boot entry in the firmware points to these files. UEFI systems will usually also support BIOS style booting for compatibility reasons, using a feature called the Compatibility Support Module (CSM).  
+    The bootloaders themselves, and sometimes small applications such as memory testing utilites, are stored on the UEFI system partition. This partition contains a FAT filesystem, has a standardized partition identifier, and is mounted at <filename class="directory">/boot/efi</filename>. Each operating system places files required for booting in a dedicated directory of this partition, and the boot entry in the firmware points to these files. UEFI systems will often also support BIOS style booting for compatibility reasons, using a feature called the Compatibility Support Module (CSM).  
   </para>
+  <bridgehead>Bootloader data</bridgehead>
   <para>
     On Linux systems, the data used by the bootloader is traditionally contained in a <systemitem>boot partition</systemitem>, mounted at and known as <filename>/boot</filename>.  The boot partition contains the kernel, a read only filesystem that holds tools used by the kernel during bootup, called an <systemitem>initramfs</systemitem>, and files for the menus and for the bootloader itself.  These files were traditionally placed on a different partition because the bootloader did not support complex storage arrangements, and could not read the kernel and initramfs from them.  Because a simple, separate boot also allows for easier disaster recovery, the practice has continued to this day.
   </para>