The Linux Bootdisk HOWTO
Tom Fawcett
fawcett+BH@croftj.net
Copyright � 1995,1996,1997,1998,1999,2000 by Tom Fawcett and Graham
Chapman.
v4.0, April 2000
This document describes how to design and build your own 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 your own
bootdisk. If you just want a rescue disk to have for emergencies, see
[1]Appendix A.1.
_________________________________________________________________
Table of Contents
[2]Preface
[3]Version notes
[4]Yet to do
[5]Feedback and credits
[6]Distribution policy
[7]Introduction
[8]Bootdisks and the boot process
[9]The boot process
[10]Disk types
[11]Building a root filesystem
[12]Overview
[13]Creating the filesystem
[14]Populating the filesystem
[15]Providing for PAM and NSS
[16]Modules
[17]Some final details
[18]Wrapping it up
[19]Choosing a kernel
[20]Putting them together: Making the diskette(s)
[21]Transferring the kernel with LILO
[22]Transferring the kernel without LILO
[23]Setting the ramdisk word
[24]Transferring the root filesystem
[25]Troubleshooting, or The Agony of Defeat
[26]Miscellaneous topics
[27]Reducing root filesystem size
[28]Non-ramdisk root filesystems
[29]Building a utility disk
[30]How the pros do it
[31]Frequently Asked Question (FAQ) list
Appendix A. [32]Resources and pointers
[33]Pre-made Bootdisks
[34]Rescue packages
[35]LILO -- the Linux loader
[36]Linux FAQ and HOWTOs
[37]Ramdisk usage
[38]The Linux boot process
Appendix B. [39]LILO boot error codes
Appendix C. [40]Sample root filesystem listings
Appendix D. [41]Sample utility disk directory listing
Preface
Important: This document may be outdated. If the date on the title
page is more than six months ago, please check the
[42]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.
_________________________________________________________________
Version notes
Graham Chapman wrote the original Bootdisk-HOWTO and he supported it
through version 3.1. Tom Fawcett started as co-author around the time
kernel v2 was introduced. He is the document's current maintainer.
This information is intended for Linux on the Intel platform. Much of
this information may be applicable to Linux on other processors, but
we have no first-hand experience or information about this. If you
have experience with bootdisks on other platforms, please contact us.
_________________________________________________________________
Yet to do
Any volunteers?
1. Describe (or link to another document that describes) how to
create other bootable disk-like things, such as CDROMs, ZIP disks
and LS110 disks.
2. Describe how to deal with the huge libc.so shared libraries. The
options are basically to get older, smaller libraries or to cut
down existing libraries.
3. Re-analyze distribution bootdisks and update the "How the Pros do
it" section.
4. Delete section that describes how to upgrade existing distribution
bootdisks. This is usually more trouble than it's worth.
5. Rewrite/streamline the Troubleshooting section.
_________________________________________________________________
Feedback and credits
I welcome any feedback, good or bad, on the content of this document.
I/we have done our best to ensure that the instructions and
information herein are accurate and reliable. Please let me know if
you find errors or omissions. When writing, please indicate the
version number of the document you're referencing.
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, corrections and questions to the author at the email
address above. I don't mind trying to answer questions, but if you
have a specific question about why your bootdisk doesn't work, please
read [43]the section called Troubleshooting, or The Agony of Defeat
first.
_________________________________________________________________
Distribution policy
Copyright � 1995,1996,1997,1998,1999,2000 by Tom Fawcett and Graham
Chapman. This document may be distributed under the terms set forth in
the [44]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.
_________________________________________________________________
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 your own 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 [45]Appendix A.1, below, for where to find these.
_________________________________________________________________
Bootdisks and the boot process
A bootdisk is basically a miniature, self-contained Linux system on a
floppy 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. We present the
basics here, which are sufficient for understanding the rest of this
document. Many details and alternative options have been omitted.
_________________________________________________________________
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.
* 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.
Once the kernel is completely loaded, it goes through some basic
device initialization. It then tries to load and mount a root
filesystem from some device. A root filesystem is simply a filesystem
that is 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. There are two reasons why the system
loads to ramdisk. First, RAM is several orders of magnitude faster
than a floppy disk, so system operation is fast; and second, 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.
At this point the system finds the init program on the root filesystem
(in /bin or /sbin) and executes it. 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 all the disks,
* Loading necessary kernel modules,
* Starting swapping,
* Initializing the network,
* Mounting disks mentioned in 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.
_________________________________________________________________
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.
_________________________________________________________________
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 [46]the section called
Non-ramdisk root filesystems.
_________________________________________________________________
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 will 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.
_________________________________________________________________
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 [47]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. For example:
mount -o loop -t ext2 /tmp/fsfile /mnt
will mount /tmp/fsfile via a loopback device at the mount point
/mnt. A df will confirm this.
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 fact in mind
whenever you delete files from your root 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 -i option to specify more inodes
than the default; -i 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 the /dev
directory then 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 -i 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.
_________________________________________________________________
Populating the filesystem
Here is a reasonable minimum set of directories for your root
filesystem [48][1]:
* /dev -- Devices, 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.
_________________________________________________________________
/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 your existing /dev directory
contents, and delete the ones you don't want. 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. The command is:
cp -dpR /dev /mnt
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 are copied, it is worth checking 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. It therefore makes sense to remove any device special
files that you don't need from the diskette /dev directory. For
example, if you do not have SCSI disks you can safely remove all the
device files starting with sd. Similarly, if you don't intend to use
your serial port then all device files starting with cua can go.
Important: Be sure to include the following files from this
directory: console, kmem, mem, null, ram0 and tty1.
_________________________________________________________________
/etc
This directory contains important configuration files. 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.
Files which are not essential can usually be identified with the
command:
ls -ltru
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.
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 the directories are right. 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
[49]Appendix 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.
_________________________________________________________________
/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
[50]Appendix 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 [51]the section
called Building a utility disk. 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.
_________________________________________________________________
/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 [52]the section called Reducing root
filesystem size 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, stri
pped
/lib/libc-2.1.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not s
tripped
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.
_________________________________________________________________
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.
_________________________________________________________________
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.
_________________________________________________________________
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.
_________________________________________________________________
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.
_________________________________________________________________
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. To remake ld.so.cache,
issue the following commands:
chdir /mnt; chroot /mnt /sbin/ldconfig
The chroot is necessary because ldconfig always remakes the cache for
the root filesystem.
_________________________________________________________________
Wrapping it up
Once 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 [53]the section called Reducing root filesystem size.
_________________________________________________________________
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''.
_________________________________________________________________
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 [54]the section called Transferring
the kernel without LILO.
_________________________________________________________________
Transferring the kernel with LILO
The first thing you must do is 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 -l KERNEL'' divided by
1024 and rounded up) 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 -i 8192 -m 0 /dev/fd0 KERNEL_BLOCKS
The ``-i 8192'' specifies that we want one inode per 8192 bytes. Next,
mount the filesystem, remove the lost+found directory, and create dev
and boot directories for LILO:
mount /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 [55]the section called
Setting the ramdisk word.
_________________________________________________________________
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.
_________________________________________________________________
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.
_________________________________________________________________
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.
_________________________________________________________________
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. To get a system to boot to the
stage where it will talk to you requires several components to be
present and correctly configured. 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; is it the
correct root device? If not, 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 being reported by the ramdisk driver,
probably because the kernel is trying to write beyond the end of
the device. Your ramdisk is too small to hold your 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 [56]the section called Providing for PAM and
NSS. 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.
_________________________________________________________________
Miscellaneous topics
Reducing root filesystem size
Sometimes a root filesystem is too large to fit on a diskette even
after compression. Here are some ways to reduce the filesystem size:
1. Increase the diskette density. By default, floppy diskettes are
formatted at 1440K, but higher density formats are available.
fdformat will format disks for the following sizes: 1600, 1680,
1722, 1743, 1760, 1840, and 1920. Most 1440K drives will support
1722K, and this is what I always use for bootdisks. See the
fdformat man page and /usr/src/linux/Documentation/devices.txt.
2. Replace your shell. Some of the popular shells for Linux, such as
bash and tcsh, are large and require many libraries. Light-weight
alternatives exist, such as ash, lsh, kiss and smash, which are
much smaller and require few (or no) libraries. Most of these
replacement shells are available from
[57]http://metalab.unc.edu/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.
3. 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.
4. If you deleted or moved files much when you were creating the root
filesystem, create it again. See the NOTE ABOVE on the importance
of not having dirty blocks in the filesystem.
5. Move non-critical 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 [58]the section called Building a
utility disk for details. You may also consider moving modules to
a utility disk as well.
_________________________________________________________________
Non-ramdisk root filesystems
[59]the section called Building a root filesystem 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.
_________________________________________________________________
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.
[60]Appendix 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).
_________________________________________________________________
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
[61]/usr/src/linux/Documentation/initrd.txt and
[62]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 [63]the section called Transferring the kernel with LILO.
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.
_________________________________________________________________
Frequently Asked Question (FAQ) list
Q: [64]I boot from my boot/root disks and nothing happens. What do I
do?
Q: [65]How does the Slackware/Debian/RedHat bootdisk work?
Q: [66]How can I make a boot disk with a XYZ driver?
Q: [67]How do I update my root diskette with new files?
Q: [68]How do I remove LILO so that I can use DOS to boot again?
Q: [69]How can I boot if I've lost my kernel and my boot disk?
Q: [70]How can I make extra copies of boot/root diskettes?
Q: [71]How can I boot without typing in "ahaxxxx=nn,nn,nn" every time?
Q: [72]At boot time, I get error "A: cannot execute B". Why?
Q: [73]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 [74]the section called Troubleshooting, or The Agony of Defeat,
above.
Q: How does the Slackware/Debian/RedHat bootdisk work?
A: See [75]the section called How the pros do it, above.
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 [76]the section called Creating the
filesystem, 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 [77]the section called
Wrapping it up) 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 [78]the
section called Setting the ramdisk word, 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.
_________________________________________________________________
Appendix A. Resources and pointers
When retrieving a package, always get the latest version unless you
have good reasons for not doing so.
_________________________________________________________________
Pre-made Bootdisks
These are sources for distribution bootdisks. Please use one of the
mirror sites to reduce the load on these machines.
* [79]Slackware bootdisks, [80]rootdisks and [81]Slackware mirror
sites
* [82]RedHat bootdisks and [83]Red Hat mirror sites
* [84]Debian bootdisks and [85]Debian mirror sites
In addition to the distribution bootdisks, the following rescue disk
images are available. Unless otherwise specified, these are available
in the directory
[86]http://metalab.unc.edu/pub/Linux/system/recovery/!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.
* [87]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.
_________________________________________________________________
Rescue packages
Several packages for creating rescue disks are available on
metalab.unc.edu. With these packages you specify a set of files for
inclusion and the software automates (to varying degrees) the creation
of a bootdisk. See
[88]http://metalab.unc.edu/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, [89]Yard is the only package that will.
_________________________________________________________________
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 [90]ftp://tsx-11.mit.edu/pub/linux/packages/lilo/. It is also
available on Metalab and mirrors.
_________________________________________________________________
Linux FAQ and HOWTOs
These are available from many sources. Look at the usenet newsgroups
news.answers and comp.os.linux.announce.
The FAQ is available from [91]http://linuxdoc.org/FAQ/Linux-FAQ.html
and the HOWTOs from [92]http://linuxdoc.org/HOWTO/HOWTO-INDEX.html.
Most documentation for Linux may be found at [93]The Linux
Documentation Project homepage.
_________________________________________________________________
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.
_________________________________________________________________
The Linux boot process
For more detail on the Linux boot process, here are some pointers:
* The [94]Linux System Administrators' Guide has a section on
booting.
* The [95]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@tamacom.com) has a very
nice [96]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.
_________________________________________________________________
Appendix B. LILO boot error codes
Questions about these errors are asked so often on Usenet that we
include them here as a public service. This summary is excerpted from
Werner Almsberger's [97]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.
L 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
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).
LI The first stage boot loader was able to load the second stage boot
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.
LIL The second stage boot loader has been started, but it can't load
the descriptor table from the map file. This is typically caused by a
media failure or by a geometry mismatch.
LIL? The second stage boot loader has been loaded at an incorrect
address. This is typically caused by a subtle geometry mismatch or by
moving /boot/boot.b without running the map installer.
LIL- The descriptor table is corrupt. This can either be caused by a
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.
_________________________________________________________________
Appendix 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 110668 Nov 1 15:39 tar
-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.
so
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcom_err.so.2 -> libco
m_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 -> libcryp
t-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 -> libext
2fs.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.7.so
lrwxrwxrwx 1 root root 21 Nov 1 15:39 libnss_files.so.1 -> lib
nss_files-2.0.7.so
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libpam.so.0 -> libpam.so
.0.64
-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 -> libp
am_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 -> libte
rmcap.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 -> libnc
urses.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:
_________________________________________________________________
Appendix 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
[98][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 [99]Filesystem Hierarchy Standard, for
determining where files should go.)
References
1. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PREMADE
2. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN21
3. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN27
4. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN36
5. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN51
6. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN59
7. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN67
8. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN87
9. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN92
10. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN168
11. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#BUILDROOT
12. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN204
13. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#CREATINGROOTFS
14. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN328
15. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PAMANDNSS
16. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN649
17. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN670
18. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#WRAPPINGITUP
19. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN697
20. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN712
21. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TRANSFERRINGWITHLILO
22. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TRANSFERRINGWITHOUTLILO
23. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SETTINGRAMDISKWORD
24. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN834
25. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TROUBLESHOOTING
26. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN954
27. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SLIMFAST
28. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#NONRAMDISKROOT
29. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#UTILITYDISK
30. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PROS
31. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1093
32. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1277
33. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PREMADE
34. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1316
35. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1323
36. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1328
37. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1337
38. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1343
39. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1386
40. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#LISTINGS
41. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#UTILITYLIST
42. http://www.croftj.net/~fawcett/Bootdisk-HOWTO/index.html
43. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TROUBLESHOOTING
44. http://linuxdoc.org/copyright.html
45. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PREMADE
46. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#NONRAMDISKROOT
47. ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/
48. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#FTN.AEN331
49. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#LISTINGS
50. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#LISTINGS
51. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#UTILITYDISK
52. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SLIMFAST
53. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SLIMFAST
54. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TRANSFERRINGWITHOUTLILO
55. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SETTINGRAMDISKWORD
56. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PAMANDNSS
57. http://metalab.unc.edu/pub/Linux/system/shells/
58. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#UTILITYDISK
59. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#BUILDROOT
60. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#UTILITYLIST
61. file://localhost/usr/src/linux/Documentation/initrd.txt
62. ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz
63. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TRANSFERRINGWITHLILO
64. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1097
65. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1104
66. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1111
67. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1128
68. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1143
69. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1159
70. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1182
71. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1205
72. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1238
73. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN1265
74. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#TROUBLESHOOTING
75. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#PROS
76. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#CREATINGROOTFS
77. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#WRAPPINGITUP
78. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#SETTINGRAMDISKWORD
79. http://metalab.unc.edu/pub/Linux/distributions/slackware/bootdsks.144/
80. http://metalab.unc.edu/pub/Linux/distributions/slackware/rootdsks/
81. http://www.slackware.com/getslack/
82. http://metalab.unc.edu/pub/Linux/distributions/redhat/current/i386/images/
83. http://www.redhat.com/mirrors.html
84. ftp://ftp.debian.org/pub/debian/dists/stable/main/disks-i386/current/
85. ftp://ftp.debian.org/pub/debian/README.mirrors.html
86. http://metalab.unc.edu/pub/Linux/system/recovery/!INDEX.html
87. http://metalab.unc.edu/pub/Linux/system/recovery/images
88. http://metalab.unc.edu/pub/Linux/system/recovery/!INDEX.html
89. http://www.croftj.net/~fawcett/yard/index.html
90. ftp://tsx-11.mit.edu/pub/linux/packages/lilo/
91. http://linuxdoc.org/FAQ/Linux-FAQ.html
92. http://linuxdoc.org/HOWTO/HOWTO-INDEX.html
93. http://linuxdoc.org/
94. http://linuxdoc.org/LDP/sag/c1596.html
95. http://metalab.unc.edu/pub/Linux/system/boot/lilo/lilo-t-21.ps.gz
96. http://www.tamacom.com/tour/linux/index.html
97. http://metalab.unc.edu/pub/Linux/system/boot/lilo/lilo-u-21.ps.gz
98. file://localhost/export/sunsite/users/gferg/work/00_Bootdisk-HOWTO.html#AEN331
99. http://www.pathname.com/fhs/2.0/fhs-toc.html