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/ + +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 $``