Create a Bootable Recovery Image CD

Rocky Craig, Hewlett-Packard
Last revised July 2002

(Note: This is scheduled for inclusion in SystemImager v3.2. -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

It is important to express a key difference between "install" media and "recovery" media. Both are bootable, both can be set for minimal user input, and both leave you with a freshly rewritten hard disk.

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

First install a copy of the SystemImager client on your golden system per the instructions. Run prepareclient (with no options); after it finishes, make sure the rsync daemon is running:
# 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
Getimage will pause for a few seconds, then show the files as they are being copied. You will be asked for an IP type, choose "Replicant". When this finishes you will have a file-for-file copy of the client system on your server, along with configuration script that can repartition disks for a cold install. Now you are ready to create an ISO!


Step 2: Obtain the mkrecoveryISO tarball

If you don't already have the tarball, grab it from SystemImager's Source Forge site. mkrecoveryISO.tgz is in the "Unofficial" section of the "Downloads" link. Unpack it at the root directory of your SI server. You should see an executable Perl script, /usr/sbin/mkrecoveryISO and a directory, /usr/share/systemimager/mkrecoveryISO. That path will "piggyback" onto SI 2.01, and exists independently of other SI paths for version 1.50. mkrecoveryISO has a -help option.


Step 3: Compress a golden image

Grabbed golden images must be compressed before they can bundled into an ISO image. Running mkrecoveryISO -image myimage -compress performs this compression while spewing the names of the files as they are compressed. mkrecoveryISO should be in your (root) path at /usr/sbin. First use the -list option to show available images:
# mkrecoveryISO -list
Compressed images available for ISO creation:
Previously grabbed images available for compression:
    myimage: XXXX Mbytes
This assumes a single-image SI repository. After compressing the image as shown above, a listing should show:
# mkrecoveryISO -list
Compressed images available for ISO creation:
    myimage: YYY Mbytes
Previously grabbed images available for compression:
    myimage: XXXX Mbytes
Experience has shown an average 3:1 compression ratio for images but of course your mileage will vary.

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

Once you have a compressed image you can create the ISO file that drives your CD recording process.
# mkrecoveryISO -image myimage -iso myboot.iso
When a CD burned with this image is booted, a menu is displayed (with only one item in this example). The user must validate this entry before recovery will begin. This menu and prompt functionality is provided by the SYSLINUX facility which is also needed for the stock installation of SystemImager. The kernel supplied with mkrecoveryISO is a stock kernel.org version 2.4.18 compiled with many common drivers. The .config file is included with the mkrecoveryISO tarball.

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"
You could edit those choices into a file and use the "-images filename" option. When you finally booted a CD made from this ISO, you would see the following menu:

                     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:
The system will remain at this menu until a valid choice is entered. Once running, the hard disk(s) will be repartitioned according to information gathered during the prepareclient/getimage phase and files written appropriately.


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.
Finally, cdrecord -v myboot.iso will generate your bootable CD.

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


Acknowledgements and References


Original Author

mkrecoveryISO was written by Rocky Craig at Hewlett-Packard (for internal use) in the fall of 2001. I tried for the look and feel of SystemImager 1.50, including some coding style. Permission was granted by HP management to release this effort back to the open source community. I added the ability to work with both 1.50 and 2.01 archives and released it in July 2002.

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

I started this whole project with a "don't reinvent the wheel" attitude; that's why I was happy to find find SystemImager (version 1.50, fall 2001). mkautoinstallcd got me thinking, and I tried to add a series of options to it. The further I got into it, the more I realized I needed a separate add-on command. That was mainly because of the extra boot-time commands needed to do the restore (mainly tar and bzip2). That decision really paid off when I added the ability to work with 2.01 (as well as 1.50).

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.