Fork: 0
tundra / baremetal
Browse code
Minor edits.
master
1 parent abbef34 commit 398a68988b2a516c2cfddbcec7693a4e16055ce3
@tundra tundra authored on 22 Aug 2014
Patch
Unified Split
Showing 1 changed file
View
58
■■■■■
 baremetal.rst
 
 
: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
------
linux command line tools*.
 
 
.. 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
-----------------
 
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
bootloaders about the boot LUN's WWID and the necessary
partitions and data partitions. But ... not tested.
 
- 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.
 
- 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.
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. 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
---------