Create a Bootable Recovery Image CD

(Note: This is scheduled for inclusion in SystemImager v3.8. -Brian E. Finley)

This document describes a method to build a bootable, unattended recovery CD from an image of a running system, provided that system can run the SystemImager client; other restrictions apply as noted below. bzip2 compression is used and attains an average 3:1 compression factor, allowing systems of nearly 2 GB to be restored from a single CD.

All functionality is provided by an add-on program, mkrecoveryISO, that is run on the SystemImager server. Note that SystemImager provides a utility called "mkautoinstallcd" which allows you to cold-install a system over the network (i.e, the CD is not a standalone system image). mkrecoveryISO can generate such a full-image, standalone CD.

• Install CD versus Recovery CD
• Golden Images and SystemImager

• Step 1: Obtain the Golden Image
• Step 2: Unpack the mkrecoveryISO tarball
• Step 3: Compress the Golden Image
• Step 4: Create an ISO File
• Step 5: Burn the CD
• Acknowledgements
• Author and legal stuff
• How Does It Work?

Install CD versus Recovery CD

Install media is adaptable and flexible, able to correctly detect and conform to a wide variety of hardware (specifically disk controllers and sizes). Install media has every conceivable driver and software to make the correct choices; installation is more than simple copying of a fixed set of files. It tends to require user input but can be batched. The same install disk can be used on a wide variety of systems, from a single-disk 386 based machine to a four-way RAID box.

Recovery media is targetted at a restricted hardware configuration (CPU, controllers, disk number and size). It is created by taking a snapshot of a known-good system and probably won't work on any hardware that varies the slightest from that system. There are no user inputs required; it is mostly a simple re-partition and file copy.

A recovery CD is most easily created from a "golden image": a known-good system provides the files, configuration, and layout necessary to recreate itself. If there is sufficient disk space on the golden system, the image can be created in-place. Otherwise, the entire file system must be copied over the network to a repository server.

Golden Images and SystemImager

All of a system's files, its disk layout and boot configuration, provide enough data to build a bootable CD that can restore that to another system. The first question is, how is all the data obtained? An open-source client-server solution solves that part of the problem: SystemImager (see http://systemimager.org/ ). An SI server is established somewhere on the net; the SI client is installed on your "golden client". The SI program "prepareclient" (run on the client) gathers information and readies the client for network file copy using rsync .

The SI server program "getimage" retrieves the golden client, creating a duplicate file system layout on the server and capturing other data about the client system. The design intent of SystemImager is to provide network-based backup and restore features, especially deployment to multiple similar clients. The data stored on the SI server is the starting point for building recovery CDs.

mkrecoveryISO is an "add-on" to SystemImager. Running mkrecoveryISO on the server can generate a bootable ISO image from a previously grabbed golden client image. mkrecoveryISO will work against SystemImager 1.50 and 2.01 image repositories.

Restrictions

There are several known restrictions on the use of mkrecoveryISO. By definition, there are no unknown limitations :-)

1. Only Intel x86 systems using LILO will work.
2. Software RAID will not work. mkrecoveryISO was originally written for "appliance" products; this limitation was a design decision.
3. You must use the "replicant" IP option with getimage.
4. Systems that use the device file system, devfs, will not work with SystemImager 1.50 (Mandrake 8.1 is an example). This requires a fix to the SI client program "prepareclient" (which I have implemented). I don't know about SI 2.01.
5. Systems that do not use the "RedHat" /etc/sysconfig hierarchy will not work with SystemImager 1.50 (SuSE 7.1 is an example). This requires a fix to the SI server program "getimage" (which I have implemented). I don't know about SI 2.01.

The design constraints extant in the fall of 2001 required a network-based solution that captured all "golden image" data to the server. At the time, SystemImager seemed like the best base to choose from the available open-source projects. If you want a standalone solution, be sure and check out MkCDrec.

Step 1: Obtain a golden image

# ps -ef | grep rsync
........ rsync --daemon --config=/tmp/rsyncd.conf

Next, install the SystemImager server on your server as documented on the SI web page. Your server will have several new directories that store images and data; these directories are different between SI 1.50 and SI 2.01. Grab an image from your client (which should still be running rsync):

# getimage -golden-client target.xyzzy.hp.com -image myimage

Step 2: Obtain the mkrecoveryISO tarball

Step 3: Compress a golden image

# mkrecoveryISO -list
Compressed images available for ISO creation:
Previously grabbed images available for compression:
    myimage: XXXX Mbytes

# mkrecoveryISO -list
Compressed images available for ISO creation:
    myimage: YYY Mbytes
Previously grabbed images available for compression:
    myimage: XXXX Mbytes

mkrecoveryISO stores the compressed images in a directory one-off the SI repository. If you are running SI 1.50 the compressed images are stored in /var/spool/systemimager/images.BZ2. For version 2.01, mkrecoveryISO looks in the /etc/systemimager/systemimager.conf file and makes a directory along with the images directory. To remove the compressed image (recover disk space) use the -decompress option. mkrecoveryISO will never do anything to the original SI image.

Step 4: Create an ISO file

# mkrecoveryISO -image myimage -iso myboot.iso

Since the images are compressed it may be possible to fit more than one image on the final CD. Multiple "-image" options can be given. There is an extended syntax: the first word of a "-image" argument is the image name and the remaining words will be used in the boot menu. Finally a "-label" option appears as a header on the boot menu. Assuming you had three images named myimage1, myimage2, and myimage3, the following command could be used:

# mkrecoveryISO -iso myboot.iso -label "Nifty Neato Model XJ2000" \
                -image "myimage1 A Good Choice" \
                -image "myimage2 A Better Choice" \
                -image "myimage3 Last But Not Least"

                     SystemImager Recovery Disk vX.Y.Z
                          Nifty Neato Model XJ2000

STOP NOW...If you don't want to overwrite your system!

This CD contains a new file system layout and contents.  Continuing
this process will partition your disks with filesystems and swap, then
copy the contents.  Finally your new system will be configured to boot.

When you are ready, enter a choice ("ImageX") at the "boot:" prompt.

Choice   Description
=============================================================================
Image1   A Good Choice
Image2   A Better Choice
Image3   Last But Not Least

boot:

Step 5: Burn the CD

If you're burning your CD under Linux, remember three things:

1. The cdrecord Home Page. You probably already have cdrecord on your system.
2. "cdrecord -scanbus" is your friend.
3. "/etc/cdrecord.conf" is where you save things your friend told you.

I have successfully burned CDs with the ISO file on Windows platforms using Easy CD Creator. Your mileage may vary.

Acknowledgements and References

• The SystemImager Home Page
• The rsync Home Page
• Boot menus with Syslinux
• BusyBox: Commands for embedded Linux
• The Linux CD-Writing HOWTO
• The cdrecord Home Page

Original Author

I will be certainly entertain email from the world on the code, and will strive mightily to at least respond. Due to the vagaries of reality, I can't guarantee if or when I might get to take action on your requests. If my HP email address ever starts bouncing :-) try the Source Forge target.

Obligatory large company legalase:

Author: Rocky Craig, rocky_craig(AT)hp.com
                     coloroco(AT)users.sourceforge.net

(c) Copyright Hewlett-Packard Company 2002

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.

This notice will need to be modified for software to which a different
license applies (e.g., GNU LGPL, BSD license, Apache license).

How It Works

mkrecoveryISO runs "getimage -v" to obtain the repository version so it can recover image paths and make its own images.BZ2 directory for compressed images. Directories are compressed separately, as are files at /; this seemed more prudent than one giant BZ2 file. Compression takes place separately from ISO creation to allow the generation of multi-image boot CDs.

The kernel for the bootable CD has most common hardware "standalone" drivers and an initial RAM disk (initrd) with a smart script. This was a divergence from the mkautoinstallcd that put one script in one spot. I pared down the script to a static portion that stays in the initrd.gz. It is smart enough to mount the CD and invoke another script that actually unpacks the image.

The kernel and initrd.gz live in /usr/share/systemimager/mkrecoveryISO. There is also a dotconfig file there for use in generating your own kernel; it is from 2.4.18. The initrd originally came from SI 1.50. When the kernel boots, it runs /sbin/init from the initrd. As it turns out, that is a link to "BusyBox" (as are most of the files in /bin and /sbin). /etc/inittab directs init to run /etc/init.d/rcS which is the script that mounts the CD and transfers control to the script "local.cfg" on the CD.

If you want to see all this, unpack the initrd.gz and mount it. Should you make changes, repack it with "gzip -9". Note that BusyBox init has its own little quirks, be sure you understand them. Keep a copy of the original initrd.gz, just in case :-)

# cd /usr/share/systemimager/mkrecoveryISO
# gunzip < initrd.gz > /tmp/initrd.img
# mkdir /mnt/ramdisk
# mount -oloop -text2 /tmp/initrd.img /mnt/ramdisk
# cd /mnt/ramdisk/

Each image (on a multi-image CD) is stored in its own directory. That directory has multiple .bz2 files as discussed earlier. /etc/init.d/rcS examines the kernel command line for a parameter that tells it which image the user selected for boot. That line is processed by the Syslinux facility whose config file was written by mkrecoveryISO. All of these files are collected into a floppy image which is supplied to mkisofs as the CD boot sector. These boot-time support files are stored in their own directory on the CD. This keeps the root directory of the CD relatively uncluttered.

The secondary script on the CD, "local.cfg", is culled from the image.master script made by SI "getimage" and stored in the appropriate directory. It contains the partition layout and format commands necessary for a system. "local.cfg" then unpacks all the bz2 archives and runs lilo.