I classify boot-related disks into 4 types. The discussion here and throughout this document uses the term "disk" to refer to diskettes unless otherwise specified. Most of the discussion could be equally well applied to hard disks.
A summary of disk types and uses is:
A disk containing a kernel which can be booted. The disk can contain a filesystem and use a boot loader to boot, or it can simply contain the kernel only at the start of the disk. The disk can be used to boot the kernel using a root file system on another disk. This could be useful if you lost your boot loader due to, for example, an incorrect installation attempt.
A disk with a file system containing everything required to run a Linux system. It does not necessarily contain either a kernel or a boot loader.
This disk can be used to run the system independently of any other disks, once the kernel has been booted. A special kernel feature allows a separate root disk to be mounted after booting, with the root disk being automatically copied to a ramdisk.
You could use this type of disk to check another disk for corruption without mounting it, or to restore another disk after a disk failure or loss of files.
A disk which is the same as a root disk, but contains a kernel and a boot loader. It can be used to boot from, and to run the system. The advantage of this type of disk is that is it compact - everything required is on a single disk. However the gradually increasing size of everything means that it won't necessarily always be possbile to fit everything on a single diskette, even with compression.
A disk which contains a file system, but is not intended to be mounted as a root file system. It is an additional data disk. You would use this type of disk to carry additional utilities where you have too much to fit on your root disk.
The term "utility" only really applies to diskettes, where you would use a utility disk to store additional recovery utility software.
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.
All PC systems start the boot process by executing code in ROM to load the sector from sector 0, cylinder 0 of the boot drive and try and execute it. On most bootable disks, sector 0, cylinder 0 contains either:
If a Linux kernel has been written to a diskette as a raw device, then the first sector will be the first sector of the Linux kernel itself, and this sector will continue the boot process by loading the rest of the kernel and running Linux. For a more detailed description of the boot sector contents, see the documentation in lilo-01.5 or higher.
An alternative method of storing a kernel on a boot disk is to create a filesystem, not as a root filesystem, but simply as a means of installing LILO and thus allowing boot-time command line options to be specified. For example, the same kernel could then be used to boot using a hard disk root filesystem, or a diskette root filesystem. This could be useful if you were trying to rebuild the hard disk filesystem, and wanted to repeatedly test results.
The kernel must somehow obtain a pointer to the drive and partititon to be mounted as the root drive. This can be provided in several ways:
ROOT_DEV = devicename
in the Linux kernel makefile
and rebuilding the kernel (for advice on how to rebuild the kernel,
read the Linux FAQ and look in /usr/src/linux
). Comments in the
Linux makefile describe the valid values for devicename
.
rdev filename devicename
This will set the root device of the kernel contained in filename
to be devicename
. For example:
rdev zImage /dev/sda1
This sets the root device in the kernel in zImage to the first partition on
the first SCSI drive.There are some alternative ways of issuing the rdev command. Try:
rdev -h
and it will display command usage.
There is usually no need to configure the root device for boot diskette use, because the kernel currently used to boot from probably already points to the root drive device. The need can arise, howoever, if you obtain a kernel from another machine, for example, from a distribution, or if you want to use the kernel to boot a root diskette. It is probably a good idea to check the current root drive setting, just in case it is wrong. To get rdev to check the current root device in a kernel file, enter the command:
rdev <filename>
It is possible to change the root device set in a kernel by means other than using rdev. For details, see the FAQ at the end of this document.
Once the kernel has been configured then it must be copied to the boot diskette.
The commands described below (and throughout the HOWTO) assume that the diskettes have been formatted. If not, then use fdformat to format the diskettes before continuing.
If the disk is not intended to contain a file system, then the kernel can be copied using the dd command, as follows:
dd if=infilename of=devicename
where infilename is the name of the kernel
and devicename is the diskette raw device,
usually /dev/fd0
The cp command can also be used:
cp filename devicename
For example:
dd if=zImage of=/dev/fd0
or
cp zImage /dev/fd0
The seek parameter to the dd command should NOT be used. The file must be copied to start at the boot sector (sector 0, cylinder 0), and omitting the seek parameter will do this.
The output device name to be used is usually /dev/fd0
for
the primary diskette drive (i.e. drive "A:" in DOS), and /dev/fd1
for the secondary. These device names will cause the kernel to
autodetect the attributes of the drives. Drive attributes can
be specified to the kernel by using other device names: for
example /dev/fd0H1440
specifies a high density 1.44 Mb
drive. It is rare to need to use these specific device names.
Where the kernel is to be copied to a boot disk containing a filesystem, then the disk is mounted at a suitable point in a currently-mounted filesystem, then the cp command is used. For example:
mount -t ext2 /dev/fd0 /mnt
cp zImage /mnt
umount /mnt
Note that for almost all operations in this HOWTO, the user should be operating as the superuser.
A root disk contains a complete working Linux system, but without necessarily including a kernel. In other words, the disk may not be bootable, but once the kernel is running, the root disk contains 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:
This is essentially the same as the root disk, with the addition of a kernel and a boot loader such as LILO.
With this configuration, a kernel file is copied to the root file system, and LILO is then run to install a configuration which points to the kernel file on the target disk. At boot time, LILO will boot the kernel from the target disk.
Several files must be copied to the diskette for this method to work. Details of these files and the required LILO configuration, including a working sample, are given below in the section titled "LILO".
For a diskette root filesystem to be efficient, you need to be able to run it from a ramdisk, i.e. an emulated disk drive in main memory. This avoids having the system run at a snail's pace, which a diskette would impose. The Ftape HOWTO states that a ramdisk will be required when using Ftape because Ftape requires exclusive use of the diskette controller.
There is an added benefit from using a ramdisk - the Linux kernel includes an automatic ramdisk root feature, whereby it will, under certain circumstances, automatically copy the contents of a root diskette to a ramdisk, and then switch the root drive to be the ramdisk instead of the diskette. This has three major benefits:
For kernels 1.3.48+, the ramdisk code was substantially rewritten. You have some more options and the commands for using the ramdisk are somewhat different. The section titled "Advanced Bootdisk Creation" discusses how to take advantage of these.
You must configure your kernel to have ramdisk support, but the
ramdisk is dynamically expandible so you need not specify the size.
rdev -r
is no longer used to specify the ramdisk size, but
instead sets a ramdisk word in the kernel image. The section titled
"Advanced Bootdisk Creation" discusses this in more detail.
If you have a kernel *before* 1.3.48, the following requirements apply. Note that this applies ONLY to kernels prior to 1.3.48.
A ramdisk can be configured into the kernel in several ways:
RAMDISK = -DRAMDISK=1440
to define a ramdisk of 1440 1K blocks, the size of a
high-density diskette.
rdev -r zImage 1440
this might change in the future, of course. To see what
your version of rdev does, enter the command:
rdev -h
and it should display its options.
ramdisk = 1440
to request a ramdisk of 1440 1K blocks at boot time.
zImage ramdisk=1440
See the section on LILO for more details.The easiest of these methods is LILO configuration, because you need to set up a LILO configuration file anyway, so why not add the ramdisk size here?
LILO configuration is briefly described in a section titled "LILO" below, but it is advisable to obtain the latest stable version of LILO from your nearest Linux mirror site, and read the documentation that comes with it.
Ramdisks can be made larger than the size of a diskette, and made to contain a filesystem as large as the ramdisk. This can be useful to load all the software required for rescue work onto a single high-performance ramdisk. The method of doing this is described in the FAQ section under the question "How can I create an oversize ramdisk filesystem?"
Often one disk is not sufficient to hold all the software you need to be able to perform rescue functions of analysing, repairing and restoring corrupted disk drives. By the time you include tar, gzip e2fsck, fdisk, Ftape and so on, there is enough for a whole new diskette, maybe even more if you want lots of tools.
This means that a rescue set often requires a utility diskette, with a file system containing any extra files required. This file system can then be mounted at a convenient point, such as /usr, on the boot/root system.
Creating a file system is fairly easy, and is described in the section titled "File Systems".