The Linux Bootdisk HOWTO

Tom Fawcett

Â Â Â Â Â Â Â Â <Bootdisk-HOWTO@linuxdoc.org>
Â Â Â Â Â Â Â Â
Copyright Â© 1995-2002 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.
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.
-------------------------------------------------------------------------------

Table of Contents

1. Preface

1.1. Version_notes

1.2. To_do_list

1.3. Feedback_and_credits

1.4. Distribution_policy

2. Introduction

3. Bootdisks_and_the_boot_process

3.1. The_boot_process

3.2. Disk_types

4. Building_a_root_filesystem

4.1. Overview

4.2. Creating_the_filesystem

4.3. Populating_the_filesystem

4.4. Providing_for_PAM_and_NSS

4.5. Modules

4.6. Some_final_details

4.7. Wrapping_it_up

5. Choosing_a_kernel

6. Putting_them_together:_Making_the_diskette(s)

6.1. Transferring_the_kernel_with_LILO

6.2. Transferring_the_kernel_without_LILO

6.3. Setting_the_ramdisk_word

6.4. Transferring_the_root_filesystem

7. Troubleshooting,_or_The_Agony_of_Defeat

8. Reducing_root_filesystem_size

8.1. Increase_the_diskette_density

8.2. Replace_common_utilities_with_BusyBox

8.3. Use_an_alternate_shell

8.4. Strip_libraries_and_binaries

8.5. Move_files_to_a_utility_disk

9. Miscellaneous_topics

9.1. Non-ramdisk_root_filesystems

9.2. Building_a_utility_disk

10. How_the_pros_do_it

11. Creating_bootable_CD-ROMs

11.1. What_is_El_Torito?

11.2. How_it_Works

11.3. How_to_make_it_work

11.4. Create_Win9x_Bootable_CD-Roms

12. Frequently_Asked_Question_(FAQ)_list

A. Resources_and_pointers

A.1. Pre-made_Bootdisks

A.2. Rescue_packages

A.3. LILO_--_the_Linux_loader

A.4. Ramdisk_usage

A.5. The_Linux_boot_process

B. LILO_boot_error_codes

C. Sample_root_filesystem_listings

D. Sample_utility_disk_directory_listing

1. Preface

Important This document may be outdated. If the date on the title page is
more than six months ago, please check the Bootdisk-HOWTO_homepage
to see if a more recent version exists.

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.
-------------------------------------------------------------------------------

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.
-------------------------------------------------------------------------------

2. Introduction

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:

* Use one from a distribution such as Slackware. This will at least allow you
to boot.
* Use a rescue package to set up disks designed to be used as rescue disks.
* Learn what is required for each of the types of disk to operate, then build
your own.

Some people choose the last option so they can do it themselves. That way, if
something breaks, they can work out what to do to fix it. Plus it's a great way
to learn about how a Linux system works.
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.
-------------------------------------------------------------------------------

3. Bootdisks and the boot process

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.
-------------------------------------------------------------------------------

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.

boot
A disk containing a kernel which can be booted. The disk can be used to
boot the kernel, which then may load a root file system on another disk.
The kernel on a bootdisk usually must be told where to find its root
filesystem.
Often a bootdisk loads a root filesystem from another diskette, but it is
possible for a bootdisk to be set up to load a hard disk's root
filesystem instead. This is commonly done when testing a new kernel (in
fact, ``make zdisk'' will create such a bootdisk automatically from the
kernel source code).

root
A disk with a filesystem containing files required to run a Linux system.
Such a disk does not necessarily contain either a kernel or a boot
loader.
A root disk can be used to run the system independently of any other
disks, once the kernel has been booted. Usually the root disk is
automatically copied to a ramdisk. This makes root disk accesses much
faster, and frees up the disk drive for a utility disk.

boot/root
A disk which contains both the kernel and a root filesystem. In other
words, it contains everything necessary to boot and run a Linux system
without a hard disk. 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 is increasingly difficult to
fit everything on a single diskette, even with compression.

utility
A disk which contains a filesystem, 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.

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. Building a root filesystem

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.
-------------------------------------------------------------------------------

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.

Important 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.

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

-------------------------------------------------------------------------------

4.3.2. /etc

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:

1. Required at all times, e.g. rc, fstab, passwd.
2. May be required, but no one is too sure.
3. Junk that crept in.

This lists files in reverse order of date last accessed, so if any files are
not being accessed, they can be omitted from a root diskette.
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:

1. The ones I must configure for a boot/root system:

a. rc.d/* -- system startup and run level change scripts
b. fstab -- list of file systems to be mounted
c. inittab -- parameters for the init process, the first process started
at boot time.
d. gettydefs -- parameters for the init process, the first process
started at boot time.

2. The ones I should tidy up for a boot/root system:

a. passwd -- Critical list of users, home directories, etc.
b. group -- user groups.
c. shadow -- passwords of users. You may not have this.
d. termcap -- the terminal capability database.

If security is important, passwd and shadow should be pruned to avoid
copying user passwords off the system, and so that unwanted logins are
rejected when you boot from diskette.
Be sure that passwd contains at least root. If you intend other users to
login, be sure their home directories and shells exist.
termcap, the terminal database, is typically several hundred kilobytes.
The version on your boot/root diskette should be pruned down to contain
only the terminal(s) you use, which is usually just the linux or linux-
console entry.
3. The rest. They work at the moment, so I leave them alone.

Out of this, I only really have to configure two files, and what they should
contain is surprisingly small.

* rc should contain:

#!/bin/sh
/bin/mount -av
/bin/hostname Kangaroo

Be sure it is executable, be sure it has a "#!" line at the top, and be sure
any absolute filenames are correct. You don't really need to run hostname â€”
it just looks nicer if you do.
* fstab should contain at least:

/dev/ram0 / ext2 defaults
/dev/fd0 / ext2 defaults
/proc /proc proc defaults

You can copy entries from your existing fstab, but you should not
automatically mount any of your hard disk partitions; use the noauto keyword
with them. Your hard disk may be damaged or dead when the bootdisk is used.

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:

id:2:initdefault:
si::sysinit:/etc/rc
1:2345:respawn:/sbin/getty 9600 tty1
2:23:respawn:/sbin/getty 9600 tty2

The inittab file defines what the system will run in various states including
startup, move to multi-user mode, etc. Check carefully the filenames mentioned
in inittab; if init cannot find the program mentioned the bootdisk will hang,
and you may not even get an error message.
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.
-------------------------------------------------------------------------------

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.

Important 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.3.4. /lib

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:
___________________________________________________________________________
| |
| % ls -l /lib/libc* |
| -rwxr-xr-x 1 root root 4016683 Apr 16 18:48 libc-2.1.1.so* |
| lrwxrwxrwx 1 root root 13 Apr 10 12:25 libc.so.6 -> libc-|
| 2.1.1.so* |
|___________________________________________________________________________|

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:
_______________________________________________________________
| |
| % ldd /sbin/mke2fs |
| libext2fs.so.2 => /lib/libext2fs.so.2 (0x40014000) |
| libcom_err.so.2 => /lib/libcom_err.so.2 (0x40026000) |
| libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) |
| libc.so.6 => /lib/libc.so.6 (0x4002c000) |
| /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)|
|_______________________________________________________________|

Each file on the right-hand side is required. The file may be a symbolic link.
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:
____________________________________________________________________________
| |
| % file /lib/libc.so.4.7.2 /lib/libc.so.5.4.33 /lib/libc-2.1.1.so |
| /lib/libc.so.4.7.2: Linux/i386 demand-paged executable (QMAGIC), stripped |
| /lib/libc.so.5.4.33: ELF 32-bit LSB shared object, Intel 80386, version 1,|
| stripped |
| /lib/libc-2.1.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1, |
| not stripped |
|____________________________________________________________________________|

The QMAGIC indicates that 4.7.2 is for A.OUT libraries, and ELF indicates that
5.4.33 and 2.1.1 are for ELF.
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.
-------------------------------------------------------------------------------

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.4.1. PAM (Pluggable Authentication Modules)

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:

OTHER auth optional /lib/security/pam_permit.so
OTHER account optional /lib/security/pam_permit.so
OTHER password optional /lib/security/pam_permit.so
OTHER session optional /lib/security/pam_permit.so

Also copy the file /lib/security/pam_permit.so to your root filesystem. This
library is only about 8K so it imposes minimal overhead.
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.
-------------------------------------------------------------------------------

4.4.2. NSS (Name Service Switch)

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:

passwd: files
shadow: files
group: files
hosts: files
services: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
automount: files
aliases: files
netgroup: files
publickey: files

This specifies that every service be provided only by local files. You will
also need to include /lib/libnss_files.so.X, where X is 1 for glibc 2.0 and 2
for glibc 2.1. This library will be loaded dynamically to handle the file
lookups.
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.
-------------------------------------------------------------------------------

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.

Important 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.
-------------------------------------------------------------------------------

5. Choosing a kernel

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''.
-------------------------------------------------------------------------------

6. Putting them together: Making the diskette(s)

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.
-------------------------------------------------------------------------------

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:
_________________________________________________________
|Bit_field|Description____________________________________|
|0-10_____|Offset_to_start_of_ramdisk,_in_1024_byte_blocks|
|11-13____|unused_________________________________________|
|14_______|Flag_indicating_that_ramdisk_is_to_be_loaded___|
|15_______|Flag_indicating_to_prompt_before_loading_rootfs|

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.

Important 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!

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

-------------------------------------------------------------------------------

7. Troubleshooting, or The Agony of Defeat

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:

* You may see a message like this:
_____________________________________________________
| |
| Kernel panic: VFS: Unable to mount root fs on XX:YY|
|_____________________________________________________|

This is a common problem and it has only a few causes. First, check the
device XX:YY against the list of device codes in /usr/src/linux/
Documentation/devices.txt. If it is incorrect, you probably didn't do an rdev
-R, or you did it on the wrong image. If the device code is correct, then
check carefully the device drivers compiled into your kernel. Make sure it
has floppy disk, ramdisk and ext2 filesystem support built-in.
* If you see many errors like:
_________________________________________________________
| |
| end_request: I/O error, dev 01:00 (ramdisk), sector NNN|
|_________________________________________________________|

This is an I/O error from the ramdisk driver, usually because the kernel is
trying to write beyond the end of the device. The ramdisk is too small to
hold the root filesystem. Check your bootdisk kernel's initialization
messages for a line like:
________________________________________________________________
| |
| Ramdisk driver initialized : 16 ramdisks of 4096K size|
|________________________________________________________________|

Check this size against the uncompressed size of the root filesystem. If the
ramdisks aren't large enough, make them larger.
* Check that the root disk actually contains the directories you think it does.
It is easy to copy at the wrong level so that you end up with something like
/rootdisk/bin instead of /bin on your root diskette.
* Check that there is a /lib/libc.so with the same link that appears in your /
lib directory on your hard disk.
* Check that any symbolic links in your /dev directory in your existing system
also exist on your root diskette filesystem, where those links are to devices
which you have included in your root diskette. In particular, /dev/console
links are essential in many cases.
* Check that you have included /dev/tty1, /dev/null, /dev/zero, /dev/mem, /dev/
ram and /dev/kmem files.
* Check your kernel configuration -- support for all resources required up to
login point must be built in, not modules. So ramdisk and ext2 support must
be built-in.
* Check that your kernel root device and ramdisk settings are correct.

Once these general aspects have been covered, here are some more specific files
to check:

1. Make sure init is included as /sbin/init or /bin/init. Make sure it is
executable.
2. Run ldd init to check init's libraries. Usually this is just libc.so, but
check anyway. Make sure you included the necessary libraries and loaders.
3. Make sure you have the right loader for your libraries -- ld.so for a.out
or ld-linux.so for ELF.
4. Check the /etc/inittab on your bootdisk filesystem for the calls to getty
(or some getty-like program, such as agetty, mgetty or getty_ps). Double-
check these against your hard disk inittab. Check the man pages of the
program you use to make sure these make sense. inittab is possibly the
trickiest part because its syntax and content depend on the init program
used and the nature of the system. The only way to tackle it is to read
the man pages for init and inittab and work out exactly what your existing
system is doing when it boots. Check to make sure /etc/inittab has a
system initialisation entry. This should contain a command to execute the
system initialization script, which must exist.
5. As with init, run ldd on your getty to see what it needs, and make sure
the necessary library files and loaders were included in your root
filesystem.
6. Be sure you have included a shell program (e.g., bash or ash) capable of
running all of your rc scripts.
7. If you have a /etc/ld.so.cache file on your rescue disk, remake it.

If init starts, but you get a message like:
______________________________________________________________
| |
| Id xxx respawning too fast: disabled for 5 minutes |
|______________________________________________________________|

it is coming from init, usually indicating that getty or login is dying as soon
as it starts up. Check the getty and login executables and the libraries they
depend upon. Make sure the invocations in /etc/inittab are correct. If you get
strange messages from getty, it may mean the calling form in /etc/inittab is
wrong.
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.
-------------------------------------------------------------------------------

8. Reducing root filesystem size

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.
-------------------------------------------------------------------------------

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|
|___________________________________|

Important 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. Miscellaneous topics

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).
-------------------------------------------------------------------------------

10. How the pros do it

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.
-------------------------------------------------------------------------------

11. Creating bootable CD-ROMs

Note This section was contributed by Rizwan Mohammed Darwe (rizwan AT
clovertechnologies dot com)

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.
-------------------------------------------------------------------------------

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.
-------------------------------------------------------------------------------

12. Frequently Asked Question (FAQ) list

Q: I_boot_from_my_boot/root_disks_and_nothing_happens._What_do_I_do?

Q: How_does_the_Slackware/Debian/RedHat_bootdisk_work?

Q: How_do_I_use_higher-density_(>_1440K)_diskettes?_How_do_I_figure_out_which
densities_will_work_with_my_diskette_drive?

Q: How_do_I_increase_the_size_of_my_ramdisks?

Q: How_do_I_make_bootable_CD-ROMs?

Q: How_do_I_make_bootable_LS-120_disks?

Q: How_can_I_make_a_boot_disk_with_a_XYZ_driver?

Q: How_do_I_update_my_root_diskette_with_new_files?

Q: How_do_I_remove_LILO_so_that_I_can_use_DOS_to_boot_again?

Q: How_can_I_boot_if_I've_lost_my_kernel_and_my_boot_disk?

Q: How_can_I_make_extra_copies_of_boot/root_diskettes?

Q: How_can_I_boot_without_typing_in_â€œahaxxxx=nn,nn,nnâ€_every_time?

Q: At_boot_time,_I_get_error_â€œA:_cannot_execute_Bâ€._Why?

Q: My_kernel_has_ramdisk_support,_but_initializes_ramdisks_of_0K._Why?

Q:I boot from my boot/root disks and nothing happens. What do I do?
A:See Section_7, above.
Q:How does the Slackware/Debian/RedHat bootdisk work?
A:See Section_10, above.
Q:How do I use higher-density (> 1440K) diskettes? How do I figure out which
densities will work with my diskette drive?
A:See Section Section_8, above, for the comments by Alain Knaff on this
subject. His is the most authoritative answer I know of.
Q:How do I increase the size of my ramdisks?
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.

1. Use the ramdisk_size=NNN command line parameter. You can either enter this
manually or use a command like append="ramdisk_size=NNN" with LILO.
2. If you're using LILO, you can use a kernel option like ramdisk=8192K in
the lilo.conf file.
3. Change the kernel configuration option CONFIG_BLK_DEV_RAM_SIZE and
recompile your kernel.

Q:How do I make bootable CD-ROMs?
A:See section Section_11.
Q:How do I make bootable LS-120 disks?
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:
_________________________________
| |
| boot=/dev/hda |
| compact |
| disk=/dev/hda bios=0 |
| install=/floppy/boot.b |
| map=/floppy/map |
| image=/floppy/linux |
| label=Linux |
| append="load_ramdisk=1"|
| initrd=/floppy/root.bin|
| ramdisk=8192 |
|_________________________________|

The line "disk=/dev/hda bios=0" is what does the trick to make it boot the LS-
120.
Q:How can I make a boot disk with a XYZ driver?
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''.
Q:How do I update my root diskette with new files?
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:
____________________________________________________________________________
| |
| dd if=/dev/fd0 bs=1k skip=ROOTBEGIN count=BLOCKS | gunzip > DEVICE|
| mount -t ext2 DEVICE /mnt |
|____________________________________________________________________________|

After making the changes, proceed as before (in Section_4.7) and transfer the
root filesystem back to the disk. You should not have to re-transfer the kernel
or re-compute the ramdisk word if you do not change the starting position of
the new root filesystem.
Q:How do I remove LILO so that I can use DOS to boot again?
A:This is not really a Bootdisk topic, but it is asked often. Within Linux, you
can run:
_______________________
| |
| /sbin/lilo -u|
|_______________________|

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:
____________________
| |
| FDISK /MBR|
|____________________|

MBR stands for Master Boot Record. This command replaces the boot sector with a
clean DOS one, without affecting the partition table. Some purists disagree
with this, but even the author of LILO, Werner Almesberger, suggests it. It is
easy, and it works.
Q:How can I boot if I've lost my kernel and my boot disk?
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:
___________________________________________________
| |
| HEX DEC DESCRIPTION |
| 0x01F8 504 Low byte of RAMDISK word |
| 0x01F9 505 High byte of RAMDISK word |
| 0x01FC 508 Root minor device number - see below|
| 0X01FD 509 Root major device number - see below|
|___________________________________________________|

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:
_____________________________________________________________
| |
| DEVICE MAJOR MINOR |
| /dev/fd0 2 0 1st floppy drive |
| /dev/hda1 3 1 partition 1 on 1st IDE drive |
| /dev/sda1 8 1 partition 1 on 1st SCSI drive|
| /dev/sda8 8 8 partition 8 on 1st SCSI drive|
|_____________________________________________________________|

Once you have set these values then you can write the file to a diskette using
either Norton Utilities Disk Editor, or a program called rawrite.exe. This
program is included in all distributions. It is a DOS program which writes a
file to the ``raw'' disk, starting at the boot sector, instead of writing it to
the file system. If you use Norton Utilities you must write the file to a
physical disk starting at the beginning of the disk.
Q:How can I make extra copies of boot/root diskettes?
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:
______________________________________
| |
| dd if=DEVICENAME of=FILENAME|
|______________________________________|

where DEVICENAME is the device name of the diskette drive and FILENAME is the
name of the (hard-disk) output file. Omitting the count parameter causes dd to
copy the whole diskette (2880 blocks if high-density).
To copy the resulting file back to a new diskette, insert the new diskette and
enter the reverse command:
______________________________________
| |
| dd if=FILENAME of=DEVICENAME|
|______________________________________|

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:
____________________________________
| |
| dd if=/dev/fd0 of=/dev/fd1|
|____________________________________|

Q:How can I boot without typing in â€œahaxxxx=nn,nn,nnâ€ every time?
A: Where a disk device cannot be autodetected it is necessary to supply the
kernel with a command device parameter string, such as:
______________________________
| |
| aha152x=0x340,11,3,1|
|______________________________|

This parameter string can be supplied in several ways using LILO:

* By entering it on the command line every time the system is booted via LILO.
This is boring, though.
* By using LILO's lock keyword to make it store the command line as the default
command line, so that LILO will use the same options every time it boots.
* By using the append= statement in the LILO config file. Note that the
parameter string must be enclosed in quotes.

For example, a sample command line using the above parameter string would be:
__________________________________________________________
| |
| zImage aha152x=0x340,11,3,1 root=/dev/sda1 lock|
|__________________________________________________________|

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:
_____________________________________________
| |
| APPEND = â€œaha152x=0x340,11,3,1â€|
|_____________________________________________|

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.
Q:At boot time, I get error â€œA: cannot execute Bâ€. Why?
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:

* shutdown in some versions has /etc/reboot hardcoded, so reboot must be placed
in the /etc directory.
* init has caused problems for at least one person, with the kernel being
unable to find init.

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.
Q:My kernel has ramdisk support, but initializes ramdisks of 0K. Why?
A:Where this occurs, a kernel message like this will appear as the kernel is
booting:
_____________________________________________________________
| |
| Ramdisk driver initialized : 16 ramdisks of 0K size|
|_____________________________________________________________|

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:
________________
| |
| ramdisk= 0|
|________________|

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.
-------------------------------------------------------------------------------

A. Resources and pointers

When retrieving a package, always get the latest version unless you have good
reasons for not doing so.
-------------------------------------------------------------------------------

A.1. Pre-made Bootdisks

These are sources for distribution bootdisks. Please use one of the mirror
sites to reduce the load on these machines.

* Slackware_bootdisks, rootdisks and Slackware_mirror_sites
* RedHat_bootdisks and Red_Hat_mirror_sites
* Debian_bootdisks and Debian_mirror_sites
* Mandrake_downloads

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

* RIP is a boot/rescue system which comes in several versions: one that fits on
a 1.44M floppy diskette and one that fits on a CD-ROM. It has large file
support and many utility programs for disk maintenance and rescue. It has
support for ext2, ext3, iso9660, msdos, ntfs, reiserfs, ufs and vfat. RIP is
available from http://www.tux.org/pub/people/kent-robotti/looplinux/rip/
index.html
* tomsrtbt, by Tom Oehser, is a single-disk boot/root disk based on kernel 2.0,
with a large set of features and support programs. It supports IDE, SCSI,
tape, network adaptors, PCMCIA and more. About 100 utility programs and tools
are included for fixing and restoring disks. The package also includes
scripts for disassembling and reconstructing the images so that new material
can be added if necessary.
* rescue02, by John Comyns, is a rescue disk based on kernel 1.3.84, with
support for IDE and Adaptec 1542 and NCR53C7,8xx. It uses ELF binaries but it
has enough commands so that it can be used on any system. There are modules
that can be loaded after booting for all other SCSI cards. It probably won't
work on systems with 4 mb of ram since it uses a 3 mb ram disk.
* resque_disk-2.0.22, by Sergei Viznyuk, is a full-featured boot/root disk
based on kernel 2.0.22 with built-in support for IDE, many difference SCSI
controllers, and ELF/AOUT. Also includes many modules and useful utilities
for repairing and restoring a hard disk.
* cramdisk_images, based on the 2.0.23 kernel, available for 4 meg and 8 meg
machines. They include math emulation and networking (PPP and dialin script,
NE2000, 3C509), or support for the parallel port ZIP drive. These diskette
images will boot on a 386 with 4MB RAM. MSDOS support is included so you can
download from the net to a DOS partition.

-------------------------------------------------------------------------------

A.2. Rescue packages

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.
-------------------------------------------------------------------------------

A.3. LILO -- the Linux loader

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.
-------------------------------------------------------------------------------

A.4. Ramdisk usage

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.
-------------------------------------------------------------------------------

A.5. The Linux boot process

For more detail on the Linux boot process, here are some pointers:

* The Linux_System_Administrators'_Guide has a section on booting.
* The LILO_``Technical_overview'' has the definitive technical, low-level
description of the boot process, up to where the kernel is started.
* The source code is the ultimate guide. Below are some kernel files related to
the boot process. If you have the Linux kernel source code, you can find
these under /usr/src/linux on your machine; alternatively, Shigio Yamaguchi
(shigio at tamacom.com) has a very nice hypertext_kernel_browser for reading
kernel source files. Here are some relevant files to look at:

arch/i386/boot/bootsect.S and setup.S
Contain assembly code for the bootsector itself.

arch/i386/boot/compressed/misc.c
Contains code for uncompressing the kernel.

arch/i386/kernel/
Directory containing kernel initialization code. setup.c defines the
ramdisk word.

drivers/block/rd.c
Contains the ramdisk driver. The procedures rd_load and rd_load_image
load blocks from a device into a ramdisk. The procedure
identify_ramdisk_image determines what kind of filesystem is found and
whether it is compressed.

-------------------------------------------------------------------------------

B. LILO boot error codes

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.
_____________________________________________________________________________
|Output___|Problem____________________________________________________________|
|(nothing)|No part of LILO has been loaded. LILO either isn't installed or the|
|_________|partition_on_which_its_boot_sector_is_located_isn't_active.________|
| |The first stage boot loader has been loaded and started, but it |
| |can't load the second stage boot loader. The two-digit error codes |
|L |indicate the type of problem. (See also section ``Disk error |
| |codes''.) This condition usually indicates a media failure or a |
|_________|geometry_mismatch_(e.g._bad_disk_parameters).______________________|
| |The first stage boot loader was able to load the second stage boot |
|LI |loader, but has failed to execute it. This can either be caused by |
| |a geometry mismatch or by moving /boot/boot.b without running the |
|_________|map_installer._____________________________________________________|
| |The second stage boot loader has been started, but it can't load |
|LIL |the descriptor table from the map file. This is typically caused by|
|_________|a_media_failure_or_by_a_geometry_mismatch._________________________|
| |The second stage boot loader has been loaded at an incorrect |
|LIL? |address. This is typically caused by a subtle geometry mismatch or |
|_________|by_moving_/boot/boot.b_without_running_the_map_installer.__________|
| |The descriptor table is corrupt. This can either be caused by a |
|LIL- |geometry mismatch or by moving /boot/map without running the map |
|_________|installer._________________________________________________________|
|LILO_____|All_parts_of_LILO_have_been_successfully_loaded.___________________|

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.
-------------------------------------------------------------------------------

C. Sample root filesystem listings

______________________________________________________________________________________
| |
| /: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 bin |
| drwxâ€“â€“xâ€“â€“x 2 root root 4096 Nov 1 15:39 dev |
| drwxâ€“â€“xâ€“â€“x 3 root root 1024 Nov 1 15:39 etc |
| drwxâ€“â€“xâ€“â€“x 4 root root 1024 Nov 1 15:39 lib |
| drwxâ€“â€“xâ€“â€“x 5 root root 1024 Nov 1 15:39 mnt |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 proc |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 root |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 sbin |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 tmp |
| drwxâ€“â€“xâ€“â€“x 7 root root 1024 Nov 1 15:39 usr |
| drwxâ€“â€“xâ€“â€“x 5 root root 1024 Nov 1 15:39 var |
| |
| /bin: |
| -rwxâ€“â€“xâ€“â€“x 1 root root 62660 Nov 1 15:39 ash |
| -rwxâ€“â€“xâ€“â€“x 1 root root 9032 Nov 1 15:39 cat |
| -rwxâ€“â€“xâ€“â€“x 1 root root 10276 Nov 1 15:39 chmod |
| -rwxâ€“â€“xâ€“â€“x 1 root root 9592 Nov 1 15:39 chown |
| -rwxâ€“â€“xâ€“â€“x 1 root root 23124 Nov 1 15:39 cp |
| -rwxâ€“â€“xâ€“â€“x 1 root root 23028 Nov 1 15:39 date |
| -rwxâ€“â€“xâ€“â€“x 1 root root 14052 Nov 1 15:39 dd |
| -rwxâ€“â€“xâ€“â€“x 1 root root 14144 Nov 1 15:39 df |
| -rwxâ€“â€“xâ€“â€“x 1 root root 69444 Nov 1 15:39 egrep |
| -rwxâ€“â€“xâ€“â€“x 1 root root 395 Nov 1 15:39 false |
| -rwxâ€“â€“xâ€“â€“x 1 root root 69444 Nov 1 15:39 fgrep |
| -rwxâ€“â€“xâ€“â€“x 1 root root 69444 Nov 1 15:39 grep |
| -rwxâ€“â€“xâ€“â€“x 3 root root 45436 Nov 1 15:39 gunzip |
| -rwxâ€“â€“xâ€“â€“x 3 root root 45436 Nov 1 15:39 gzip |
| -rwxâ€“â€“xâ€“â€“x 1 root root 8008 Nov 1 15:39 hostname |
| -rwxâ€“â€“xâ€“â€“x 1 root root 12736 Nov 1 15:39 ln |
| -rwsâ€“â€“xâ€“â€“x 1 root root 15284 Nov 1 15:39 login |
| -rwxâ€“â€“xâ€“â€“x 1 root root 29308 Nov 1 15:39 ls |
| -rwxâ€“â€“xâ€“â€“x 1 root root 8268 Nov 1 15:39 mkdir |
| -rwxâ€“â€“xâ€“â€“x 1 root root 8920 Nov 1 15:39 mknod |
| -rwxâ€“â€“xâ€“â€“x 1 root root 24836 Nov 1 15:39 more |
| -rwsâ€“â€“xâ€“â€“x 1 root root 37640 Nov 1 15:39 mount |
| -rwxâ€“â€“xâ€“â€“x 1 root root 12240 Nov 1 15:39 mt |
| -rwxâ€“â€“xâ€“â€“x 1 root root 12932 Nov 1 15:39 mv |
| -r-xâ€“â€“xâ€“â€“x 1 root root 12324 Nov 1 15:39 ps |
| -rwxâ€“â€“xâ€“â€“x 1 root root 5388 Nov 1 15:39 pwd |
| -rwxâ€“â€“xâ€“â€“x 1 root root 10092 Nov 1 15:39 rm |
| lrwxrwxrwx 1 root root 3 Nov 1 15:39 sh -> ash |
| -rwxâ€“â€“xâ€“â€“x 1 root root 25296 Nov 1 15:39 stty |
| -rwsâ€“â€“xâ€“â€“x 1 root root 12648 Nov 1 15:39 su |
| -rwxâ€“â€“xâ€“â€“x 1 root root 4444 Nov 1 15:39 sync |
| -rwxâ€“â€“xâ€“â€“x 1 root root 19712 Nov 1 15:39 touch |
| -rwxâ€“â€“xâ€“â€“x 1 root root 395 Nov 1 15:39 true |
| -rwsâ€“â€“xâ€“â€“x 1 root root 19084 Nov 1 15:39 umount |
| -rwxâ€“â€“xâ€“â€“x 1 root root 5368 Nov 1 15:39 uname |
| -rwxâ€“â€“xâ€“â€“x 3 root root 45436 Nov 1 15:39 zcat |
| |
| /dev: |
| lrwxrwxrwx 1 root root 6 Nov 1 15:39 cdrom -> cdu31a |
| brwâ€“rwâ€“râ€“â€“ 1 root root 15, 0 May 5 1998 cdu31a |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 0 Nov 1 15:29 console |
| crwâ€“rwâ€“rwâ€“ 1 root uucp 5, 64 Sep 9 19:46 cua0 |
| crwâ€“rwâ€“rwâ€“ 1 root uucp 5, 65 May 5 1998 cua1 |
| crwâ€“rwâ€“rwâ€“ 1 root uucp 5, 66 May 5 1998 cua2 |
| crwâ€“rwâ€“rwâ€“ 1 root uucp 5, 67 May 5 1998 cua3 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 0 Aug 8 13:54 fd0 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 36 Aug 8 13:54 fd0CompaQ |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 84 Aug 8 13:55 fd0D1040 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 88 Aug 8 13:55 fd0D1120 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 12 Aug 8 13:54 fd0D360 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 16 Aug 8 13:54 fd0D720 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 120 Aug 8 13:55 fd0D800 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 32 Aug 8 13:54 fd0E2880 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 104 Aug 8 13:55 fd0E3200 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 108 Aug 8 13:55 fd0E3520 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 112 Aug 8 13:55 fd0E3840 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 28 Aug 8 13:54 fd0H1440 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 124 Aug 8 13:55 fd0H1600 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 44 Aug 8 13:55 fd0H1680 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 60 Aug 8 13:55 fd0H1722 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 76 Aug 8 13:55 fd0H1743 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 96 Aug 8 13:55 fd0H1760 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 116 Aug 8 13:55 fd0H1840 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 100 Aug 8 13:55 fd0H1920 |
| lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H360 â€“> fd0D360 |
| lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H720 â€“> fd0D720 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 52 Aug 8 13:55 fd0H820 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 68 Aug 8 13:55 fd0H830 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 4 Aug 8 13:54 fd0d360 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 8 Aug 8 13:54 fd0h1200 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 40 Aug 8 13:54 fd0h1440 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 56 Aug 8 13:55 fd0h1476 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 72 Aug 8 13:55 fd0h1494 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 92 Aug 8 13:55 fd0h1600 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 20 Aug 8 13:54 fd0h360 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 48 Aug 8 13:55 fd0h410 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 64 Aug 8 13:55 fd0h420 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 24 Aug 8 13:54 fd0h720 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root floppy 2, 80 Aug 8 13:55 fd0h880 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 0 May 5 1998 hda |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 1 May 5 1998 hda1 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 2 May 5 1998 hda2 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 3 May 5 1998 hda3 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 4 May 5 1998 hda4 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 5 May 5 1998 hda5 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 6 May 5 1998 hda6 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 64 May 5 1998 hdb |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 65 May 5 1998 hdb1 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 66 May 5 1998 hdb2 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 67 May 5 1998 hdb3 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 68 May 5 1998 hdb4 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 69 May 5 1998 hdb5 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 3, 70 May 5 1998 hdb6 |
| crwâ€“râ€“â€“â€“â€“â€“ 1 root kmem 1, 2 May 5 1998 kmem |
| crwâ€“râ€“â€“â€“â€“â€“ 1 root kmem 1, 1 May 5 1998 mem |
| lrwxrwxrwx 1 root root 12 Nov 1 15:39 modem â€“> ttyS1 |
| lrwxrwxrwx 1 root root 12 Nov 1 15:39 mouse â€“> psaux |
| crwâ€“rwâ€“rwâ€“ 1 root root 1, 3 May 5 1998 null |
| crwxrwxrwx 1 root root 10, 1 Oct 5 20:22 psaux |
| brwâ€“râ€“â€“â€“â€“â€“ 1 root disk 1, 1 May 5 1998 ram |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 0 May 5 1998 ram0 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 1 May 5 1998 ram1 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 2 May 5 1998 ram2 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 3 May 5 1998 ram3 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 4 May 5 1998 ram4 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 5 May 5 1998 ram5 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 6 May 5 1998 ram6 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 7 May 5 1998 ram7 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 8 May 5 1998 ram8 |
| brwâ€“rwâ€“â€“â€“â€“ 1 root disk 1, 9 May 5 1998 ram9 |
| lrwxrwxrwx 1 root root 4 Nov 1 15:39 ramdisk â€“> ram0 |
| *** I have only included devices for the IDE partitions I use. |
| *** If you use SCSI, then use the /dev/sdXX devices instead. |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 0 May 5 1998 tty0 |
| crwâ€“wâ€“â€“â€“â€“â€“ 1 root tty 4, 1 Nov 1 15:39 tty1 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 2 Nov 1 15:29 tty2 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 3 Nov 1 15:29 tty3 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 4 Nov 1 15:29 tty4 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 5 Nov 1 15:29 tty5 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 6 Nov 1 15:29 tty6 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4, 7 May 5 1998 tty7 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root tty 4, 8 May 5 1998 tty8 |
| crwâ€“â€“â€“â€“â€“â€“â€“ 1 root tty 4, 9 May 8 12:57 tty9 |
| crwâ€“rwâ€“rwâ€“ 1 root root 4, 65 Nov 1 12:17 ttyS1 |
| crwâ€“rwâ€“rwâ€“ 1 root root 1, 5 May 5 1998 zero |
| |
| /etc: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 164 Nov 1 15:39 conf.modules |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 668 Nov 1 15:39 fstab |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 71 Nov 1 15:39 gettydefs |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 389 Nov 1 15:39 group |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 413 Nov 1 15:39 inittab |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 65 Nov 1 15:39 issue |
| â€“rwâ€“râ€“â€“râ€“â€“ 1 root root 746 Nov 1 15:39 ld.so.cache |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 32 Nov 1 15:39 motd |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 949 Nov 1 15:39 nsswitch.conf|
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 pam.d |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 139 Nov 1 15:39 passwd |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 516 Nov 1 15:39 profile |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 387 Nov 1 15:39 rc |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 55 Nov 1 15:39 shells |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 774 Nov 1 15:39 termcap |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 78 Nov 1 15:39 ttytype |
| lrwxrwxrwx 1 root root 15 Nov 1 15:39 utmp â€“> ../var/run/utmp |
| lrwxrwxrwx 1 root root 15 Nov 1 15:39 wtmp â€“> ../var/log/wtmp |
| |
| /etc/pam.d: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 356 Nov 1 15:39 other |
| |
| /lib: |
| â€“rwxrâ€“xrâ€“x 1 root root 45415 Nov 1 15:39 ldâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 11 Nov 1 15:39 ldâ€“linux.so.2 â€“> ldâ€“2.0|7.so
| â€“rwxrâ€“xrâ€“x 1 root root 731548 Nov 1 15:39 libcâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 13 Nov 1 15:39 libc.so.6 â€“> libcâ€“2.0.7.s|
| lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcom_err.so.2 â€“> |
| libcom_err.so.2.0 |
| â€“rwxrâ€“xrâ€“x 1 root root 6209 Nov 1 15:39 libcom_err.so.2.0 |
| â€“rwxrâ€“xrâ€“x 1 root root 153881 Nov 1 15:39 libcryptâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcrypt.so.1 â€“> |
| libcryptâ€“2.0.7.so |
| â€“rwxrâ€“xrâ€“x 1 root root 12962 Nov 1 15:39 libdlâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 14 Nov 1 15:39 libdl.so.2 â€“> libdlâ€“2.0.7|so
| lrwxrwxrwx 1 root root 16 Nov 1 15:39 libext2fs.so.2 â€“> |
| libext2fs.so.2.4 |
| â€“rwxrâ€“xrâ€“x 1 root root 81382 Nov 1 15:39 libext2fs.so.2.4 |
| â€“rwxrâ€“xrâ€“x 1 root root 25222 Nov 1 15:39 libnslâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 15 Nov 1 15:39 libnsl.so.1 â€“> |
| libnslâ€“2.0.7.so |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 178336 Nov 1 15:39 libnss_filesâ€“2.0.|.so
| lrwxrwxrwx 1 root root 21 Nov 1 15:39 libnss_files.so.1 â€“> |
| libnss_filesâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 14 Nov 1 15:39 libpam.so.0 â€“> libpam.so.0.|4
| â€“rwxrâ€“xrâ€“x 1 root root 26906 Nov 1 15:39 libpam.so.0.64 |
| lrwxrwxrwx 1 root root 19 Nov 1 15:39 libpam_misc.so.0 â€“> |
| libpam_misc.so.0.64 |
| â€“rwxrâ€“xrâ€“x 1 root root 7086 Nov 1 15:39 libpam_misc.so.0.64 |
| â€“râ€“xrâ€“xrâ€“x 1 root root 35615 Nov 1 15:39 libproc.so.1.2.6 |
| lrwxrwxrwx 1 root root 15 Nov 1 15:39 libpwdb.so.0 â€“> |
| libpwdb.so.0.54 |
| â€“rwâ€“râ€“râ€“â€“â€“ 1 root root 121899 Nov 1 15:39 libpwdb.so.0.54 |
| lrwxrwxrwx 1 root root 19 Nov 1 15:39 libtermcap.so.2 â€“> |
| libtermcap.so.2.0.8 |
| â€“rwxrâ€“xrâ€“x 1 root root 12041 Nov 1 15:39 libtermcap.so.2.0.8 |
| â€“rwxrâ€“xrâ€“x 1 root root 12874 Nov 1 15:39 libutilâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 16 Nov 1 15:39 libutil.so.1 â€“> |
| libutilâ€“2.0.7.so |
| lrwxrwxrwx 1 root root 14 Nov 1 15:39 libuuid.so.1 â€“> |
| libuuid.so.1.1 |
| â€“rwxrâ€“xrâ€“x 1 root root 8039 Nov 1 15:39 libuuid.so.1.1 |
| drwxâ€“â€“xâ€“â€“x 3 root root 1024 Nov 1 15:39 modules |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 security |
| |
| /lib/modules: |
| drwxâ€“â€“xâ€“â€“x 4 root root 1024 Nov 1 15:39 2.0.35 |
| |
| /lib/modules/2.0.35: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 block |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 cdrom |
| |
| /lib/modules/2.0.35/block: |
| drwxâ€“â€“â€“â€“â€“â€“ 1 root root 7156 Nov 1 15:39 loop.o |
| |
| /lib/modules/2.0.35/cdrom: |
| drwxâ€“â€“â€“â€“â€“â€“ 1 root root 24108 Nov 1 15:39 cdu31a.o |
| |
| /lib/security: |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 8771 Nov 1 15:39 pam_permit.so |
| |
| *** Directory stubs for mounting |
| /mnt: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 cdrom |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 floppy |
| |
| /proc: |
| |
| /root: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 176 Nov 1 15:39 .bashrc |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 182 Nov 1 15:39 .cshrc |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 455 Nov 1 15:39 .profile |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 4014 Nov 1 15:39 .tcshrc |
| |
| /sbin: |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 23976 Nov 1 15:39 depmod |
| â€“rwxâ€“â€“xâ€“â€“x 2 root root 274600 Nov 1 15:39 e2fsck |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 41268 Nov 1 15:39 fdisk |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 9396 Nov 1 15:39 fsck |
| â€“rwxâ€“â€“xâ€“â€“x 2 root root 274600 Nov 1 15:39 fsck.ext2 |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 29556 Nov 1 15:39 getty |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 6620 Nov 1 15:39 halt |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 23116 Nov 1 15:39 init |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 25612 Nov 1 15:39 insmod |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 10368 Nov 1 15:39 kerneld |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 110400 Nov 1 15:39 ldconfig |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 6108 Nov 1 15:39 lsmod |
| â€“rwxâ€“â€“xâ€“â€“x 2 root root 17400 Nov 1 15:39 mke2fs |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 4072 Nov 1 15:39 mkfs |
| â€“rwxâ€“â€“xâ€“â€“x 2 root root 17400 Nov 1 15:39 mkfs.ext2 |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 5664 Nov 1 15:39 mkswap |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 22032 Nov 1 15:39 modprobe |
| lrwxrwxrwx 1 root root 4 Nov 1 15:39 reboot â€“> halt |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 7492 Nov 1 15:39 rmmod |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 12932 Nov 1 15:39 shutdown |
| lrwxrwxrwx 1 root root 6 Nov 1 15:39 swapoff â€“> swapon |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 5124 Nov 1 15:39 swapon |
| lrwxrwxrwx 1 root root 4 Nov 1 15:39 telinit â€“> init |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 6944 Nov 1 15:39 update |
| |
| /tmp: |
| |
| /usr: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 bin |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 lib |
| drwxâ€“â€“xâ€“â€“x 3 root root 1024 Nov 1 15:39 man |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 sbin |
| drwxâ€“â€“xâ€“â€“x 3 root root 1024 Nov 1 15:39 share |
| lrwxrwxrwx 1 root root 10 Nov 1 15:39 tmp â€“> ../var/tmp |
| |
| /usr/bin: |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 37164 Nov 1 15:39 afio |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 5044 Nov 1 15:39 chroot |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 10656 Nov 1 15:39 cut |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 63652 Nov 1 15:39 diff |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 12972 Nov 1 15:39 du |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 56552 Nov 1 15:39 find |
| â€“râ€“xâ€“â€“xâ€“â€“x 1 root root 6280 Nov 1 15:39 free |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 7680 Nov 1 15:39 head |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 8504 Nov 1 15:39 id |
| â€“râ€“srâ€“xrâ€“x 1 root bin 4200 Nov 1 15:39 passwd |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 14856 Nov 1 15:39 tail |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 19008 Nov 1 15:39 tr |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 7160 Nov 1 15:39 wc |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 4412 Nov 1 15:39 whoami |
| |
| /usr/lib: |
| lrwxrwxrwx 1 root root 17 Nov 1 15:39 libncurses.so.4 â€“> |
| libncurses.so.4.2 |
| â€“rwâ€“râ€“râ€“â€“â€“ 1 root root 260474 Nov 1 15:39 libncurses.so.4.2|
| |
| /usr/sbin: |
| â€“râ€“xâ€“â€“xâ€“â€“x 1 root root 13684 Nov 1 15:39 fuser |
| â€“rwxâ€“â€“xâ€“â€“x 1 root root 3876 Nov 1 15:39 mklost+found |
| |
| /usr/share: |
| drwxâ€“â€“xâ€“â€“x 4 root root 1024 Nov 1 15:39 terminfo |
| |
| /usr/share/terminfo: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 l |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 v |
| |
| /usr/share/terminfo/l: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 1552 Nov 1 15:39 linux |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 1516 Nov 1 15:39 linuxâ€“m |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 1583 Nov 1 15:39 linuxâ€“nic |
| |
| /usr/share/terminfo/v: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 2 root root 1143 Nov 1 15:39 vt100 |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 2 root root 1143 Nov 1 15:39 vt100â€“am |
| |
| /var: |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 log |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 run |
| drwxâ€“â€“xâ€“â€“x 2 root root 1024 Nov 1 15:39 tmp |
| |
| /var/log: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 0 Nov 1 15:39 wtmp |
| |
| /var/run: |
| â€“rwâ€“â€“â€“â€“â€“â€“â€“ 1 root root 0 Nov 1 15:39 utmp |
| |
| /var/tmp: |
|______________________________________________________________________________________|

-------------------------------------------------------------------------------

D. Sample utility disk directory listing

____________________________________________________________________________
| |
| total 579 |
| â€“rwxrâ€“xrâ€“x 1 root root 42333 Jul 28 19:05 cpio |
| â€“rwxrâ€“xrâ€“x 1 root root 32844 Aug 28 19:50 debugfs |
| â€“rwxrâ€“xrâ€“x 1 root root 103560 Jul 29 21:31 elvis |
| â€“rwxrâ€“xrâ€“x 1 root root 29536 Jul 28 19:04 fdisk |
| â€“rwâ€“râ€“râ€“â€“â€“ 1 root root 128254 Jul 28 19:03 ftape.o|
| â€“rwxrâ€“xrâ€“x 1 root root 17564 Jul 25 03:21 ftmt |
| â€“rwxrâ€“xrâ€“x 1 root root 64161 Jul 29 20:47 grep |
| â€“rwxrâ€“xrâ€“x 1 root root 45309 Jul 29 20:48 gzip |
| â€“rwxrâ€“xrâ€“x 1 root root 23560 Jul 28 19:04 insmod |
| â€“rwxrâ€“xrâ€“x 1 root root 118 Jul 28 19:04 lsmod |
| lrwxrwxrwx 1 root root 5 Jul 28 19:04 mt â€“> mtâ€“st |
| â€“rwxrâ€“xrâ€“x 1 root root 9573 Jul 28 19:03 mtâ€“st |
| lrwxrwxrwx 1 root root 6 Jul 28 19:05 rmmod â€“> insmod |
| â€“rwxrâ€“xrâ€“x 1 root root 104085 Jul 28 19:05 tar |
| lrwxrwxrwx 1 root root 5 Jul 29 21:35 vi â€“> elvis |
|____________________________________________________________________________|

Notes

[1] The directory structure presented here is for root diskette use only. Real
Linux systems have a more complex and disciplined set of policies, called
the Filesystem_Hierarchy_Standard, for determining where files should go.)