1.1. Version notes

Graham Chapman wrote the original Bootdisk-HOWTO and supported it through version 3.1. Tom Fawcett started as co-author around the time kernel v2 was introduced, and he is the document's current maintainer. Chapman has disappeared from the Linux community and his whereabouts are currently unknown.

This information is intended for Linux on the Intel platform. Much of this information may be applicable to Linux on other processors, but I have no first-hand experience or information about this. If you have experience with bootdisks on other platforms, please contact me.

1.2. To do list

1. User-mode-linux ( http://user-mode-linux.sourceforge.net) seems like a great way to test out bootdisks without having to reboot your machine constantly. I haven't been able to get it to work. If anyone has been using this consistently with homemade bootdisks, please let me know.

2. Re-analyze distribution bootdisks and update the "How the Pros do it" section.

3. Figure out just how much of the init-getty-login sequence can be simplified, and rip it out. A few people have said that init can be linked directly to /bin/sh; if so, and if this imposes no great limitations, alter the instructions to do this. This would eliminate the need for getty, login, gettydefs, and maybe all that PAM and NSS stuff.

4. Go through the 2.4 kernel source code again and write a detailed explanation of how the boot process and ramdisk-loading process work, in detail. (If only so that I understand it better.) There are some issues about initrd and limitations of booting devices (eg flash memory) that I don't understand yet.

5. Delete section that describes how to upgrade existing distribution bootdisks. This is usually more trouble than it's worth.

6. Replace rdev commands with LILO keywords.

1.3. Feedback and credits

I welcome any feedback, good or bad, on the content of this document. I have done my best to ensure that the instructions and information herein are accurate and reliable, but I don't know everything and I don't keep up on kernel development. Please let me know if you find errors or omissions. When writing, please indicate the version number of the document you're referencing. Be nice.

We thank the many people who assisted with corrections and suggestions. Their contributions have made it far better than we could ever have done alone.

Send comments and corrections to the author at the email address above. Please read Section 7 before asking me questions. Do not email me disk images.

1.4. Distribution policy

Copyright � 1995-2002 by Tom Fawcett and Graham Chapman. This document may be distributed under the terms set forth in the Linux Documentation Project License. Please contact the authors if you are unable to get the license.

This is free documentation. It 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.

3.1. The boot process

All PC systems start the boot process by executing code in ROM (specifically, the BIOS) to load the sector from sector 0, cylinder 0 of the boot drive. The boot drive is usually the first floppy drive (designated A: in DOS and /dev/fd0 in Linux). The BIOS then tries to execute this sector. On most bootable disks, sector 0, cylinder 0 contains either:

• code from a boot loader such as LILO, which locates the kernel, loads it and executes it to start the boot proper; or

• the start of an operating system kernel, such as Linux.

If a Linux kernel has been raw-copied to a diskette, the first sector of the disk will be the first sector of the Linux kernel itself. This first sector will continue the boot process by loading the rest of the kernel from the boot device.

When the kernel is completely loaded, it initializes device drivers and its internal data structures. Once it is completely initialized, it consults a special location in its image called the ramdisk word. This word tells it how and where to find its root filesystem. A root filesystem is simply a filesystem that will be mounted as ``/''. The kernel has to be told where to look for the root filesystem; if it cannot find a loadable image there, it halts.

In some boot situations — often when booting from a diskette — the root filesystem is loaded into a ramdisk, which is RAM accessed by the system as if it were a disk. RAM is several orders of magnitude faster than a floppy disk, so system operation is fast from a ramdisk. Also, the kernel can load a compressed filesystem from the floppy and uncompress it onto the ramdisk, allowing many more files to be squeezed onto the diskette.

Once the root filesystem is loaded and mounted, you see a message like:

VFS: Mounted root (ext2 filesystem) readonly.

Once the system has loaded a root filesystem successfully, it tries to execute the init program (in /bin or /sbin). init reads its configuration file /etc/inittab, looks for a line designated sysinit, and executes the named script. The sysinit script is usually something like /etc/rc or /etc/init.d/boot. This script is a set of shell commands that set up basic system services, such as running fsck on hard disks, loading necessary kernel modules, initializing swapping, initializing the network, and mounting disks mentioned in /etc/fstab.

This script often invokes various other scripts to do modular initialization. For example, in the common SysVinit structure, the directory /etc/rc.d/ contains a complex structure of subdirectories whose files specify how to enable and shut down most system services. However, on a bootdisk the sysinit script is often very simple.

When the sysinit script finishes control returns to init, which then enters the default runlevel, specified in inittab with the initdefault keyword. The runlevel line usually specifies a program like getty, which is responsible for handling commununications through the console and ttys. It is the getty program which prints the familiar ``login:'' prompt. The getty program in turn invokes the login program to handle login validation and to set up user sessions.

3.2. Disk types

Having reviewed the basic boot process, we can now define various kinds of disks involved. We classify disks into four types. The discussion here and throughout this document uses the term ``disk'' to refer to floppy diskettes unless otherwise specified, though most of the discussion could apply equally well to hard disks.

In general, when we talk about ``building a bootdisk'' we mean creating both the boot (kernel) and root (files) portions. They may be either together (a single boot/root disk) or separate (boot + root disks). The most flexible approach for rescue diskettes is probably to use separate boot and root diskettes, and one or more utility diskettes to handle the overflow.

4.1. Overview

A root filesystem must contain everything needed to support a full Linux system. To be able to do this, the disk must include the minimum requirements for a Linux system:

• The basic file system structure,

• Minimum set of directories: /dev, /proc, /bin, /etc, /lib, /usr, /tmp,

• Basic set of utilities: sh, ls, cp, mv, etc.,

• Minimum set of config files: rc, inittab, fstab, etc.,

• Devices: /dev/hd*, /dev/tty*, /dev/fd0, etc.,

• Runtime library to provide basic functions used by utilities.

Of course, any system only becomes useful when you can run something on it, and a root diskette usually only becomes useful when you can do something like:

• Check a file system on another drive, for example to check your root file system on your hard drive, you need to be able to boot Linux from another drive, as you can with a root diskette system. Then you can run fsck on your original root drive while it is not mounted.

• Restore all or part of your original root drive from backup using archive and compression utilities such as cpio, tar, gzip and ftape.

We describe how to build a compressed filesystem, so called because it is compressed on disk and, when booted, is uncompressed onto a ramdisk. With a compressed filesystem you can fit many files (approximately six megabytes) onto a standard 1440K diskette. Because the filesystem is much larger than a diskette, it cannot be built on the diskette. We have to build it elsewhere, compress it, then copy it to the diskette.

4.2. Creating the filesystem

In order to build such a root filesystem, you need a spare device that is large enough to hold all the files before compression. You will need a device capable of holding about four megabytes. There are several choices:

• Use a ramdisk (DEVICE = /dev/ram0). In this case, memory is used to simulate a disk drive. The ramdisk must be large enough to hold a filesystem of the appropriate size. If you use LILO, check your configuration file (/etc/lilo.conf) for a line like RAMDISK = nnn which determines the maximum RAM that can be allocated to a ramdisk. The default is 4096K, which should be sufficient. You should probably not try to use such a ramdisk on a machine with less than 8MB of RAM. Check to make sure you have a device like /dev/ram0, /dev/ram or /dev/ramdisk. If not, create /dev/ram0 with mknod (major number 1, minor 0).

• If you have an unused hard disk partition that is large enough (several megabytes), this is acceptable.

• Use a loopback device, which allows a disk file to be treated as a device. Using a loopback device you can create a three megabyte file on your hard disk and build the filesystem on it.

  Type man losetup for instructions on using loopback devices. If you don't have losetup, you can get it along with compatible versions of mount and unmount from the util-linux package in the directory ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/.

  If you do not have a loop device (/dev/loop0, /dev/loop1, etc.) on your system, you will have to create one with ``mknod /dev/loop0 b 7 0''. Once you've installed these special mount and umount binaries, create a temporary file on a hard disk with enough capacity (eg, /tmp/fsfile). You can use a command like:

  dd if=/dev/zero of=/tmp/fsfile bs=1k count=nnn

  to create an nnn-block file.

  Use the file name in place of DEVICE below. When you issue a mount command you must include the option -o loop to tell mount to use a loopback device.

After you've chosen one of these options, prepare the DEVICE with:

dd if=/dev/zero of=DEVICE bs=1k count=4096

This command zeroes out the device.

Zeroing the device is critical because the filesystem will be compressed later, so all unused portions should be filled with zeroes to achieve maximum compression. Keep this in mind whenever you move or delete files on the filesystem. The filesystem will correctly de-allocate the blocks, but it will not zero them out again. If you do a lot of deletions and copying, your compressed filesystem may end up much larger than necessary.

Next, create the filesystem. The Linux kernel recognizes two file system types for root disks to be automatically copied to ramdisk. These are minix and ext2, of which ext2 is preferred. If using ext2, you may find it useful to use the -N option to specify more inodes than the default; -N 2000 is suggested so that you don't run out of inodes. Alternatively, you can save on inodes by removing lots of unnecessary /dev files. mke2fs will by default create 360 inodes on a 1.44Mb diskette. I find that 120 inodes is ample on my current rescue root diskette, but if you include all the devices in /dev you will easily exceed 360. Using a compressed root filesystem allows a larger filesystem, and hence more inodes by default, but you may still need to either reduce the number of files or increase the number of inodes.

So the command you use will look like:

mke2fs -m 0 -N 2000 DEVICE

(If you're using a loopback device, the disk file you're using should be supplied in place of this DEVICE.)

The mke2fs command will automatically detect the space available and configure itself accordingly. The ``-m�0'' parameter prevents it from reserving space for root, and hence provides more usable space on the disk.

Next, mount the device:

mount -t ext2 DEVICE /mnt

(You must create a mount point /mnt if it does not already exist.) In the remaining sections, all destination directory names are assumed to be relative to /mnt.

4.3. Populating the filesystem

Here is a reasonable minimum set of directories for your root filesystem [1]:

• /dev -- Device files, required to perform I/O

• /proc -- Directory stub required by the proc filesystem

• /etc -- System configuration files

• /sbin -- Critical system binaries

• /bin -- Essential binaries considered part of the system

• /lib -- Shared libraries to provide run-time support

• /mnt -- A mount point for maintenance on other disks

• /usr -- Additional utilities and applications

Three of these directories will be empty on the root filesystem, so they only need to be created with mkdir. The /proc directory is basically a stub under which the proc filesystem is placed. The directories /mnt and /usr are only mount points for use after the boot/root system is running. Hence again, these directories only need to be created.

The remaining four directories are described in the following sections.

---

4.3.1. /dev

A /dev directory containing a special file for all devices to be used by the system is mandatory for any Linux system. The directory itself is a normal directory, and can be created with mkdir in the normal way. The device special files, however, must be created in a special way, using the mknod command.

There is a shortcut, though — copy devices files from your existing hard disk /dev directory. The only requirement is that you copy the device special files using -R option. This will copy the directory without attempting to copy the contents of the files. Be sure to use an upper case R. For example:

cp -dpR /dev/fd[01]* /mnt/dev cp -dpR /dev/tty[0-6] /mnt/dev

assuming that the diskette is mounted at /mnt. The dp switches ensure that symbolic links are copied as links, rather than using the target file, and that the original file attributes are preserved, thus preserving ownership information.

If you want to do it the hard way, use ls -l to display the major and minor device numbers for the devices you want, and create them on the diskette using mknod.

However the devices files are created, check that any special devices you need have been placed on the rescue diskette. For example, ftape uses tape devices, so you will need to copy all of these if you intend to access your floppy tape drive from the bootdisk.

Note that one inode is required for each device special file, and inodes can at times be a scarce resource, especially on diskette filesystems. You'll need to be selective about the device files you include. For example, if you do not have SCSI disks you can safely ignore /dev/sd*; if you don't intend to use serial ports you can ignore /dev/ttyS*.

If, in building your root filesystem, you get the error No space left on device but a df command shows space still available, you have probably run out of inodes. A df -i will display inode usage.

Be sure to include the following files from this directory: console, kmem, mem, null, ram0 and tty1.

        ls -ltru

---

4.3.3. /bin and /sbin

The /bin directory is a convenient place for extra utilities you need to perform basic operations, utilities such as ls, mv, cat and dd. See Appendix C for an example list of files that go in a /bin and /sbin directories. It does not include any of the utilities required to restore from backup, such as cpio, tar and gzip. That is because I place these on a separate utility diskette, to save space on the boot/root diskette. Once the boot/root diskette is booted, it is copied to the ramdisk leaving the diskette drive free to mount another diskette, the utility diskette. I usually mount this as /usr.

Creation of a utility diskette is described below in Section 9.2. It is probably desirable to maintain a copy of the same version of backup utilities used to write the backups so you don't waste time trying to install versions that cannot read your backup tapes.

Be sure to include the following programs: init, getty or equivalent, login, mount, some shell capable of running your rc scripts, a link from sh to the shell.

4.4. Providing for PAM and NSS

Your system may require dynamically loaded libraries that are not visible to ldd. If you don't provide for these, you may have trouble logging in or using your bootdisk.

4.5. Modules

If you have a modular kernel, you must consider which modules you may want to load from your bootdisk after booting. You might want to include ftape and zftape modules if your backup tapes are on floppy tape, modules for SCSI devices if you have them, and possibly modules for PPP or SLIP support if you want to access the net in an emergency.

These modules may be placed in /lib/modules. You should also include insmod, rmmod and lsmod. Depending on whether you want to load modules automatically, you might also include modprobe, depmod and swapout. If you use kerneld, include it along with /etc/conf.modules.

However, the main advantage to using modules is that you can move non-critical modules to a utility disk and load them when needed, thus using less space on your root disk. If you may have to deal with many different devices, this approach is preferable to building one huge kernel with many drivers built in.

In order to boot a compressed ext2 filesystem, you must have ramdisk and ext2 support built-in. They cannot be supplied as modules.

4.6. Some final details

Some system programs, such as login, complain if the file /var/run/utmp and the directory /var/log do not exist. So:

        mkdir -p /mnt/var/{log,run}
        touch /mnt/var/run/utmp

Finally, after you have set up all the libraries you need, run ldconfig to remake /etc/ld.so.cache on the root filesystem. The cache tells the loader where to find the libraries. You can do this with:

ldconfig -r /mnt

4.7. Wrapping it up

When you have finished constructing the root filesystem, unmount it, copy it to a file and compress it:

umount /mnt dd if=DEVICE bs=1k | gzip -v9 > rootfs.gz

When this finishes you will have a file rootfs.gz. This is your compressed root filesystem. You should check its size to make sure it will fit on a diskette; if it doesn't you'll have to go back and remove some files. Some suggestions for reducing root filesystem size appear in Section 8.

6.1. Transferring the kernel with LILO

First, make sure you have a recent version of LILO.

You must create a small configuration file for LILO. It should look like this:

boot =/dev/fd0 install =/boot/boot.b map =/boot/map read-write backup =/dev/null compact image = KERNEL label = Bootdisk root =/dev/fd0

For an explanation of these parameters, see LILO's user documentation. You will probably also want to add an append=... line to this file from your hard disk's /etc/lilo.conf file.

Save this file as bdlilo.conf.

You now have to create a small filesystem, which we shall call a kernel filesystem, to distinguish it from the root filesystem.

First, figure out how large the filesystem should be. Take the size of your kernel in blocks (the size shown by ``ls -s KERNEL'') and add 50. Fifty blocks is approximately the space needed for inodes plus other files. You can calculate this number exactly if you want to, or just use 50. If you're creating a two-disk set, you may as well overestimate the space since the first disk is only used for the kernel anyway. Call this number KERNEL_BLOCKS.

Put a floppy diskette in the drive (for simplicity we'll assume /dev/fd0) and create an ext2 kernel filesystem on it:

mke2fs -N 24 -m 0 /dev/fd0 KERNEL_BLOCKS

The ``-N 24'' specifies 24 inodes, which is all you should need for this filesystem. Next, mount the filesystem, remove the lost+found directory, and create dev and boot directories for LILO:

mount -o dev /dev/fd0 /mnt rm -rf /mnt/lost+found mkdir /mnt/{boot,dev}

Next, create devices /dev/null and /dev/fd0. Instead of looking up the device numbers, you can just copy them from your hard disk using -R:

cp -R /dev/{null,fd0} /mnt/dev

LILO needs a copy of its boot loader, boot.b, which you can take from your hard disk. It is usually kept in the /boot directory.

cp /boot/boot.b /mnt/boot

Finally, copy in the LILO configuration file you created in the last section, along with your kernel. Both can be put in the root directory:

cp bdlilo.conf KERNEL /mnt

Everything LILO needs is now on the kernel filesystem, so you are ready to run it. LILO's -r flag is used for installing the boot loader on some other root:

lilo -v -C bdlilo.conf -r /mnt

LILO should run without error, after which the kernel filesystem should look something like this:

total 361 1 –rw–r––r–– 1 root root 176 Jan 10 07:22 bdlilo.conf 1 drwxr–xr–x 2 root root 1024 Jan 10 07:23 boot/ 1 drwxr–xr–x 2 root root 1024 Jan 10 07:22 dev/ 358 –rw–r––r–– 1 root root 362707 Jan 10 07:23 vmlinuz boot: total 8 4 –rw–r––r–– 1 root root 3708 Jan 10 07:22 boot.b 4 –rw––––––– 1 root root 3584 Jan 10 07:23 map dev: total 0 0 brw–r––––– 1 root root 2, 0 Jan 10 07:22 fd0 0 crw–r––r–– 1 root root 1, 3 Jan 10 07:22 null

Do not worry if the file sizes are slightly different from yours.

Now leave the diskette in the drive and go to Section 6.3.

6.2. Transferring the kernel without LILO

If you are not using LILO, transfer the kernel to the bootdisk with dd:

% dd if=KERNEL of=/dev/fd0 bs=1k 353+1 records in 353+1 records out

In this example, dd wrote 353 complete records + 1 partial record, so the kernel occupies the first 354 blocks of the diskette. Call this number KERNEL_BLOCKS and remember it for use in the next section.

Finally, set the root device to be the diskette itself, then set the root to be loaded read/write:

rdev /dev/fd0 /dev/fd0 rdev -R /dev/fd0 0

Be careful to use a capital -R in the second rdev command.

6.3. Setting the ramdisk word

Inside the kernel image is the ramdisk word that specifies where the root filesystem is to be found, along with other options. The word can be accessed and set via the rdev command, and its contents are interpreted as follows:

If bit 15 is set, on boot-up you will be prompted to place a new floppy diskette in the drive. This is necessary for a two-disk boot set.

There are two cases, depending on whether you are building a single boot/root diskette or a double ``boot+root'' diskette set.

1. If you are building a single disk, the compressed root filesystem will be placed right after the kernel, so the offset will be the first free block (which should be the same as KERNEL_BLOCKS). Bit 14 will be set to 1, and bit 15 will be zero. For example, say you're building a single disk and the root filesystem will begin at block 253 (decimal). The ramdisk word value should be 253 (decimal) with bit 14 set to 1 and bit 15 set to 0. To calculate the value you can simply add the decimal values. 253 + (2^14) = 253 + 16384 = 16637. If you don't quite understand where this number comes from, plug it into a scientific calculator and convert it to binary,

2. If you are building a two-disk set, the root filesystem will begin at block zero of the second disk, so the offset will be zero. Bit 14 will be set to 1 and bit 15 will be 1. The decimal value will be 2^14 + 2^15 = 49152 in this case.

After carefully calculating the value for the ramdisk word, set it with rdev -r. Be sure to use the decimal value. If you used LILO, the argument to rdev here should be the mounted kernel path, e.g. /mnt/vmlinuz; if you copied the kernel with dd, instead use the floppy device name (e.g., /dev/fd0).

rdev -r KERNEL_OR_FLOPPY_DRIVE VALUE

If you used LILO, unmount the diskette now.

Do not believe what the rdev/ramsize manpage says about ramdisk size. The manpage is obsolete. As of kernel 2.0 or so, the ramdisk word no longer determines the ramdisk size; the word is instead interpreted according to the table at the beginning of section Section 6.3. For a detailed explanation, see the documentation file ramdisk.txt or http://www.linuxhq.com/kernel/v2.4/doc/ramdisk.txt.html.

6.4. Transferring the root filesystem

The last step is to transfer the root filesystem.

• If the root filesystem will be placed on the same disk as the kernel, transfer it using dd with the seek option, which specifies how many blocks to skip:

  dd if=rootfs.gz of=/dev/fd0 bs=1k seek=KERNEL_BLOCKS

• If the root filesystem will be placed on a second disk, remove the first diskette, put the second diskette in the drive, then transfer the root filesystem to it:

  dd if=rootfs.gz of=/dev/fd0 bs=1k

Congratulations, you are done!

You should always test a bootdisk before putting it aside for an emergency. If it fails to boot, read on.

8.1. Increase the diskette density

By default, floppy diskettes are formatted at 1440K, but higher density formats are possible. Whether you can boot from higher density disks depends mostly on your BIOS. fdformat will format disks for the following sizes: 1600K, 1680K, 1722K, 1743K, 1760K, 1840K, and 1920K. See the fdformat man page and /usr/src/linux/Documentation/devices.txt.

But what diskette densities/geometries will your machine support? Here are some (lightly edited) answers from Alain Knaff, the author of fdutils.

This is more an issue of the BIOS rather than the physical format of the disk. If the BIOS decides that any sector number greater than 18 is bad, then there is not much we can do. Indeed, short of disassembling the BIOS, trial and error seems to be the only way to find out. However, if the BIOS supports ED disks (extra density: 36 sectors/track and 2.88MB), there's a chance that 1722K disks are supported as well.

Superformatted disks with more than 21 sectors/track are likely not bootable: indeed, those use sectors of non-standard sizes (1024 bytes in a sector instead of 512, for example), and are likely not bootable. It should however be possible to write a special bootsector program to work around this. If I remember correctly, the DOS 2m utility has such a beast, as does OS/2's XDF utilities.

Some BIOSes artificially claim that any sector number greater than 18 must be in error. As 1722K disks use sector numbers up to 21, these would not be bootable. The best way to test would be to format a test DOS or syslinus disk as 1722K and make it bootable. If you use LILO, don't use the option linear (or else LILO would assume that the disk is the default 18 sectors/track, and the disk will fail to boot even if supported by the BIOS).

8.2. Replace common utilities with BusyBox

Much root filesystem space is consumed by common GNU system utilities such as cat, chmod, cp, dd, df, etc. The BusyBox project was designed to provide minimal replacements for these common system utilities. BusyBox supplies one single monolithic executable file, /bin/busybox, about 150K, which implements the functions of these utilities. You then create symlinks from different utilities to this executable; busybox sees how it was called and invokes the correct code. BusyBox even includes a basic shell. BusyBox is available in binary packages for many distributions, and source code is available from the BusyBox site.

8.3. Use an alternate shell

Some of the popular shells for Linux, such as bash and tcsh, are large and require many libraries. If you don't use the BusyBox shell, you should still consider replacing your shell anyway. Some light-weight alternatives are ash, lsh, kiss and smash, which are much smaller and require few (or no) libraries. Most of these replacement shells are available from http://www.ibiblio.org/pub/Linux/system/shells/. Make sure any shell you use is capable of running commands in all the rc files you include on your bootdisk.

8.4. Strip libraries and binaries

Many libraries and binaries are distributed with debugging information. Running file on these files will tell you ``not stripped'' if so. When copying binaries to your root filesystem, it is good practice to use:

objcopy --strip-all FROM TO

When copying libraries, be sure to use strip-debug instead of strip-all.

8.5. Move files to a utility disk

If some of your binaries are not needed immediately to boot or login, you can move them to a utility disk. See Section 9.2 for details. You may also consider moving modules to a utility disk as well.

9.1. Non-ramdisk root filesystems

Section 4 gave instructions for building a compressed root filesystem which is loaded to ramdisk when the system boots. This method has many advantages so it is commonly used. However, some systems with little memory cannot afford the RAM needed for this, and they must use root filesystems mounted directly from the diskette.

Such filesystems are actually easier to build than compressed root filesystems because they can be built on a diskette rather than on some other device, and they do not have to be compressed. We will outline the procedure as it differs from the instructions above. If you choose to do this, keep in mind that you will have much less space available.

1. Calculate how much space you will have available for root files. If you are building a single boot/root disk, you must fit all blocks for the kernel plus all blocks for the root filesystem on the one disk.

2. Using mke2fs, create a root filesystem on a diskette of the appropriate size.

3. Populate the filesystem as described above.

4. When done, unmount the filesystem and transfer it to a disk file but do not compress it.

5. Transfer the kernel to a floppy diskette, as described above. When calculating the ramdisk word, set bit 14 to zero, to indicate that the root filesystem is not to be loaded to ramdisk. Run the rdev's as described.

6. Transfer the root filesystem as before.

There are several shortcuts you can take. If you are building a two-disk set, you can build the complete root filesystem directly on the second disk and you need not transfer it to a hard disk file and then back. Also, if you are building a single boot/root disk and using LILO, you can build a single filesystem on the entire disk, containing the kernel, LILO files and root files, and simply run LILO as the last step.

9.2. Building a utility disk

Building a utility disk is relatively easy -- simply create a filesystem on a formatted disk and copy files to it. To use it with a bootdisk, mount it manually after the system is booted.

In the instructions above, we mentioned that the utility disk could be mounted as /usr. In this case, binaries could be placed into a /bin directory on your utility disk, so that placing /usr/bin in your path will access them. Additional libraries needed by the binaries are placed in /lib on the utility disk.

There are several important points to keep in mind when designing a utility disk:

1. Do not place critical system binaries or libraries onto the utility disk, since it will not be mountable until after the system has booted.

2. You cannot access a floppy diskette and a floppy tape drive simultaneously. This means that if you have a floppy tape drive, you will not be able to access it while your utility disk is mounted.

3. Access to files on the utility disk will be slow.

Appendix D shows a sample of files on a utility disk. Here are some ideas for files you may find useful: programs for examining and manipulating disks (format, fdisk) and filesystems (mke2fs, fsck, debugfs, isofs.o), a lightweight text editor (elvis, jove), compression and archive utilities (gzip, bzip, tar, cpio, afio), tape utilities (mt, ftmt, tob, taper), communications utilities (ppp.o, slip.o, minicom) and utilities for devices (setserial, mknod).

11.1. What is El Torito?

For the x86 platform, many BIOS's have begun to support bootable CDs. The patches for mkisofs is based on the standard called "El Torito". Simply put, El Torito is a specification that says how a cdrom should be formatted such that you can directly boot from it.

The "El Torito" spec says that any cdrom drive should work (SCSI or EIDE) as long as the BIOS supports El Torito. So far this has only been tested with EIDE drives because none of the SCSI controllers that has been tested so far appears to support El Torito. The motherboard definately has to support El Torito. How do you know if your motherboard supports "El Torito"? Well, the ones that support it let you choose booting from hard disk, Floppy, Network or CDROM.

11.2. How it Works

The El Torito standard works by making the CD drive appear, through BIOS calls, to be a normal floppy drive. This way you simply put any floppy size image (exactly 1440k for a 1.44 meg floppy) somewhere in the ISO filesystem. In the headers of the ISO fs you place a pointer to this image. The BIOS will then grab this image from the CD and for all purposes it acts as if it were booting from the floppy drive. This allows a working LILO boot disk, for example, to simply be used as is.

Roughly speaking, the first 1.44 (or 2.88 if supported) Mbytes of the CD-ROM contains a floppy-disk image supplied by you. This image is treated like a floppy by the BIOS and booted from. (As a consequence, while booting from this virtual floppy, your original drive A: (/dev/fd0) may not be accessible, but you can try with /dev/fd1).

11.3. How to make it work

First create a file, say "boot.img", which is an exact image of the bootable floppy-disk which you want to boot via the CD-ROM. This must be an 1.44 MB bootable floppy-disk. The command below will do this

dd if=/dev/fd0 of=boot.img bs=10k count=144

assuming the floppy is in the A: drive.

Place this image somewhere in the hierarchy which will be the source for the iso9660 filesystem. It is a good idea to put all boot related files in their own directory ("boot/" under the root of the iso9660 fs, for example).

One caveat -- Your boot floppy must load any initial ramdisk via LILO, not the kernel ramdisk driver! This is because once the linux kernel starts up, the BIOS emulation of the CD as a floppy disk is circumvented and will fail. LILO will load the initial ramdisk using BIOS disk calls, so the emulation works as designed.

The El Torito specification requires a "boot catalog" to be created as well. This is a 2048 byte file which is of no interest except it is required. The patchwork done by the author of mkisofs will cause it to automatically create the boot catalog, but you must specify where the boot catalog will go in the iso9660 filesystem. Usually it is a good idea to put it in the same place as the boot image, and a name like boot.catalog seems appropriate.

So we have our boot image in the file boot.img, and we are going to put it in the directory boot/ under the root of the iso9660 filesystem. We will have the boot catalog go in the same directory with the name boot.catalog. The command to create the iso9660 fs in the file bootcd.iso is then:

mkisofs -r -b boot/boot.img -c boot/boot.catalog -o bootcd.iso .

The -b option specifies the boot image to be used (note the path is relative to the root of the iso9660 disk), and the -c option is for the boot catalog file. The -r option will make approptiate file ownerships and modes (see the mkisofs manpage). The "." in the end says to take the source from the current directory.

Now burn the CD with the usual cdrecord command and it is ready to boot.

11.4. Create Win9x Bootable CD-Roms

The first step is to get hold of the bootable image used by the source CD. But you cannot simply mount the CD under linux and dd the first 1440k to a floppy disk or to a file like boot.img. Instead you simply boot with the source CD-ROM.

When you boot the Win98 CD you are dropped to A: prompt which is the actual ramdisk. And D: or Z: is where all the installables are residing. By using the diskcopy command of dos copy the A: image into the actual floppy drive which is now B: The command below will do this.

diskcopy A: B:

It works just like dd. You can try booting from this newly created disk to test if the booting process is similar to that of the source CD. Then the usual dd of this floppy to a file like boot.img and then rest is as usual.