diff --git a/baremetal.rst b/baremetal.rst
index b029ba5..f424b32 100644
--- a/baremetal.rst
+++ b/baremetal.rst
@@ -6,7 +6,7 @@
 
 :Author: Tim Daneliuk (tundra@tundraware.com)
 
-:Version: ``$Id: baremetal.rst,v 1.109 2014/08/23 00:42:36 tundra Exp $``
+:Version: ``$Id: baremetal.rst,v 1.110 2014/08/23 00:50:14 tundra Exp $``
 
 
 Précis
@@ -25,10 +25,11 @@
 
 
 .. warning:: Doing this wrong can **clobber your systems and its
-              data**.  What you see here is just a simple example for
-              purposes of explaining the general approach. **You should
-              not trust this approach unless you prove these
-              procedures are satisfactory in YOUR OWN ENVIRONMENT.**
+             data**.  What you see here is just a simple example for
+             purposes of explaining the general approach. **You should
+             not trust this approach unless you prove these
+             procedures are satisfactory in YOUR OWN ENVIRONMENT.**
+         
 
 
 General Approach
@@ -134,12 +135,12 @@
 Because this is partition based - that is, you are imaging and
 restoring *partitions* not disks - you can actually restore to a
 physical disk that is a different size than the one from which the
-image was taken so long as there is room for all the data on the new
-disk.  This makes it easy to lay your operating system down on a new,
-larger disk.  Do an image of the old disk, restore it to the new disk,
-and then, while still running under the ``System Rescue CD``, run
-``parted`` or ``gparted`` to expand the partitions to use the
-additional disk space.
+image was taken.  Obviously, there has to be enough room for all the
+data on the new disk.  This makes it easy to lay your operating system
+down on a new, larger disk.  Do an image of the old disk, restore it
+to the new disk, and then, while still running under the ``System
+Rescue CD``, run ``parted`` or ``gparted`` to expand the partitions to
+use the additional disk space.
 
 .. warning:: **Do NOT try this with a machine that boots from SAN!!!**
              SAN-booted machines put information into their
@@ -190,18 +191,23 @@
 
 - This works well for Unix-style operating systems because they boot with
   a full complement of drivers and discover what is on the machine
-  at boot time.  However, Windows may have a fit if you do this,
-  especially if you restore to machine substantially different than
-  the one where the backup image was created.  First of all, Windows
-  doesn't carry around any drivers it doesn't think it needs.  Secondly,
-  Windows licensing logic is designed to prevent this sort of thing
-  as a deterrent to software piracy.  
+  at boot time.
 
-- This approach assumes the disk us partitioned using standard ``fdisk``
-  type tools.  Some OSs - notably ``FreeBSD`` - have the option to use
-  their own disk slicing and labeling tools.  This general approach will
-  work, but you have to tweak it to ensure you preserve those boot loaders
-  and custom slicing tables.
+- However, Windows may have a fit if you do this, especially if you
+  restore to machine substantially different than the one where the
+  backup image was created.  First of all, Windows doesn't carry
+  around any drivers it doesn't think it needs.  Secondly, Windows
+  licensing logic is designed to prevent this sort of thing as a
+  deterrent to software piracy.  This doesn't mean it cannot be done -
+  it can - but it may take some extra fiddling after you reboot
+  Windows.
+
+- This approach assumes the disk us partitioned using standard
+  ``fdisk`` type tools.  Some OSs - notably the ``*BSD`` varianst (aka
+  "God's Own Operating System") - have the option to use their own disk
+  slicing and labeling tools.  This general approach will work, but
+  you have to tweak it to ensure you preserve those boot loaders and
+  custom slicing tables.
 
 
 Copyright