Fork: 0
tundra / tbku
Browse code
Edits, and some portion of the Gotchas section begun.
master
1 parent 2f55fef commit 9051046395d32a0c4cec06a121f313fbc2f91a88
@tundra tundra authored on 12 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
140
■■■■■
 Imaging-SUSE-Linux-With-tbku.txt
clone from smaller disks to larger ones or go the other way.
 
.. Note::
 
The whole point of doing imaging is to avoid having to
do custom configuration for each new installation.
The whole point of imaging is to avoid having to do
custom configuration for each new installation.
However, some configuration changes may be necessary
when the target hardware is different than the hardware
on which the master image was created. This is
discussed a bit more below in the `Gotchas`_ section.
when the target environment or hardware is different
than the system on which the master image was created.
This is discussed a bit more below in the `Gotchas`_
section.
 
 
Creating The Master Image
 
/usr
/var
 
Notice that we do *not* backup the dynamic kernel-created
filesystems like ``/dev`` or ``/proc``.
filesystems like ``/dev`` or ``/proc``, nor do we
backup utility mountpoints like ``/mnt`` or ``/tmp``.
 
3. Save the resulting ``.tar.gz`` (tarball) file somewhere
it can be retrieved later when you want to image another
machine. This can be a network server, a USB drive,
``Rescue System``.
 
2. Now we have to prepare the disk to receive a Linux
filesystem. The example below assumes we are installing on
/dev/hda - a PATA master on the first IDE controller - but
you can do what follows with any of the drives on your
system. Just substitute the device names as appropriate::
``/dev/hda`` - a PATA master on the first IDE controller -
but that the image came from a system that boots from the
first SCSI drive, ``/dev/sda``. Keep in mind you can do
what follows with any of the drives on your system. Just
substitute the device names as appropriate::
 
# Partition the drive:
 
fdisk /dev/hda
# OK, time to dump the image previously created by tbku
# onto our shiny new filesystem (make sure your current
# directory is still /mnt before doing this):
 
tar -xzvf /mnt/my-system-image.tar.gz
tar -xzvf mnt/my-system-image.tar.gz
 
# Now we have to make sure that the boot tables and
# default file mounts are correct - Our target system
# may have a different drive type or device (SCSI, sata,
# pata) than the system from which tbku took the image:
# may have a different drive type or device (SCSI, SATA,
# PATA) than the system from which tbku took the image:
 
# Edit /mnt/etc/fstab to reflect the partitioning
# you did with fdisk. Remember that drives can be
# named by device name (/dev/xxxx) or by the vendor
 
(fd0) /dev/fd0
(hd0) /dev/sda
 
# But our new system wants to boot from ATAPI so it
# But our new system wants to boot from PATA so it
# now needs to look like this:
 
(fd0) /dev/fd0
(hd0) /dev/hda
kernel /boot/vmlinuz-2.6.16.54-0.2.5-default root=/dev/sda2
resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.16.54-0.2.5-default
 
# As with the previous gfxmenu statement, make sure
# root (hd0,1) is right.
 
# All references to /dev/sda2 have to be changed to /dev/hda2
# All references to /dev/sda1 have to be changed to /dev/hda1
 
# Repeat this for every menu entry.
 
# Finally, lets make sure that the boot loader
# is properly installed and configured:
# Finally, let's make sure that the boot loader is
# properly installed and configured:
 
grub-install --root-directory=/mnt /dev/hda
 
 
We're DONE! Well ... maybe. If the hardware (chipset, CPU) of your
We're DONE! Well ... maybe. If the environment or hardware of your
target machine is similar/same as the machine from which you took the
original image OR if the kernel you plan to boot has support for your
new target hardware, you should just be able to boot and run at this
point. If not, read the following `Gotchas`_ section for further
explanation.
 
This may all seem complex the first time you do it, but after a couple
of times, you'll be able to do this in your sleep. Depending on how
large your backup image is, a complete system restore can typically be
done in less than an hour. That's less than an hour to a *completely
configured system* with all your applications, custom configuration,
and so on as you last left them.
of times, you'll be able to do this in your sleep. This is one of
those things where describing it is more complicated than just
doing it!
 
Depending on how large your backup image is, a complete system restore
can typically be done in less than an hour. That's less than an hour
to a *completely configured system* with all your applications, custom
configuration, and so on as you last left them.
 
 
Gotchas
=======
 
There are some circumstances where you cannot avoid doing some
configuration on the newly provisioned machine.
 
A. Network differences
 
If you use the approach described above to reprovision the
same machine - say after a disk failure or disk upgrade -
then that's all you have to do. Your "target" machine is
essentially identical to the one from which you got the backup
image ... the same machine.
 
However, there are some circumstances where you cannot avoid doing some
configuration on the newly provisioned machine. This is the case where
there is a significant difference between the machine that took the
snapshot and the machine receiving it. This might be because the
target machine has different hardware, needs a different IP address,
uses a different chipset, and so on.
 
There is no general way to solve these sorts of problems. You'll have
to dig through YAST (if the system boots at all) and/or the individual
configuration tools to correct things.
 
As a personal preference, I like to work directly with configuration
files from the command line whenever I can. If the target machine
will not boot, you sort of have no other choice. You'll have to
do something like this to get to those files to edit them.
Boot the installation CD and select ``Rescue System``, then
mount the target drive(s)::
 
mount /dev/hda2 /mnt
 
You can then edit the files found under /mnt.
 
 
 
A. Environmental Differences
 
B. Different Hardware
 
C. Different Chip Architectures
 
1. CPU Architecture
2. Motherboard Chipset
- Disk Controllers
- Network Controllers
- Audio
- Video
 
 
Author
======
 
http://docutils.sourceforge.net/rst.html
 
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.104 2008/03/12 22:40:44 tundra Exp $``
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.105 2008/03/12 23:06:34 tundra Exp $``