diff --git a/Imaging-SUSE-Linux-With-tbku.txt b/Imaging-SUSE-Linux-With-tbku.txt
index 1f977b7..9303b24 100644
--- a/Imaging-SUSE-Linux-With-tbku.txt
+++ b/Imaging-SUSE-Linux-With-tbku.txt
@@ -4,11 +4,24 @@
This document describes how to use the TundraWare Inc. ``tbku``
utility to "image" or "clone" SUSE Linux systems.
- .. Note::
+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.
- 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?
@@ -51,6 +64,17 @@
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``?
=================
@@ -221,22 +245,35 @@
# 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
+ # file, or at least make sure it still makes sense.
- # 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:
+ # 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
@@ -249,8 +286,12 @@
# 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
@@ -312,17 +353,26 @@
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
@@ -332,19 +382,146 @@
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
======
@@ -354,6 +531,17 @@
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
====================
@@ -368,4 +556,4 @@
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 $``