Fork: 0
tundra / tbku
Browse code
First complete version.
master
1 parent 91e7b46 commit 0b414e3b4d2656f769a6024a89332b59fdf7cb5a
@tundra tundra authored on 13 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
392
■■■■■
 Imaging-SUSE-Linux-With-tbku.txt
 
This document describes how to use the TundraWare Inc. ``tbku``
utility to "image" or "clone" SUSE Linux systems.
 
.. Note::
 
Most/Much of this will also be relevant to other Linux
distributions, though some of the fine points may be
different.
It's worth noting that most/much of this will also be relevant to
other Linux distributions, though some of the fine points may be
different.
 
 
.. Warning::
 
What follows is a description of activities that can (and
will) clobber the contents of a hard drive. Never do any
of this until you understand what's going on fully.
Obviously, you should have backups of whatever machine
you're targeting so that if (when) you make a mistake, you
can recover your data. YOU HAVE BEEN WARNED! If you
proceed, you do so at your own risk ... and no, I will
*not* come to your house and help you recover your hard
drive.
 
 
 
 
Why Bother Imaging?
===================
As a practical matter, production Data Centers tend to keep a separate
restore image around *for each different system variant*. So, for
example, you might have a separate image for your IBM servers, your
Dell servers, your Toshiba laptops, and so on.
 
Imaging may- or may not make sense when initially installing a new
configuration. Say you have a system that is a web server, but you
now want to build a separate machine that is a database server.
Typically, you would initially install SUSE Linux with the
installation disk, configure the database and *then* create a system
image of your database server. However, this is kind of time
consuming (unless you already have an ``AutoYAST`` configuration ready to
go). It may be simpler to image the target machine with your web
server image, boot it, reconfigure it as a database server, and then
take the image.
 
 
What Is ``tbku``?
=================
# 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:
 
# 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
# name (/dev/disk/by-id/xxxx). In our case the
# relevant portion of /mnt/etc/fstab looks like this:
# We need to make sure that things are mounted to
# reflect the partitioning you did with fdisk. This is
# done by editing:
#
# /mnt/etc/fstab
#
# Remember that drives can be named by device name
# (/dev/xxxx) or by the drive id name (/dev/disk/by-id/xxxx).
#
# In our case the relevant portion of /mnt/etc/fstab
# looks like this:
 
/dev/sda1 swap swap defaults 0 0
/dev/sda2 / reiserfs acl,user_xattr 1 1
 
# But now it needs to look like this:
 
/dev/hda1 swap swap defaults 0 0
/dev/hda2 / reiserfs acl,user_xattr 1 1
 
# Be sure not to disturb the other stuff in the fstab
# file
 
# Now, check and fix the device map file,
# /mnt/boot/grub/device.map Say we took the tbku image
# from a system that boot from SCSI, that file
# would look like this:
# file, or at least make sure it still makes sense.
 
# Now, check and fix the device map file:
#
# /mnt/boot/grub/device.map
#
# Since we took the tbku image from a system that boots
# from SCSI, the file looks like this:
 
(fd0) /dev/fd0
(hd0) /dev/sda
 
(hd0) /dev/hda
 
# We also have to correct any differences in the boot
# menu that appears when you first start the system.
# This is in /mnt/boot/grub/menu.lst Near the top of
# this file you'll see something like this:
# This is in:
#
# /mnt/boot/grub/menu.lst
#
# Near the top of this file you'll see something like
# this:
 
gfxmenu (hd0,1)/boot/message
 
# hd0 is right - we made sure of that when we edited
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
However, there are 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
to dig through ``YAST`` (if the system boots at all) and/or the individual
configuration tools to correct things.
 
.. Note::
 
Imaging is not the answer to every new installation
problem. At some point, it becomes simpler to
do a fresh install of SUSE Linux than to try
and "tweak" an existing image to get it running
properly.
 
 
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
drive(s)::
 
mount /dev/hda2 /mnt
 
You can then edit the files found under /mnt.
You can then edit the files found under ``/mnt``.
 
 
What Problems Can I Expect
--------------------------
 
So, you've decided to image a machine that is somehow different
than the original source of the image. Here's what you'll
possibly encounter:
 
 
A. Environmental Differences
 
Your newly imaged machine may work fine except that its
environment needs to change. The most common thing here is
the need to reconfigure the NIC with new network parameters
like IP address, netmask, DNS server, default route, and
so on. Similarly, you may want to change the machine
name or domain name.
 
This is all easily done via ``YAST`` or by editing the relevant
configuration files directly. Keep in mind that changing the
OS environment may also require changes in your applications'
configuration. For instance, changing your machine name, IP,
and so forth can break Apache.
 
B. Different Hardware
 
1. CPU Architecture
2. Motherboard Chipset
- Disk Controllers
- Network Controllers
- Audio
- Video
This is the tougher situation to handle after a machine
has been newly imaged. Modern SUSE Linux kernels come with
enough standard driver support built-in that they should
boot on most standard hardware ... unless you've hand
tuned the kernel on the machine where the image was taken.
 
However "booting" and "running properly" are two different
things. In the process of preparing this documentation, I
discovered that my newly imaged test machine *refused* to set
the PATA drive into UDMA modes 5/6. Why? Because the machine
used to create the original image had an older (different)
chipset than the newly imaged machine. I had to figure out
which additional drivers the kernel needed to load for it
to work properly on the new hardware.
 
Hardware differences show up in a number of places:
 
1. CPU Architecture
 
If you built your image on a machine that is configured
exclusively to run, say, on Xeon chipsets, and then try
to image another machine with a Pentium 4, um ... it's
not going to work. The kernels in your image have to be
compatible with the CPU architecture on your target
machine
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and
"Southbridge" chipsets. The Northbridge chip(s) control
memory and high speed graphics (like AGP). The
Southbridge chip(s) control the slower I/O functions and
peripherals of the motherboard. If the machine you're
imaging uses wildly different chipsets than the machine
where the image was taken, you're going to probably have
problems.
 
This was the case in the example above. By default, SUSE
Linux could boot IDE in its slowest possible mode, but
it could not exploit the higher speed UDMA features
of the new Southbridge chipset - that required the
installation of a driver specific for that chipset.
 
If you have different Southbridges, you'll run into this
with any of the on-board controllers:
 
- Audio
- Buses
- Disk
- Joystick
- Network
- Video
 
3. Peripheral Cards
 
If your newly imaged machine has different PCI and/or
video cards than the machine that produced the image,
you may, again, have to install additional or different
drivers.
 
 
Configuring Drivers
-------------------
 
Let's assume you can boot your machine fine, but you need to get
additional or different drivers to load for the machine to run
optimally. The kernel configuration is in this file::
 
/etc/sysconfig/kernel
 
In that file, you'll see a line something like this::
 
INITRD_MODULES="piix aic7xxx processor thermal fan reiserfs edd"
 
Now, suppose we want to add the drivers for, say, a VIA chipset.
We'd edit that line as follows::
 
INITRD_MODULES="piix aic7xxx sata_via via82cxxx processor thermal fan reiserfs edd"
 
Then we have to create a new ``initrd`` like this::
 
mkinitrd
 
Now unmount the drive and reboot.
 
.. Note::
 
If you *cannot* boot your new system, boot the
installation CD as before and get into the ``Rescue
System``. Mount the target drive under ``/mnt`` as we
did previously. This will allow you to edit
``/mnt/etc/sysconfig/kernel`` as needed. You can then
run ``mkinitrd`` with options to write the updated file
onto your target drive. See ``man mkinitrd`` for the
details.
 
 
 
The trick here is know *which* drivers you'll need. That's going
to take some digging on your part. Generally, you'll find
the compiled driver modules under::
 
./modules/<kernel-name>/kernel/
 
But, it's going to be up to you tofigure out which of these your
particular hardware actually needs.
 
In the end, unless the differences in source and target hardware are
fairly small/simple, you're typically better off to do a new
installation for each class of hardware you run, and create separate
image for each of them.
 
 
Author
======
 
Tim Daneliuk - tbku@tundraware.com
 
Comments and/or improvements welcome!
 
 
Acknowledgements
================
 
Several of Novell's terrific Dedicated Support Engineers answered my
(often stupid) questions. These guys know SUSE Linux inside out and
were most generous with their time and advice. Anything you see here
that's right is probably mostly due to them. Anything that's wrong is
likely my malfunction. In any case, I owe Aaron Gresko and Jared
Hudson a big "Thanks!" for their help.
 
 
Document Information
====================
disseminate this document without charge, so long as you do so without
modifying it in any way.
 
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.107 2008/03/12 23:37:30 tundra Exp $``
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.108 2008/03/13 21:21:45 tundra Exp $``