Copyright © 1995-2002 by Tom Fawcett
v4.5, January 2002
This document describes how to design and build boot/root diskettes for Linux. These disks can be used as rescue disks or to test new system components. You should be reasonably familiar with system administration tasks before attempting to build a bootdisk. If you just want a rescue disk to have for emergencies, see Appendix A.1.
Although this document should be legible in its text form, it looks much better in Postscript, PDF or HTML forms because of the typographical conventions used.
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.
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.
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.
Linux boot disks are useful in a number of situations, such as testing a new kernel, recovering from a disk failure (anything from a lost boot sector to a disk head crash), fixing a disabled system, or upgrading critical system files safely (such as libc.so).
There are several ways of obtaining boot disks:
This document assumes some basic familiarity with Linux system administration concepts. For example, you should know about directories, filesystems and floppy diskettes. You should know how to use mount and df. You should know what /etc/passwd and fstab files are for and what they look like. You should know that most of the commands in this HOWTO should be run as root.
Constructing a bootdisk from scratch can be complicated. If you haven't read the Linux FAQ and related documents, such as the Linux Installation HOWTO and the Linux Installation Guide, you should not be trying to build boot diskettes. If you just need a working bootdisk for emergencies, it is much easier to download a prefabricated one. See Appendix A.1, below, for where to find these.
A bootdisk is basically a miniature, self-contained Linux system on a diskette. It must perform many of the same functions that a complete full-size Linux system performs. Before trying to build one you should understand the basic Linux boot process. Here we present the basics, which are sufficient for understanding the rest of this document. Many details and alternative options have been omitted.
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:
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:
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.
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.
Creating the root filesystem involves selecting files necessary for the system to run. In this section we describe how to build a compressed root filesystem. A less common option is to build an uncompressed filesystem on a diskette that is directly mounted as root; this alternative is described in Section 9.1.
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:
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:
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.
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:
After you've chosen one of these options, prepare the DEVICE with:
This command zeroes out the device.
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:
(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:
Here is a reasonable minimum set of directories for your root filesystem :
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.
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:
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.
The /etc directory contains configuration files. What it should contain depends on what programs you intend to run. On most systems, these can be divided into three groups:
On my root diskettes, I have the number of config files down to 15. This reduces my work to dealing with three sets of files:
Out of this, I only really have to configure two files, and what they should contain is surprisingly small.
Your inittab should be changed so that its sysinit line runs rc or whatever basic boot script will be used. Also, if you want to ensure that users on serial ports cannot login, comment out all the entries for getty which include a ttys or ttyS device at the end of the line. Leave in the tty ports so that you can login at the console.
A minimal inittab file looks like this:
Note that some programs cannot be moved elsewhere because other programs have hardcoded their locations. For example, on my system, /etc/shutdown has hardcoded in it /etc/reboot. If I move reboot to /bin/reboot, and then issue a shutdown command, it will fail because it cannot find the reboot file.
For the rest, just copy all the text files in your /etc directory, plus all the executables in your /etc directory that you cannot be sure you do not need. As a guide, consult the sample listing in Appendix C. Probably it will suffice to copy only those files, but systems differ a great deal, so you cannot be sure that the same set of files on your system is equivalent to the files in the list. The only sure method is to start with inittab and work out what is required.
Most systems now use an /etc/rc.d/ directory containing shell scripts for different run levels. The minimum is a single rc script, but it may be simpler just to copy inittab and the /etc/rc.d directory from your existing system, and prune the shell scripts in the rc.d directory to remove processing not relevent to a diskette system environment.
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.
In /lib you place necessary shared libraries and loaders. If the necessary libraries are not found in your /lib directory then the system will be unable to boot. If you're lucky you may see an error message telling you why.
Nearly every program requires at least the libc library, libc.so.N, where N is the current version number. Check your /lib directory. The file libc.so.N is usually a symlink to a filename with a complete version number:
In this case, you want libc-2.1.1.so. To find other libraries you should go through all the binaries you plan to include and check their dependencies with ldd. For example:
Note that some libraries are quite large and will not fit easily on your root filesystem. For example, the libc.so listed above is about 4 meg. You will probably need to strip libraries when copying them to your root filesystem. See Section 8 for instructions.
In /lib you must also include a loader for the libraries. The loader will be either ld.so (for A.OUT libraries, which are no longer common) or ld-linux.so (for ELF libraries). Newer versions of ldd tell you exactly which loader is needed, as in the example above, but older versions may not. If you're unsure which you need, run the file command on the library. For example:
Copy the specific loader(s) you need to the root filesystem you're building. Libraries and loaders should be checked carefully against the included binaries. If the kernel cannot load a necessary library, the kernel may hang with no error message.
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.
If your system uses PAM (Pluggable Authentication Modules), you must make some provision for it on your bootdisk. Briefly, PAM is a sophisticated modular method for authenticating users and controlling their access to services. An easy way to determine if your system uses PAM is run ldd on your login executable; if the output includes libpam.so, you need PAM.
Fortunately, security is usually of no concern with bootdisks since anyone who has physical access to a machine can usually do anything they want anyway. Therefore, you can effectively disable PAM by creating a simple /etc/pam.conf file in your root filesystem that looks like this:
This configuration allows anyone complete access to the files and services on your machine. If you care about security on your bootdisk for some reason, you'll have to copy some or all of your hard disk's PAM setup to your root filesystem. Be sure to read the PAM documentation carefully, and copy any libraries needed in /lib/security onto your root filesystem.
You must also include /lib/libpam.so on your bootdisk. But you already know this since you ran ldd on /bin/login, which showed this dependency.
If you are using glibc (aka libc6), you will have to make provisions for name services or you will not be able to login. The file /etc/nsswitch.conf controls database lookups for various servies. If you don't plan to access services from the network (eg, DNS or NIS lookups), you need only prepare a simple nsswitch.conf file that looks like this:
If you plan to access the network from your bootdisk, you may want to create a more elaborate nsswitch.conf file. See the nsswitch man page for details. You must include a file /lib/libnss_service.so.1 for each service you specify.
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.
Some system programs, such as login, complain if the file /var/run/utmp and the directory /var/log do not exist. So:
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:
When you have finished constructing the root filesystem, unmount it, copy it to a file and compress it:
At this point you have a complete compressed root filesystem. The next step is to build or select a kernel. In most cases it would be possible to copy your current kernel and boot the diskette from that. However, there may be cases where you wish to build a separate one.
One reason is size. If you are building a single boot/root diskette, the kernel will be one of the largest files on the diskette so you will have to reduce the size of the kernel as much as possible. To reduce kernel size, build it with the minumum set of facilities necessary to support the desired system. This means leaving out everything you don't need. Networking is a good thing to leave out, as well as support for any disk drives and other devices which you don't need when running your boot/root system. As stated before, your kernel must have ramdisk and ext2 support built into it.
Having worked out a minimum set of facilities to include in a kernel, you then need to work out what to add back in. Probably the most common uses for a boot/root diskette system would be to examine and restore a corrupted root file system, and to do this you may need kernel support. For example, if your backups are all held on tape using Ftape to access your tape drive, then, if you lose your current root drive and drives containing Ftape, then you will not be able to restore from your backup tapes. You will have to reinstall Linux, download and reinstall ftape, and then try to read your backups.
The point here is that, whatever I/O support you have added to your kernel to support backups should also be added into your boot/root kernel.
The procedure for actually building the kernel is described in the documentation that comes with the kernel. It is quite easy to follow, so start by looking in /usr/src/linux. If you have trouble building a kernel, you should probably not attempt to build boot/root systems anyway. Remember to compress the kernel with ``make zImage''.
At this point you have a kernel and a compressed root filesystem. If you are making a boot/root disk, check their sizes to make sure they will both fit on one disk. If you are making a two disk boot+root set, check the root filesystem to make sure it will fit on a single diskette.
You should decide whether to use LILO to boot the bootdisk kernel. The alternative is to copy the kernel directly to the diskette and boot without LILO. The advantage of using LILO is that it enables you to supply some parameters to the kernel which may be necessary to initialize your hardware (Check the file /etc/lilo.conf on your system. If it exists and has a line like ``append=...'', you probably need this feature). The disadvantage of using LILO is that building the bootdisk is more complicated and takes slightly more space. You will have to set up a small separate filesystem, which we shall call the kernel filesystem, where you transfer the kernel and a few other files that LILO needs.
If you are going to use LILO, read on; if you are going to transfer the kernel directly, skip ahead to Section 6.2.
First, make sure you have a recent version of LILO.
You must create a small configuration file for LILO. It should look like this:
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:
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:
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.
If you are not using LILO, transfer the kernel to the bootdisk with dd:
Finally, set the root device to be the diskette itself, then set the root to be loaded read/write:
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.
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).
If you used LILO, unmount the diskette now.
The last step is to transfer the root filesystem.
Congratulations, you are done!
When building bootdisks, the first few tries often will not boot. The general approach to building a root disk is to assemble components from your existing system, and try and get the diskette-based system to the point where it displays messages on the console. Once it starts talking to you, the battle is half over because you can see what it is complaining about, and you can fix individual problems until the system works smoothly. If the system just hangs with no explanation, finding the cause can be difficult. The recommended procedure for investigating the problem where the system will not talk to you is as follows:
Once these general aspects have been covered, here are some more specific files to check:
If init starts, but you get a message like:
If you get a login prompt, and you enter a valid login name but the system prompts you for another login name immediately, the problem may be with PAM or NSS. See Section 4.4. The problem may also be that you use shadow passwords and didn't copy /etc/shadow to your bootdisk.
If you try to run some executable, such as df, which is on your rescue disk but you yields a message like: df: not found, check two things: (1) Make sure the directory containing the binary is in your PATH, and (2) make sure you have libraries (and loaders) the program needs.
One of the main problems with building bootdisks is getting everything to fit into one (or even two) diskettes. Even when files are compressed this can be very difficult, because Linux system components keep growing. Here are some common techniques used to make everything fit.
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.
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.
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.
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:
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.
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.
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:
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).
You may notice that the bootdisks used by major distributions such as Slackware, RedHat or Debian seem more sophisticated than what is described in this document. Professional distribution bootdisks are based on the same principles outlined here, but employ various tricks because their bootdisks have additional requirements. First, they must be able to work with a wide variety of hardware, so they must be able to interact with the user and load various device drivers. Second, they must be prepared to work with many different installation options, with varying degrees of automation. Finally, distribution bootdisks usually combine installation and rescue capabilities.
Some bootdisks use a feature called initrd (initial ramdisk). This feature was introduced around 2.0.x and allows a kernel to boot in two phases. When the kernel first boots, it loads an initial ramdisk image from the boot disk. This initial ramdisk is a root filesystem containing a program that runs before the real root fs is loaded. This program usually inspects the environment and/or asks the user to select various boot options, such as the device from which to load the real rootdisk. It typically loads additional modules not built in to the kernel. When this initial program exits, the kernel loads the real root image and booting continues normally. For further information on initrd, see your local file /usr/src/linux/Documentation/initrd.txt and ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz
The following are summaries of how each distribution's installation disks seem to work, based on inspecting their filesystems and/or source code. We do not guarantee that this information is completely accurate, or that they have not changed since the versions noted.
Slackware (v.3.1) uses a straightforward LILO boot similar to what is described in Section 6.1. The Slackware bootdisk prints a bootup message (“Welcome to the Slackware Linux bootkernel disk!”) using LILO's message parameter. This instructs the user to enter a boot parameter line if necessary. After booting, a root filesystem is loaded from a second disk. The user invokes a setup script which starts the installation. Instead of using a modular kernel, Slackware provides many different kernels and depends upon the user to select the one matching his or her hardware requirements.
RedHat (v.4.0) also uses a LILO boot. It loads a compressed ramdisk on the first disk, which runs a custom init program. This program queries for drivers then loads additional files from a supplemental disk if necessary.
Debian (v.1.3) is probably the most sophisticated of the installation disk sets. It uses the SYSLINUX loader to arrange various load options, then uses an initrd image to guide the user through installation. It appears to use both a customized init and a customized shell.
This section assumes that you are familiar with the process and workings of writing CDs in linux. Consider this to be a quick reference to include the ability to boot the CD which you will burn. The CD-Writing-HOWTO should give you an in-depth reference.
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.
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).
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
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:
Now burn the CD with the usual cdrecord command and it is ready to boot.
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.
A: See Section 7, above.
A: See Section 10, above.
A: See Section Section 8, above, for the comments by Alain Knaff on this subject. His is the most authoritative answer I know of.
A: This probably should be explained better in the text, but I'll put an answer here for the time being.
First, do not attempt to use the rdev or ramsize commands to do this, no matter what their documentation says. The ramdisk word no longer determines the size of ramdisks.
Second, keep in mind that ramdisks are actually dynamic; when you set a ramdisk size you aren't allocating any memory, you're just setting the limit of how large it can grow. Don't be afraid to set these fairly large (eg, 8 or even 16 meg). The RAM space is not actually consumed until you need it. You can set these limits in one of several ways.
A: See section Section 11.
A: Since I don't have an LS-120 drive, the following information is summarized from information provided by Dave Cinege from the Linux Router Project.
The LS-120 is an IDE floppy drive. It is compatible with both standard 3.5" disks and the new 120MB disks. As of Linux v2.0.31 there is full support. To be able to boot from these you must have a BIOS that specifically allows the LS-120 to be treated as drive 0 (whereas IDE devices normally start at 80). If you do not have BIOS support, you can purchase a small IDE FloppyMAX card from Promise Technologies to overcome this deficiency.
The kernel boot loader does not like the LS-120, and instantly dies. Also 2m disks do not like it and will not boot. 1.44MB through 1.74MB disks will work fine. SYSLINUX works with the 120MB disks as of v1.32. You would better off partitioning the disk and using ext2 or minix, instead of SYSLINUX unless you need MS-DOS compatibility.
LILO does work fine with 120MB disks. Here is a sample lilo.conf:
A: The easiest way is to obtain a Slackware kernel from your nearest Slackware mirror site. Slackware kernels are generic kernels which atttempt to include drivers for as many devices as possible, so if you have a SCSI or IDE controller, chances are that a driver for it is included in the Slackware kernel.
Go to the a1 directory and select either IDE or SCSI kernel depending on the type of controller you have. Check the xxxxkern.cfg file for the selected kernel to see the drivers which have been included in that kernel. If the device you want is in that list, then the corresponding kernel should boot your computer. Download the xxxxkern.tgz file and copy it to your boot diskette as described above in the section on making boot disks.
You must then check the root device in the kernel, using the command rdev zImage. If this is not the same as the root device you want, use rdev to change it. For example, the kernel I tried was set to /dev/sda2, but my root SCSI partition is /dev/sda8. To use a root diskette, you would have to use the command rdev zImage /dev/fd0.
If you want to know how to set up a Slackware root disk as well, that's outside the scope of this HOWTO, so I suggest you check the Linux Install Guide or get the Slackware distribution. See the section in this HOWTO titled ``References''.
A: The easiest way is to copy the filesystem from the rootdisk back to the DEVICE you used (from Section 4.2, above). Then mount the filesystem and make the changes. You have to remember where your root filesystem started and how many blocks it occupied:
A: This is not really a Bootdisk topic, but it is asked often. Within Linux, you can run:
You can also use the dd command to copy the backup saved by LILO to the boot sector. Refer to the LILO documentation if you wish to do this.
Within DOS and Windows you can use the DOS command:
A: If you don't have a boot disk standing by, probably the easiest method is to obtain a Slackware kernel for your disk controller type (IDE or SCSI) as described above for ``How do I make a boot disk with a XXX driver?''. You can then boot your computer using this kernel, then repair whatever damage there is.
The kernel you get may not have the root device set to the disk type and partition you want. For example, Slackware's generic SCSI kernel has the root device set to /dev/sda2, whereas my root Linux partition happens to be /dev/sda8. In this case the root device in the kernel will have to be changed.
You can still change the root device and ramdisk settings in the kernel even if all you have is a kernel, and some other operating system, such as DOS.
rdev changes kernel settings by changing the values at fixed offsets in the kernel file, so you can do the same if you have a hex editor available on whatever systems you do still have running -- for example, Norton Utilities Disk Editor under DOS. You then need to check and if necessary change the values in the kernel at the following offsets:
The interpretation of the ramdisk word was described in Section 6.3, above.
The major and minor device numbers must be set to the device you want to mount your root filesystem on. Some useful values to select from are:
A: Because magnetic media may deteriorate over time, you should keep several copies of your rescue disk, in case the original is unreadable.
The easiest way of making copies of any diskettes, including bootable and utility diskettes, is to use the dd command to copy the contents of the original diskette to a file on your hard drive, and then use the same command to copy the file back to a new diskette. Note that you do not need to, and should not, mount the diskettes, because dd uses the raw device interface.
To copy the original, enter the command:
To copy the resulting file back to a new diskette, insert the new diskette and enter the reverse command:
Note that the above discussion assumes that you have only one diskette drive. If you have two of the same type, you can copy diskettes using a command like:
A: Where a disk device cannot be autodetected it is necessary to supply the kernel with a command device parameter string, such as:
For example, a sample command line using the above parameter string would be:
This would pass the device parameter string through, and also ask the kernel to set the root device to /dev/sda1 and save the whole command line and reuse it for all future boots.
A sample APPEND statement is:
Note that the parameter string must not be enclosed in quotes on the command line, but it must be enclosed in quotes in the APPEND statement.
Note also that for the parameter string to be acted on, the kernel must contain the driver for that disk type. If it does not, then there is nothing listening for the parameter string, and you will have to rebuild the kernel to include the required driver. For details on rebuilding the kernel, go to /usr/src/linux and read the README, and read the Linux FAQ and Installation HOWTO. Alternatively you could obtain a generic kernel for the disk type and install that.
Readers are strongly urged to read the LILO documentation before experimenting with LILO installation. Incautious use of the BOOT statement can damage partitions.
A: There are several cases of program names being hardcoded in various utilities. These cases do not occur everywhere, but they may explain why an executable apparently cannot be found on your system even though you can see that it is there. You can find out if a given program has the name of another hardcoded by using the strings command and piping the output through grep.
Known examples of hardcoding are:
To fix these problems, either move the programs to the correct directory, or change configuration files (e.g. inittab) to point to the correct directory. If in doubt, put programs in the same directories as they are on your hard disk, and use the same inittab and /etc/rc.d files as they appear on your hard disk.
A: Where this occurs, a kernel message like this will appear as the kernel is booting:
This is probably because the size has been set to 0 by kernel parameters at boot time. This could possibly be because of an overlooked LILO configuration file parameter:
This was included in sample LILO configuration files in some older distributions, and was put there to override any previous kernel setting. If you have such a line, remove it.
Note that if you attempt to use a ramdisk of 0 size, the behaviour can be unpredictable, and can result in kernel panics.
When retrieving a package, always get the latest version unless you have good reasons for not doing so.
These are sources for distribution bootdisks. Please use one of the mirror sites to reduce the load on these machines.
In addition to the distribution bootdisks, the following rescue disk images are available. Unless otherwise specified, these are available in the directory http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html
Several packages for creating rescue disks are available on www.ibiblio.org. With these packages you specify a set of files for inclusion and the software automates (to varying degrees) the creation of a bootdisk. See http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html for more information. Check the file dates carefully. Some of these packages have not been updated in several years and will not support the creation of a compressed root filesystem loaded into ramdisk. To the best of our knowledge, Yard is the only package that will.
Written by Werner Almesberger. Excellent boot loader, and the documentation includes information on the boot sector contents and the early stages of the boot process.
Ftp from ftp://tsx-11.mit.edu/pub/linux/packages/lilo/. It is also available on Metalab and mirrors.
An excellent description of the how the ramdisk code works may be found with the documentation supplied with the Linux kernel. See /usr/src/linux/Documentation/ramdisk.txt. It is written by Paul Gortmaker and includes a section on creating a compressed ramdisk.
For more detail on the Linux boot process, here are some pointers:
Questions about these codes are asked so often on Usenet that we include them here as a public service. This summary is excerpted from Werner Almsberger's LILO User Documentation.
When LILO loads itself, it displays the word LILO. Each letter is printed before or after performing some specific action. If LILO fails at some point, the letters printed so far can be used to identify the problem.
If the BIOS signals an error when LILO is trying to load a boot image, the respective error code is displayed. These codes range from 0x00 through 0xbb. See the LILO User Guide for an explanation of these.