mkCDrec logo Make CD-ROM Recovery

FAQ List
Mailing Lists

Internals Explained



Make CD-ROM Recovery (mkCDrec) consists out of 2 big pieces, namely "making the bootable CD image(s)", and the "restore/rescue/clone part" in case one needs it.

In this article we will try to explain both parts in more detail. Please be patient as this article will take a while before it is finished.
The question why mkCDrec is the best suitable tool for your backups is not on its place as mkCDrec never claimed to be a backup tool anyway! One has to see it as a "disaster recovery" tool which is not yet standard available in any linux distribution. Until this situation is corrected mkCDrec can be of assistance ;-)
A word of caution: do not trust blindly that mkCDrec will do its job without errors, therefore, please test it on a test-and-burn system which is more or less equivalent to your production system.
In case you stumble over a bug, submit a bug report (see support page)!

Configuring mkCDrec

After downloading the latest release of the main website ( ) and installing it in some directory one can start customizing the behavior of mkCDrec by editing the file.
For more details on all changeable items go and read the config.html web-page.

Make test

One of the first thing one can do to test his system if its ready to start a make process is to run make test first to check if all the prerequisites are met. Therefore, type the following commands:
# cd   mkcdrec
# make  test

This will result into (hopefully) as follows:

If a FAIL pops up then correct the problem by following the instructions. In case of missing executables please install them from your linux distribution CD-ROMs.

The make process

When you would like to make an ISO9660 image of your system you have to do it via a "make" command. A simple make command drives the whole process of gathering system information, making backups (if asked for), and creating ISO9660 images.
After typing make you will see the following menu:

Before we go in more detail in above menu lets discuss the makefile in more detail.

Design Goals

The reason why we choose to drive the complete process of making a bootable El Torito CD-ROM from a simple "make" command was for simplicity toward end-users.
In worst case the users have to edit the "" file which contains directory paths where images will be stored and so on (see page for more in-depth details).

The Makefile itself

The "Makefile" which is read by the make command can be found in the top directory of mkCDrec. The following table shows the Makefile of mkCDrec v0.4.7:

# Copyright (c) 2000-2001 Gratien D'haese 
# Please read LICENSE in the source directory 


SHFILES=$(addsuffix .sh,$(DISKNAMES)) 
BZ2FILES=$(addsuffix .img.bz2,$(DISKNAMES)) 

# local dirs 
MKCDREC_DIR := $(shell pwd) 

# some packages used by mkCDrec (may be replaced by higher versions) 
SYSLINUX_DIR := $(shell ls -d syslinux*) 
BUSYBOX_DIR := $(shell ls -d busybox*) 
TINYLOGIN_DIR := $(shell ls -d tinylogin*) 
SFDISK_DIR := $(shell ls -d sfdisk*) 
CUTSTREAM_DIR := $(shell ls -d cutstream*) 
PASTESTREAM_DIR := $(shell ls -d pastestream*) 
CKSFV_DIR := $(shell ls -d cksfv*) 

DATE := $(shell date +%d.%m.%Y) 
ISOFS_DIR := $(shell grep ISOFS_DIR= |grep -v ^\# | cut -d= -f 2) 
VERSION := $(shell cat VERSION) 
CDREC_ISO_DIR := $(shell grep CDREC_ISO_DIR= |grep -v ^\#|cut -d= -f2) 

all: devs dirs mformat mkmakeISO9660 $(BZ2FILES) bootflop.img Backup_Finished 
    @echo Done. 

mkmakeISO9660: $(SCRIPTS)/ 

CDrec.iso: $(BZ2FILES) bootflop.img Backup_Finished 
  mkisofs -J -r -P "$(VERSION)" -V "CDrec-$(DATE)" -o $(CDREC_ISO_DIR)/$@ -b bootflop.img isofs/ 

$(BZ2FILES): %.img.bz2: $(SCRIPTS)/ 

bootflop.img: $(SCRIPTS)/ initrd.img.gz syslinux 

initrd.img.gz: $(SCRIPTS)/ linuxrc 

      (cd $(SYSLINUX_DIR); make) 
      cp $(SYSLINUX_DIR)/syslinux ./bin/syslinux 

     ( objcopy -S /usr/local/bin/mformat $(BIN_DIR)/mformat 2> /dev/null || \ 
     objcopy -S /usr/bin/mformat $(BIN_DIR)/mformat 2> /dev/null || \ 
    @echo No mformat found on this system. Use ours instead. ) 

     mkdir -p $(ISOFS_DIR) stage tmp 

devs: /dev/initrd /dev/fd0u1722 
    @echo Device check OK 

     mknod /dev/initrd b 1 250 
     chmod 400 /dev/initrd 

     mknod /dev/fd0u1722 b 2 60 
    chmod 666 /dev/fd0u1722 


    -umount stage 
    rm -f *.img 
    rm -f initrd.img.gz 
    rm -rf $(ISOFS_DIR) 
    rm -rf tmp 
    rm -f isofs 
    rm -rf bootflop 
    rm -f *.log 
    rm -f $(CDREC_ISO_DIR)/*.iso 

distclean: clean 
    (cd $(SYSLINUX_DIR); make clean) 
    (cd $(BUSYBOX_DIR); make clean) 
    (cd $(TINYLOGIN_DIR); make clean) 
    (cd $(SFDISK_DIR); make clean) 
    (cd $(CUTSTREAM_DIR); make clean) 
    (cd $(PASTESTREAM_DIR); make clean) 
    (cd $(CKSFV_DIR); make clean) 

dist: distclean 
    (cd ..; tar --file mk$(VERSION).tar.gz --create --gzip --verbose --exclude CDrec* --exclude stage --exclude tmp --exclude isofs --exclude OLD --exclude utilities mkcdrec ) 

    (tar --create --gzip --verbose --file ../mk$(VERSION)_utils.tar.gz $(UTILITIES) ) 

test: $(SCRIPTS)/ 

All the bold items in the Makefile are headers which can be invoked separately. The most common make commands an user can use are:

    make: this will do it all for you! At the end you will have one or more iso9660 images on hard disk or CD-R dependent on the choice given by the user, but more on this later.

    make clean: cleans up all temporary files and directories. It is preferable to do this before running an new make command.

    make test: this will check if your system is able to do a successfully make command. If it fails here one has to correct what the script asks you to repair.

Running the make command

The make command on itself will use the "all" header to do its thing:
all: devs dirs mformat mkmakeISO9660 $(BZ2FILES) bootflop.img Backup_Finished

The "all" will execute in order the above items. The "devs" will check if the device /dev/initrd exists, and if not, it will make it automatically. Thereafter, "dirs" will create the necessary temporary directories, such as ISOFS_DIR, stage and tmp. With a "make clean" those directories are removed again (be careful with images residing in ISOFS_DIR!). Mformat checks if the executable mformat in installed on your system, if not, then mkCDrec will use its own mformat utility (in bin/ directory).
The "mkmakeISO9660" will create a shell script in scripts/ directory called "" from the input file "" file and merging some variables from "" file needed later on to create an ISO9660 images called by the cutstream program of script depending on being a multi-volume CD-ROM backup or not.

The BZ2FILES does only contain one file, namely rd-base! Therefore, this line will execute the script (all scripts are located in the scripts/ directory). script is responsible for making the main root ram disk which will be loaded after the initial bootloader.

The "bootflop.img" is responsible for making the initial ram disk (, the syslinux boot loader, and finally the El-Torito bootfloppy (which contains the linux kernel, syslinux boot loader and the compressed initrd images).

Finally, Backup_Finished will execute the script to make (or skip) the tar backups of your file systems. script will always call the script to produce the ISO9660 image on hard disk (file called CDrec.iso) or burn it directory on a CD-R when chosen for it in the file).
We will try to explain all the steps in more detail following the flowchart design:

The sole purpose of this small script is to merge some variable settings from into Therefore, it will merge the file and the correct variable settings of Correct settings have to be edited manually into (sorry, no GUI yet) - see also config.html file in doc/ directory.
The reason we have to do this is that in some circumstances the script will be called in an isolated environment where mkCDrec settings are unset, therefore, we have to hardcode some variables into this script - that's all.

The script is responsible for building the main ram based root file system that will be active during the restore or cloning process.
The scripts starts up with asking the user what he wants to do (maybe it is not 100% similar to what you see):

mkCDrec will behave (do different things) on the selection you choose:

1. Here we will make only a rescue CD-ROM (no backups!). Always good to have around (and no real risk to keep on your desk as no sensitive data is kept on it).
Be aware that with this CD and physical access to any PC (with CD-ROM reader) one has access to all data on the hard disks!
2. This option will make backups on the rescue CD-ROM(s). It is smart enough to find out if multiple CDs are necessary (burn to CDR(W) directly or save separate ISO's).
3. This option will make a rescue CD-ROM and will put the backups on another path. That path can be a local disk or remote (NFS/SMB) disk.
Be aware that mkCDrec assumes that the destination path is on-line and mounted. It will not attempt to mount it for you.
4. This option will make a rescue CD-ROM and will be the backups on a (remote) tape.
5. Quit (do nothing)
Once the user selected an option the real work starts with making and mounting a RAM disk. It will compile and copy BusyBox, tinylogin, sfdisk, cut- and pastestream. It will populate the etc, dev, lib, bin directories according what was found in the file.
An important part of script will then investigate your current system and save all the needed information (system and disk related) into the directory etc/recovery/.
Once in a while a routine will keep an eye if you're not running out of disk space on the RAM disk. Once finished the RAM disk will be unmounted and compressed as rd-base.img.bz2 and copied to isofs/ directory. The isofs/ directory is the target directory for making, with mkisofs, the CDrec.iso image (or multiple images in case of large backups).

The script is responsible for making the initial ram disk with minimal driver support, just enough to get the CD-ROM mounted and load the rd-base.img image into RAM.
The first step it takes is creating an empty ram disk, and make a file system on it, be it ext2, minix, msdos or romfs. Then it will populate the file system with the necessary directories and devices (when not using devfs). Thereafter we copy the bare minimum binaries and according libraries to get the system going from initrd stage to be able to mount a bigger ramdisk.
To finish we have a tricky part: check which loadable modules should be copied on the initrd so we can mount the IDE or SCSI CD-ROM. With this (new) approach we avoid to recompile the kernel (keep it modular).
Before unmounting the ram disk we copy some system files (such as linuxrc) and then gzip the image into initrd.img.gz.

Compile Syslinux

The next step in the process is to compile syslinux (once is enough) and copy the binary to our local bin/ directory. We need syslinux to make our bootfloppy which will be put on the CD-ROM too. In El-Torito mode the CD-ROM needs a bootable floppy disk image which we will make in the following step.
It will also compile isolinux and will use isolinux when it detect the following directory (done in
Why? memtest.bin is the memtest86 executable which is an excellent ram checker. To let the end-user choose between mkcdrec or memtest we need another approach and we are unable to fit all executables (of mkcdrec and memtest) on one floppy, therefore, we decided to use isolinux instead of syslinux. Isolinux has another big advantage and that is, there is no size limit anymore for the bootable images, be it 1.44 or 2.88 Mb.
Be aware: this step is obsolete since mkCDrec v0.7.1. Now the syslinux package is a pre-requisite.

The purpose of this script is to make a bootfloppy (emulation) image which will be put on the CD-ROM to make the El-Torito mode a reality.
In the first stage we will format an empty floppy in memory (not on a physical floppy!). The floppy image will be mounted as a MSDOS file system via a loopback device on a stage-directory. Then we will copy the linux kernel to it (as specified in or we will use the current one), the initrd.img.gz image file (initial ramdisk), the syslinux.cfg file, the mkCDrec.msg file (the welcome message you see at boot time).
Now comes the magic - we unmount the bootflop.img and syslinux it to make it bootable.
Finally, the user may be prompted to create a physical bootfloppy when PROMPT_BOOT_FLOPPY= 1 and BOOT_FLOPPY_DENSITY=HD (both defined in Of course, this only works is bootflop.img is smaller than 1.44 Mb. Otherwise, the only alternative is a 2.88 Mb bootfloppy which is supported by El-Torito CD-ROMs.
The second approach available when mkCDrec Utilities are installed is the isolinux approach instead of the bootfloppy emulation of syslinux. If you see on the CD-ROM a directory called isolinux then be sure that isolinux is used. Under that directory you will find the linux kernel, initrd.gz image, some configuration files and the isolinux executable. script will always be called (even when you selected the Rescue Only option) because at the very end of this script we will call another script, to make (finally) the ISO9660 image(s).
Suppose we have a backup to make, either to tape, local mounted disk or NFS disk, or to CD-ROM (to an ISO9660 image that is). Depending on what we have chosen we will follow a different track.
If CD-ROM was chosen as destination for the backups then the script will examine if the complete backup will fit onto one CD-ROM or multiple CDs and it will warn us about is (press Enter to continue).
If  (local or remote) tape was chosen as destination then for the moment the script will assume that the maximum capacity is 2100000 Kb (approx. 2 Gb). This part could be improved a lot if we could ask or inquire the tape drive what the capacity is of the tape (if someone knows how please step forward and tell me).
Then the script will build up a exclude list of directories which may not be included in the backup (there is also an EXCLUDE_LIST variable in the file to add yours). It is a rather complicated piece of code as RedHat, Debian and SuSe interpret the tar exclude list a bit different (bah, very ugly and there goes unified systems).
Once the script has struggled through the exclude list it can start with its thing, namely backup the damn thing. Therefore, it will build a loop over all the mounted ext2, ext3, jfs, xfs and reiserfs file systems (and excluding any loop devices, devps, etc.). For all Microsoft based file systems we use "dd" instead of the tar command!
Again for doing the backup itself there is a difference between tape or disk (local, NFS, CD-ROM) as destination. When using tape we will use the following statement:
(${DEBUG} tar --create --verbose --same-owner --blocking-factor=512 \
          --preserve-permissions --exclude-from=${TMP_DIR}/${_Fs}.exclude_list \
          --gzip --file - . | ${REMOTE_COMMAND} ${RHOST} dd of=${DESTINATION} obs=512 ) 1>>  ${ISOFS_DIR}/${_Dev}.${_Fs}.log 2>&1

Above statement contains lots of variables which are defined in What is important here is that we use the dd command to dump to tape which is the safest way so we are pretty sure we can restore with a different tape drive (later, much later in case of sh*t).

If the destination is a disk (local, NFS, SMB) then we use the following statement:
${DEBUG} tar --create --verbose --same-owner --${CMP_PROG} --blocking-factor=512 \
          --preserve-permissions --exclude-from=${TMP_DIR}/${_Fs}.exclude_list \
          --file ${DESTINATION} . 2>>${ISOFS_DIR}/${_Dev}.${_Fs}.log 1>&2 

The "DESTINATION" variable is build up as following:
The extension "tar.gz" is used in case gzip was selected for CMP_PROG, or "tar.bz2" if bzip is the preferred compression program.

If the destination directory is /CDROM/ then yet another approach is followed as it can happen we have to split up the backup across different CDs.
To make this magic happen we wrote a helper program "cutstream" to cut a data stream after an predefined amount of bytes which happens to be the size of the CD-R(W)!
We introduce some new variables to help us a bit. CAPACITY contains how much space is left for backups on a CD-R (remember the first CD contains also some images such as bootlop.img, rd-base.img and documentation). MAKE_ISO9660 variable just contains the absolute path to, and VOLNO_FILE which contains the absolute path to tmp/volno file. the volno file contains the volume nummer of CD sets. It starts with 0 (single CD), and will be incremented if another CD is needed.
The command looks like:
                                                                                        CUTSTREAM="cutstream"       # cut stream to fit on CDR
export MAKE_ISO9660
VOLNO_FILE="${TMP_DIR}/volno"       # volume nr (#Cds)
(${DEBUG} tar --create --verbose --same-owner --blocking-factor=512 --preserve-permissions --exclude-from=${TMP_DIR}/${_Fs}.exclude_list --${CMP_PROG} --file - . | ${CUTSTREAM}) 2>>${TMP_DIR}/${_Dev}.${_Fs}.log

So to make the picture complete we'll explain also cutstream and


The cutstream program is based on a simple cat program, in fact it does not more than simple reading a data stream from a pipe and store it into a file. It gets the filename through the exported DESTINATION variable. It starts a counter which is incremented according the amount of data read, If the CAPACITY counter is reached then it will increment the volno counter (tmp/volno) and stops reading data and starts a system call to "". If the shell scripts finishes (with making an ISO9660 image) it returns and happy as it is continue to dump in the file DESTINATION which was removed by the script. Of course, the CAPACITY counter will be reset too to its maximum capacity (which is defined in - you see how important that file is!).
It is maybe not the most elegant solution but it does work.

The script does not exist initial, but is created through the make command as it contains absolute paths only to all kind of scripts we need. the reason is that this script will not run in our shell but in a subshell spawned by cutstream (maybe if multi-volume CDs are needed).
What does it do: it will run cksfv * > Checksums.sfv over all the files to have some kind of checksum.
Then it will start makeisofs command to create an ISO9660 image (only the first CD will be bootable).  In case BURN_CDR is Y ( again) then it will start to burn this image to a CD-R (will endless retry until it succeeds, so better insert a blank CD-R).
In case the images are stored on disk (CDREC_ISO_DIR definition in then it will check it we're dealing with a multi-volume CD-set and move CDrec.iso to something like CDrec-${DATE} followed by volume nummer. Please mark your Cds afterward with this label as a reference!
The most dangerous command happens at the end of

(cd ${ISOFS_DIR}; rm -vf *; rm -rvf doc; rm -rvf utilities)

This will clean up the old source for the ISO9660 images and remove old files and directories so we can continue with the new image.
If was called from cutstream then now is the time to go back and continue with the data stream...otherwise, we're finished.

Restore your system

The purpose of mkCDrec is to restore your system to a situation when you ran for the last time 'make' within mkcdrec, and wrote the corresponding CDrec.iso image to a CDR (or are still able to make a CDR of the image when saved on another system - as I do sometimes).
When Murphy came along - and left a system unbootable or unusable (what's the difference?) - you will probably be under high pressure to restore the system as soon as possible!
Most of the times there is not much time to investigate in-depth what happened, if it is hardware related replace the broken item immediately and restore the system or file system (it depends) and you're back in business. In case it is software related (by accident or malicious) then it could be that the system is rather unstable or likely untrustable. In these situation it is better (or wise) to restore from scratch from the latest known stable backups.
In both cases mkCDrec can come to rescue!

However, some words of wishdom, do not blindly trust the tool without trying it out on a spare "crash-and-burn" system with data you can effort to loose!

What has mkCDrec to offer?

  • restore the "complete" system from scratch. Meaning all new disks have to be of the same type (IDE, SCSI) and may not be smaller in size (which is unlikely these days) as the original ones. The script will examine the system and halt if it detects an error. If an errors occurs you are thrown back into shell where you can repare or provide the requested item of the exit code. The script may be restarted afterward hopefully continues at the point it previously exited.
    Furthermore, it will reformat the disks and un-tar all file system backups. Finally, it will make your system bootable again with the help of lilo or grub.
  • this script allows you to restore one single disk to any kind of disk (IDE, SCSI) and it will recalculates the partition size layout for you as long the size of the original backup fits into the disk space of the newer disk. Excellent script made especially for cloning purposes (as the name of the script says). This script is more interactive as it allows you to skip parts of the restore scenario, e.g. re-format the partitions, make file system on it.
  • this script will simply restore a single file system without much fuzz to a beforehand formatted disk (including partition layout). However, along the way you can choose the file system type you want to have, with other words, ideal for migrating from ext2 to ext3, ReiserFS, XFS or JFS. Another reason for this script is because it could happen that the backup is split across multiple CDRs, and therefore, you need to use "pastestream" to glue the different parts together while piping the input stream into tar.

How do we get there?
By simple inserting the mkCDrec CD-ROM into the CD-ROM drive and rebooting the system (make sure your system is able to boot from CD. Check your BIOS settings). The CD is bootable because it is compliant with the El-Torito definition which makes CDs bootable on Intel based PCs. This will emulates a bootfloppy! Therefore, the bootflop.img is loaded into memory and syslinux makes sure that initrd.gz is unzipped into /dev/ram0 and gets executed after the linux kernel is loaded into memory too.
This is called the "initial" ram disk phase: linuxrc gets executed and will try to find the CD-ROM as in fact the system booted from a kind of floppy stored on CD (can you follow?). If it can find the CD-ROM it will mount it and expands the bigger ram disk into /dev/ram1. When succeeded it will switch from /dev/ram0 to /dev/ram1.
At that point "init" is started (or linuxrc) which are links to busybox (to make as much space available in ram). The CD-ROM will get mounted again under /mnt/cdrom and /dev/ram1 will be the /, and /dev/ram0 became /dev/root.old and contains the former / which is now /initrd.
Then init will execute /etc/rc.d/rc.system which will take care of all the other steps necessary to give you a root prompt and a usable bash shell.

If you cd into /etc/recovery directory you will find the above mentioned scripts (and other scripts or files which helper scripts or input files for these scripts). If you delete these files by accident do not panic - just reboot the system with the same mkCDrec CD. No harm done ;-)

If the utilities were installed in the mkcdrec directory during the make process (before burning the CDR!) then you will have some handy tools available which gives plenty added value to your mkCDrec (see the utilities pages for additional information). I advise to add them always! 

$Id: internals.html,v 1.8 2004/03/28 18:28:18 gdha Exp $