LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/Bootdisk-HOWTO.sgml

3897 lines
140 KiB
Plaintext
Raw Permalink Blame History

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<Article Lang="en">
<Artheader>
<Title>The Linux Bootdisk HOWTO</Title>
<TitleAbbrev>Bootdisk-HOWTO</TitleAbbrev>
<Author>
<Firstname>Tom</Firstname>
<Surname>Fawcett</Surname>
<Affiliation>
<Address>
<Email>Bootdisk-HOWTO@linuxdoc.org</Email>
</Address>
</Affiliation>
</Author>
<Copyright>
<Year>1995-2002</Year>
<Holder>Tom Fawcett</Holder>
</Copyright>
<Legalnotice>
<Para>
Copyright &copy; 1995-2002 by Tom Fawcett and Graham Chapman.
This document may be distributed under the terms set forth in the <Ulink
url="http://linuxdoc.org/copyright.html">Linux Documentation Project
License</Ulink>. Please contact the authors if you are unable to get
the license.
</Para>
</Legalnotice>
<Pubdate>v4.5, January 2002</Pubdate>
<Abstract>
<Para> This document describes how to design and build boot/root
diskettes for Linux. These disks can be used as rescue disks or
to test new system components. You should be reasonably
familiar with system administration tasks before attempting to
build a bootdisk. If you just want a rescue disk to have for
emergencies, see <Xref linkend="PreMade">.
</para>
</Abstract>
</Artheader>
<Sect1><Title>Preface</title>
<Important>
<Para> This document may be outdated. If the date on the title page is
more than six months ago, please check the <Ulink
url="http://www.linuxlots.com/~fawcett/Bootdisk-HOWTO/index.html">
Bootdisk-HOWTO homepage</Ulink> to see if a more recent version exists.
</Para>
</Important>
<Para>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.
</Para>
<Sect2><Title>Version notes</Title>
<INDEXTERM><PRIMARY>kernel</PRIMARY>
<SECONDARY>versions</SECONDARY>
</INDEXTERM>
<Para>Graham Chapman wrote the original Bootdisk-HOWTO and supported it
through version 3.1. Tom Fawcett started as co-author around the time
kernel v2 was introduced, and he is the document's current maintainer.
Chapman has disappeared from the Linux community and his whereabouts are
currently unknown.
</Para>
<Para>This information is intended for Linux on the
<Emphasis>Intel</Emphasis> platform. Much of this information may be
applicable to Linux on other processors, but I have no first-hand
experience or information about this. If you have experience with
bootdisks on other platforms, please contact me.
</Para>
</Sect2>
<Sect2><Title>To do list</Title>
<Para>
<Orderedlist>
<Listitem>
<Para> User-mode-linux (<ULink url="
http://user-mode-linux.sourceforge.net/">
http://user-mode-linux.sourceforge.net</ULink>) seems like a great
way to test out bootdisks without having to reboot your machine
constantly. I haven't been able to get it to work. If anyone has
been using this consistently with homemade bootdisks, please let
me know.
</Para>
</Listitem>
<Listitem>
<Para> Re-analyze distribution bootdisks and update the "How the
Pros do it" section.
</Para>
</Listitem>
<Listitem>
<Para>Figure out just how much of the init-getty-login sequence can
be simplified, and rip it out. A few people have said that
init can be linked directly to /bin/sh; if so, and if this imposes
no great limitations, alter the instructions to do this.
This would eliminate the need for getty, login, gettydefs, and
maybe all that PAM and NSS stuff.
</Para>
</Listitem>
<Listitem>
<Para>Go through the 2.4 kernel source code again and write a
detailed explanation of how the boot process and ramdisk-loading
process work, in detail. (If only so that I understand it
better.) There are some issues about initrd and limitations of
booting devices (eg flash memory) that I don't understand yet.
</Para>
</Listitem>
<Listitem>
<Para> Delete section that describes how to upgrade existing
distribution bootdisks. This is usually more trouble than it's
worth.
</Para>
</Listitem>
<Listitem>
<Para>Replace rdev commands with LILO keywords.
</Para>
</Listitem>
</Orderedlist>
</Para>
</Sect2>
<Sect2><title>Feedback and credits</title>
<Para>I welcome any feedback, good or bad, on the content of this
document. I have done my best to ensure that the instructions and
information herein are accurate and reliable, but I don't know
everything and I don't keep up on kernel development. Please let me
know if you find errors or omissions. When writing, please indicate the
version number of the document you're referencing. Be nice.
</Para>
<Para> 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.
</Para>
<Para>
Send comments and corrections to the author at the email address
above. <Emphasis>Please read <xref linkend="Troubleshooting">
before asking me questions</Emphasis>. Do
<Emphasis>not</Emphasis> email me disk images.
</Para>
</Sect2>
<Sect2><Title>Distribution policy</Title>
<Para> Copyright &copy; 1995-2002 by Tom Fawcett and Graham Chapman.
This document may be distributed under the terms set forth in the <Ulink
url="http://linuxdoc.org/copyright.html">Linux Documentation Project
License</Ulink>. Please contact the authors if you are unable to get
the license.
</Para>
<Para> This is free documentation. It is distributed in the hope
that it will be useful, but <Emphasis>without any
warranty</emphasis>; without even the implied warranty of
<emphasis>merchantability</emphasis> or <emphasis>fitness for a
particular purpose</emphasis>.
</Para>
</Sect2>
</Sect1><!-- End of PREFACE -->
<Sect1><Title>Introduction</Title>
<Para>
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 <filename>libc.so</filename>).
</Para>
<Para>
There are several ways of obtaining boot disks:
<Itemizedlist>
<Listitem>
<Para>
Use one from a distribution such as Slackware. This will at
least allow you to boot.
</Para>
</Listitem>
<Listitem>
<Para>
Use a rescue package to set up disks designed to be used
as rescue disks.
</Para>
</Listitem>
<Listitem>
<Para>
Learn what is required for each of the types of disk to operate,
then build your own.
</Para>
</Listitem>
</Itemizedlist>
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.
</Para>
<Para>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 <command>mount</command> and <command>df</command>. You should
know what <filename>/etc/passwd</filename> and
<filename>fstab</filename> files are for and what they look like. You
should know that most of the commands in this HOWTO should be run as
root.</Para>
<Para>Constructing a bootdisk from scratch can be complicated. If you
haven't read the Linux FAQ and related documents, such as the Linux
Installation HOWTO and the Linux Installation Guide, you should not be
trying to build boot diskettes. If you just need a working bootdisk
for emergencies, it is <emphasis>much</emphasis> easier to download a
prefabricated one. See <xref linkend="PreMade">, below, for where to
find these.
</para>
</Sect1>
<Sect1>
<Title>Bootdisks and the boot process</Title>
<Indexterm><Primary>boot process</primary></indexterm>
<Para>
A bootdisk is basically a miniature, self-contained Linux system on a
diskette. It must perform many of the same functions that a complete
full-size Linux system performs. Before trying to build one you should
understand the basic Linux boot process. Here we present the basics, which
are sufficient for understanding the rest of this document. Many details and
alternative options have been omitted.
</para>
<sect2>
<title>The boot process</title>
<indexterm><primary>Boot sector</primary></indexterm>
<indexterm><primary>BIOS</primary></indexterm>
<indexterm><primary>boot drive</primary></indexterm>
<para>
All PC systems start the boot process by executing code in ROM
(specifically, the <emphasis>BIOS</emphasis>) to load the sector from
sector 0, cylinder 0 of the boot drive. The boot drive is usually the
first floppy drive (designated <filename>A:</filename> in DOS and
<filename>/dev/fd0</filename> in Linux). The BIOS then tries to execute
this sector. On most bootable disks, sector 0, cylinder 0 contains either:
<itemizedlist>
<listitem>
<para>
code from a boot loader such as LILO, which locates the kernel,
loads it and executes it to start the boot proper; or
</para>
</listitem>
<listitem>
<para>
the start of an operating system kernel, such as Linux.
</para>
</listitem>
</itemizedlist>
</para>
<para>
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.
</para>
<indexterm><primary>root filesystem</primary></indexterm>
<indexterm><primary>ramdisk</primary></indexterm>
<indexterm><primary>compressed filesystem</primary></indexterm>
<para>
When the kernel is completely loaded, it initializes device drivers and its
internal data structures. Once it is completely initialized, it consults a
special location in its image called the <Emphasis>ramdisk word</Emphasis>.
This word tells it how and where to find its <Emphasis>root
filesystem</Emphasis>. A root filesystem is simply a filesystem that will be
mounted as ``<filename>/</filename>''. The kernel has to be told where to
look for the root filesystem; if it cannot find a loadable image there, it
halts.
</para>
<para>In some boot situations &mdash; often when booting from a diskette
&mdash; the root filesystem is loaded into a <emphasis>ramdisk</emphasis>,
which is RAM accessed by the system as if it were a disk. RAM is several
orders of magnitude faster than a floppy disk, so system operation is fast
from a ramdisk. Also, the kernel can load a <emphasis>compressed
filesystem</emphasis> from the floppy and uncompress it onto the ramdisk,
allowing many more files to be squeezed onto the diskette. </para>
<para>
Once the root filesystem is loaded and mounted, you see a message like:
<Screen width=60>
VFS: Mounted root (ext2 filesystem) readonly.
</Screen>
</para>
<indexterm><primary>init</primary></indexterm>
<indexterm><primary>inittab</primary></indexterm>
<indexterm><primary>sysinit</primary></indexterm>
<para>Once the system has loaded a root filesystem successfully, it tries to
execute the <filename>init</filename> program (in <filename>/bin</filename> or
<filename>/sbin</filename>). <filename>init</filename> reads its
configuration file <filename>/etc/inittab</filename>, looks for a line
designated <literal>sysinit</literal>, and executes the named script. The
<literal>sysinit</literal> script is usually something like
<filename>/etc/rc</filename> or <filename>/etc/init.d/boot</filename>. This
script is a set of shell commands that set up basic system services, such as
running <command>fsck</command> on hard disks, loading necessary kernel
modules, initializing swapping, initializing the network, and mounting disks
mentioned in <filename>/etc/fstab</filename>.
</Para>
<Indexterm><Primary><Filename>/etc/rc.d/</Filename></Primary></Indexterm>
<Para>This script often invokes various other scripts to do modular
initialization. For example, in the common SysVinit structure, the directory
<filename>/etc/rc.d/</filename> 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.
</Para>
<Para>
When the sysinit script finishes control returns to <command>init</command>,
which then enters the <emphasis>default runlevel</emphasis>, specified in
<filename>inittab</filename> with the <literal>initdefault</literal> keyword.
The runlevel line usually specifies a program like <command>getty</command>,
which is responsible for handling commununications through the console and
ttys. It is the <command>getty</command> program which prints the familiar
``<prompt>login:</prompt>'' prompt. The <command>getty</command> program in
turn invokes the <command>login</command> program to handle login validation
and to set up user sessions.
</para>
</sect2>
<sect2>
<title>Disk types</title>
<para>
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.
</para>
<para>
<variablelist>
<varlistentry><term>boot</term>
<listitem>
<para>
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.
</para>
<para>
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,
``<command>make zdisk</command>'' will create such a bootdisk automatically
from the kernel source code).
</para>
</listitem>
</varlistentry>
<varlistentry><term>root</term>
<listitem>
<para>
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.
<Indexterm><Primary>root disk</Primary></Indexterm>
</para>
<para>
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.
</para>
</listitem>
</varlistentry>
<varlistentry><term>boot/root</term>
<indexterm><primary>boot/root</primary></indexterm>
<listitem>
<para>
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 &mdash; 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.
</para>
</listitem>
</varlistentry>
<varlistentry><term>utility</term>
<listitem>
<para>
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.
<indexterm><primary>utility diskette</primary></indexterm>
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
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.
</para>
</sect2>
</sect1>
<sect1 id="BuildRoot">
<title>Building a root filesystem</title>
<para>
Creating the root filesystem involves selecting files necessary for the
system to run. In this section we describe how to build a
<emphasis>compressed root filesystem</emphasis>. A less common option is to
build an uncompressed filesystem on a diskette that is directly mounted as
root; this alternative is described in <xref
linkend="NonRamdiskRoot">.
</para>
<sect2>
<title>Overview</title>
<para>
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:
</para>
<para>
<itemizedlist>
<listitem>
<para>
The basic file system structure,
</para>
</listitem>
<listitem>
<para>
Minimum set of directories: <filename class="directory">/dev</filename>,
<filename class="directory">/proc</filename>,
<filename class="directory">/bin</filename>,
<filename class="directory">/etc</filename>,
<filename class="directory">/lib</filename>,
<filename class="directory">/usr</filename>,
<filename class="directory">/tmp</filename>,
</para>
</listitem>
<listitem>
<para>
Basic set of utilities: <filename/sh/, <filename/ls/, <filename/cp/,
<filename/mv/, etc.,
</para>
</listitem>
<listitem>
<para>
Minimum set of config files: <filename>rc, inittab, fstab</filename>, etc.,
</para>
</listitem>
<listitem>
<para>
Devices: <filename>/dev/hd*, /dev/tty*, /dev/fd0</filename>, etc.,
</para>
</listitem>
<listitem>
<para>
Runtime library to provide basic functions used by utilities.
</para>
</listitem>
</itemizedlist>
</para>
<para>
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:
</para>
<para>
<itemizedlist>
<listitem>
<para>
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
<command>fsck</command> on your original root drive while it is not
mounted.
</para>
</listitem>
<listitem>
<para> Restore all or part of your original root drive from backup using
archive and compression utilities such as <filename>cpio</filename>,
<filename>tar</filename>, <filename>gzip</filename> and
<filename>ftape</filename>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
We describe how to build a <emphasis>compressed</emphasis> 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.
</para>
</sect2>
<sect2 id="CreatingRootFS">
<title>Creating the filesystem</title>
<para>
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:
</para>
<para>
<itemizedlist>
<listitem>
<para> Use a <emphasis>ramdisk</emphasis> (<Symbol>DEVICE</Symbol> =
<filename>/dev/ram0</filename>). 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
(<filename>/etc/lilo.conf</filename>) for a line like <literal>RAMDISK =
nnn</literal> 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 <Filename>/dev/ram0,
/dev/ram</Filename> or <Filename>/dev/ramdisk</Filename>. If not, create
<Filename>/dev/ram0</Filename> with <Command>mknod</Command> (major number
1, minor 0).
</para>
</listitem>
<listitem>
<para>
If you have an unused hard disk partition that is large enough (several
megabytes), this is acceptable.
</para>
</listitem>
<listitem>
<para>
Use a <Emphasis>loopback device</Emphasis>, 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.
</para>
<para>
Type <Command>man losetup</Command> for instructions on using loopback
devices. If you don't have <command>losetup</command>, you can get it
along with compatible versions of <command>mount</command> and
<command>unmount</command> from the <filename>util-linux</filename> package
in the directory <ulink
url="ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/"><filename
class="directory">ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/
</filename>
</ulink>.
</para>
<para> If you do not have a loop device (<filename>/dev/loop0</filename>,
<filename>/dev/loop1</filename>, etc.) on your system, you will have to
create one with ``<command>mknod /dev/loop0 b 7 0</command>''. Once you've
installed these special <command>mount</command> and
<command>umount</command> binaries, create a temporary file on a hard disk
with enough capacity (eg, <filename>/tmp/fsfile</filename>). You can use a
command like:
<Screen>
dd if=/dev/zero of=/tmp/fsfile bs=1k count=<varname>nnn</varname>
</Screen>
to create an <varname>nnn</varname>-block file.
</para>
<Para>
Use the file name in place of <Symbol>DEVICE</Symbol> below. When you issue a
mount command you must include the option <option>-o loop</option> to tell
mount to use a loopback device.
<Indexterm><Primary>loopback device</Primary></Indexterm>
</Para>
</Listitem>
</Itemizedlist>
</Para>
<Para>
After you've chosen one of these options, prepare the <Symbol>DEVICE</Symbol>
with:
<Screen width=50>
dd if=/dev/zero of=<Symbol>DEVICE</Symbol> bs=1k count=4096
</Screen>
</para>
<para>
This command zeroes out the device.
</para>
<Important>
<Para>
Zeroing the device is critical because the filesystem will be compressed
later, so all unused portions should be filled with zeroes to achieve maximum
compression. Keep this in mind whenever you move or delete files on the
filesystem. The filesystem will correctly de-allocate the blocks,
<Emphasis>but it will not zero them out again</Emphasis>. If you do a lot of
deletions and copying, your compressed filesystem may end up much larger than
necessary.
</Para>
</Important>
<Para>
<Indexterm><Primary>inodes</Primary>
<Secondary>allocation on root filesystem</Secondary></Indexterm>
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 <literal>-N</literal> option to specify more inodes than the
default; <literal>-N 2000</literal> is suggested so that you don't run out of
inodes. Alternatively, you can save on inodes by removing lots of unnecessary
<Filename>/dev</Filename> files. <Command>mke2fs</Command> 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
<Filename>/dev</Filename> 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. </Para>
<Para>
So the command you use will look like:
<Screen>
mke2fs -m 0 -N 2000 <Symbol>DEVICE</Symbol>
</Screen>
</Para>
<Para>
(If you're using a loopback device, the disk file you're using should be
supplied in place of this <Symbol>DEVICE</Symbol>.)
</Para>
<Indexterm><Primary>loopback device</Primary></Indexterm>
<Para>The <Command>mke2fs</Command> command will automatically detect the
space available and configure itself accordingly. The
``<Literal>-m&nbsp;0</Literal>'' parameter prevents it from reserving space
for root, and hence provides more usable space on the disk.
</para>
<para>
Next, mount the device:
<Screen>
mount -t ext2 <Symbol>DEVICE</Symbol> /mnt
</Screen>
(You must create a mount point <filename>/mnt</filename> if it
does not already exist.) In the remaining sections, all destination
directory names are assumed to be relative to <Filename>/mnt</Filename>.
</para>
</sect2>
<sect2>
<title>Populating the filesystem</title>
<para>
Here is a reasonable minimum set of directories for your root filesystem
<footnote>
<para>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 <Ulink url="http://www.pathname.com/fhs/2.0/fhs-toc.html">Filesystem
Hierarchy Standard</ulink>, for determining where files should go.)
</Para>
</Footnote>:
<Itemizedlist>
<Listitem>
<Para><Filename>/dev</Filename> -- Device files, required to perform I/O
</Para>
</Listitem>
<Listitem>
<Para><Filename>/proc</Filename> -- Directory stub required by the
proc filesystem
</Para>
</Listitem>
<Listitem>
<Para><Filename>/etc</Filename> -- System configuration files
</Para>
</Listitem>
<Listitem>
<Para><Filename>/sbin</Filename> -- Critical system binaries
</Para>
</Listitem>
<Listitem>
<Para><Filename>/bin</Filename> -- Essential binaries considered part of the
system
</Para>
</Listitem>
<Listitem>
<Para><Filename>/lib</Filename> -- Shared libraries to provide run-time
support
</Para>
</Listitem>
<Listitem>
<Para><Filename>/mnt</Filename> -- A mount point for maintenance on other
disks
</Para>
</Listitem>
<Listitem>
<Para><Filename>/usr</Filename> -- Additional utilities and applications
</Para>
</Listitem>
</Itemizedlist>
</Para>
<Para>
Three of these directories will be empty on the root filesystem, so they
only need to be created with <Command>mkdir</Command>. The
<filename>/proc</filename> directory is basically a stub under which the
proc filesystem is placed. The directories <filename>/mnt</filename> and
<filename>/usr</filename> are only mount points for use after the boot/root
system is running. Hence again, these directories only need to be created.
</para>
<para>
The remaining four directories are described in the following sections.
</para>
<sect3><title>/dev</title>
<Indexterm><Primary>device (dev) directory</Primary></Indexterm>
<para> A <filename>/dev</filename> 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 <literal>mkdir</literal> in the normal way. The device
special files, however, must be created in a special way, using the
<Command>mknod</Command> command.
</para>
<para> There is a shortcut, though &mdash; copy devices files from your
existing hard disk <filename>/dev</filename> directory. The only requirement
is that you copy the device special files using <literal>-R</literal> option.
This will copy the directory without attempting to copy the contents of the
files. Be sure to use an <Emphasis>upper case <Option>R</Option></Emphasis>.
For example:
<Screen>
cp -dpR /dev/fd[01]* /mnt/dev
cp -dpR /dev/tty[0-6] /mnt/dev
</Screen>
assuming that the diskette is mounted at <filename>/mnt</filename>. The
<literal>dp</literal> 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.
</para>
<para>
If you want to do it the hard way, use <literal>ls -l</literal> to display the
major and minor device numbers for the devices you want, and create them on
the diskette using <literal>mknod</literal>.
</para>
<Para>However the devices files are created, check that any special devices
you need have been placed on the rescue diskette. For example,
<literal>ftape</literal> uses tape devices, so you will need to copy all of
these if you intend to access your floppy tape drive from the bootdisk.
</Para>
<Para>Note that one inode is required for each device special file, and inodes
can at times be a scarce resource, especially on diskette filesystems. You'll
need to be selective about the device files you include. For example, if you
do not have SCSI disks you can safely ignore <Literal>/dev/sd*</Literal>; if
you don't intend to use serial ports you can ignore
<Literal>/dev/ttyS*</Literal>. </Para>
<Para>If, in building your root filesystem, you get the error <Literal>No
space left on device</Literal> but a <Literal>df</Literal> command shows space
still available, you have probably run out of inodes. A <Literal>df
-i</Literal> will display inode usage.
</Para>
<Important><Para>Be sure to include the following files from this directory:
<Filename/console/, <Filename/kmem/, <Filename/mem/, <Filename/null/,
<Filename/ram0/ and <Filename/tty1/.</para> </Important>
</sect3>
<sect3><title>/etc</title>
<Indexterm><Primary>etc directory</Primary></Indexterm>
<para>
The /etc directory contains configuration files. What it should contain
depends on what programs you intend to run.
On most systems, these can be divided into three groups:
<OrderedList>
<Listitem>
<Para>
Required at all times, <Emphasis>e.g.</Emphasis> <Filename/rc/,
<Filename/fstab/, <Filename/passwd/.
</Para>
</Listitem>
<Listitem>
<Para>
May be required, but no one is too sure.
</Para>
</Listitem>
<Listitem>
<Para>
Junk that crept in.
</Para>
</Listitem>
</Orderedlist>
Files which are not essential can usually be identified with the command:
<Screen>
ls -ltru
</Screen>
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.
</Para>
<Para>
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:
<Orderedlist>
<Listitem>
<Para>
The ones I must configure for a boot/root system:
<Orderedlist>
<Listitem>
<Para>
<Filename>rc.d/*</Filename> -- system startup and run level change scripts
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>fstab</Filename> -- list of file systems to be mounted
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>inittab</Filename> -- parameters for the
<Command>init</Command> process, the first process started at boot time.
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>gettydefs</Filename> -- parameters for the
<Command>init</Command> process, the first process started at boot time.
</Para>
</Listitem>
</Orderedlist>
</Para>
</Listitem>
<Listitem>
<Para>
The ones I should tidy up for a boot/root system:
<Orderedlist>
<Listitem>
<Para>
<Filename>passwd</Filename> -- Critical list of users, home directories, etc.
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>group</Filename> -- user groups.
<Indexterm><Primary>user groups</Primary></Indexterm>
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>shadow</Filename> -- passwords of users. You may not have this.
<Indexterm><Primary>shadow passwords</Primary></Indexterm>
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>termcap</Filename> -- the terminal capability database.
</Para>
</Listitem>
</Orderedlist>
</Para>
<Para>
If security is important, <filename>passwd</filename> and
<filename>shadow</filename> should be pruned to avoid copying user passwords
off the system, and so that unwanted logins are rejected when you boot from
diskette.
</Para>
<Indexterm><Primary>restoring files</Primary></Indexterm>
<Para>
<Indexterm><Primary>shadow passwords</Primary></Indexterm>
<Indexterm><Primary><Filename>passwd</Filename></Primary></Indexterm>
Be sure that <Filename>passwd</Filename> contains at least
<Literal>root</Literal>. If you intend other users to login, be sure their
home directories and shells exist.
</Para>
<Para>
<Filename>termcap</Filename>, 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
<Literal>linux</Literal> or <Literal>linux-console</Literal> entry.
</Para>
</Listitem>
<Listitem>
<Para>
The rest. They work at the moment, so I leave them alone.
</Para>
</Listitem>
</Orderedlist>
</Para>
<Para>
Out of this, I only really have to configure two files, and what they
should contain is surprisingly small.
<Itemizedlist>
<Listitem>
<Para>
<Filename>rc</Filename> should contain:
<Programlisting>
#!/bin/sh
/bin/mount -av
/bin/hostname Kangaroo
</Programlisting>
Be sure it is executable, be sure it has a "#!" line at the top, and be sure
any absolute filenames are correct. You don't really need to run
<Command>hostname</Command> &mdash; it just looks nicer if you do.
</Para>
</Listitem>
<Listitem>
<Para>
<Filename>fstab</Filename> should contain at least:
<Programlisting>
/dev/ram0 / ext2 defaults
/dev/fd0 / ext2 defaults
/proc /proc proc defaults
</Programlisting>
<Indexterm><Primary><Filename>fstab</Filename></Primary></Indexterm>
You can copy entries from your existing <Filename>fstab</Filename>, but you
should not automatically mount any of your hard disk partitions; use the
<Literal>noauto</Literal> keyword with them. Your hard disk may be damaged
or dead when the bootdisk is used.
</Para>
</Listitem>
</Itemizedlist>
</Para>
<Para>
Your <Filename>inittab</Filename> should be changed so that its
<Literal>sysinit</Literal> line runs <Filename>rc</Filename> 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
<Filename>getty</Filename> which include a <Filename>ttys</Filename> or
<Filename>ttyS</Filename> device at the end of the line. Leave in the
<Filename>tty</Filename> ports so that you can login at the console.
</para>
<Indexterm><Primary><Filename>inittab</Filename></Primary></Indexterm>
<Indexterm><Primary><Filename>sysinit</Filename></Primary></Indexterm>
<Indexterm><Primary><Filename>rc</Filename></Primary></Indexterm>
<para>
A minimal <Filename>inittab</Filename> file looks like this:
<Programlisting>
id:2:initdefault:
si::sysinit:/etc/rc
1:2345:respawn:/sbin/getty 9600 tty1
2:23:respawn:/sbin/getty 9600 tty2
</Programlisting>
The <Filename>inittab</Filename> file defines what the system will run in
various states including startup, move to multi-user mode, etc.
Check carefully the filenames mentioned in <filename>inittab</filename>; if
<literal>init</literal> cannot find the program mentioned the bootdisk will
hang, and you may not even get an error message.
</para>
<Indexterm><Primary>hardcoded locations</Primary></Indexterm>
<para>
Note that some programs cannot be moved elsewhere because other programs have
hardcoded their locations. For example, on my system,
<Filename>/etc/shutdown</Filename> has hardcoded in it
<Filename>/etc/reboot</Filename>. If I move <Filename>reboot</Filename> to
<Filename>/bin/reboot</Filename>, and then issue a <Literal>shutdown</Literal>
command, it will fail because it cannot find the <Literal>reboot</Literal>
file.
</Para>
<Indexterm><Primary>etc directory</Primary></Indexterm>
<Para>For the rest, just copy all the text files in your
<Filename>/etc</Filename> directory, plus all the executables in your
<filename>/etc</filename> directory that you cannot be sure you do not need.
As a guide, consult the sample listing in <Xref linkend="Listings">. 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
<Literal>inittab</Literal> and work out what is required.
</para>
<para>Most systems now use an <filename>/etc/rc.d/</filename> directory
containing shell scripts for different run levels. The minimum is a single
<filename>rc</filename> script, but it may be simpler just to copy
<Filename>inittab</Filename> and the <Filename>/etc/rc.d</Filename>
directory from your existing system, and prune the shell scripts in the
<Filename>rc.d</Filename> directory to remove processing not relevent to a
diskette system environment.
</para>
</Sect3>
<Sect3>
<Title>/bin and /sbin</Title>
<Indexterm><Primary>bin directory</Primary></Indexterm>
<Indexterm><Primary>sbin directory</Primary></Indexterm>
<Para>
The <filename>/bin</filename> directory is a convenient place for extra
utilities you need to perform basic operations, utilities such as
<command>ls</command>, <command>mv</command>, <command>cat</command> and
<command>dd</command>. See <xref linkend="Listings"> for an example list
of files that go in a <command>/bin</command> and
<filename>/sbin</filename> directories. It does not include any of the
utilities required to restore from backup, such as <command>cpio</command>,
<command>tar</command> and <command>gzip</command>. 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 <filename>/usr</filename>.
</para>
<para> Creation of a utility diskette is described below in <xref
linkend="UtilityDisk">. 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.
</para>
<Important>
<Para>
Be sure to include the following programs: <filename/init/,
<filename/getty/ or equivalent, <filename/login/, <filename/mount/, some
shell capable of running your rc scripts, a link from <filename/sh/ to the
shell.
</para>
</Important>
<Indexterm><Primary>init</Primary></Indexterm>
<Indexterm><Primary>getty</Primary></Indexterm>
<Indexterm><Primary>login</Primary></Indexterm>
<Indexterm><Primary>sh</Primary></Indexterm>
<Indexterm><Primary>shells</Primary></Indexterm>
</sect3>
<Sect3><Title>/lib</Title>
<Indexterm><Primary>library (lib) directory</Primary></Indexterm>
<Indexterm><Primary>libraries</Primary></Indexterm>
<para>
In <filename>/lib</filename> you place necessary shared libraries and
loaders. If the necessary libraries are not found in your
<filename>/lib</filename> directory then the system will be unable to boot.
If you're lucky you may see an error message telling you why.
</para>
<para>
<Indexterm><Primary><Filename>libc.so</Filename></Primary></Indexterm>
Nearly every program requires at least the <filename>libc</filename>
library, <Filename>libc.so.</Filename><Emphasis>N</Emphasis>, where
<emphasis>N</emphasis> is the current version number. Check your
<filename>/lib</filename> directory. The file
<filename>libc.so.N</filename> is usually a symlink to a filename with a
complete version number:
</para>
<para>
<Screen width=82>
% 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*
</Screen>
</para>
<para> In this case, you want <filename>libc-2.1.1.so</filename>. To find
other libraries you should go through all the binaries you plan to include
and check their dependencies with <Command>ldd</Command>. For example:
<Screen width=70>
% ldd /sbin/mke2fs
libext2fs.so.2 =&#62; /lib/libext2fs.so.2 (0x40014000)
libcom&lowbar;err.so.2 =&#62; /lib/libcom&lowbar;err.so.2 (0x40026000)
libuuid.so.1 =&#62; /lib/libuuid.so.1 (0x40028000)
libc.so.6 =&#62; /lib/libc.so.6 (0x4002c000)
/lib/ld-linux.so.2 =&#62; /lib/ld-linux.so.2 (0x40000000)
</Screen>
Each file on the right-hand side is required. The file may be a symbolic
link.
</para>
<para> Note that some libraries are <emphasis>quite large</emphasis> and
will not fit easily on your root filesystem. For example, the
<filename>libc.so</filename> listed above is about 4 meg. You will
probably need to strip libraries when copying them to your root filesystem.
See <xref linkend="slimfast"> for instructions.
</para>
<Indexterm><Primary>loaders</Primary></Indexterm>
<para>
In <filename>/lib</filename> you must also include a loader for the libraries.
The loader will be either <filename>ld.so</filename> (for A.OUT libraries,
which are no longer common) or <filename>ld-linux.so</filename> (for
ELF libraries). Newer versions of <command>ldd</command> 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 <command>file</command> command on
the library. For example:
<Screen width=80>
% file /lib/libc.so.4.7.2 /lib/libc.so.5.4.33 /lib/libc-2.1.1.so
/lib/libc.so.4.7.2: Linux/i386 demand-paged executable (QMAGIC), stripped
/lib/libc.so.5.4.33: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/libc-2.1.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
</Screen>
The <literal>QMAGIC</literal> indicates that <literal>4.7.2</literal> is for
A.OUT libraries, and <literal>ELF</literal> indicates that
<literal>5.4.33</literal> and <literal>2.1.1</literal> are for ELF.
<Indexterm><Primary>ELF</Primary></Indexterm>
</para>
<para>
Copy the specific loader(s) you need to the root filesystem you're building.
Libraries and loaders should be checked <Emphasis>carefully</Emphasis> against
the included binaries. If the kernel cannot load a necessary library, the
kernel may hang with no error message.
</para>
</sect3>
</sect2>
<Sect2 id="PAMandNSS">
<Title>Providing for PAM and NSS</title>
<Para>
Your system may require dynamically loaded libraries that are not visible to
<filename>ldd</filename>. If you don't provide for these, you may have
trouble logging in or using your bootdisk.
</Para>
<sect3>
<Title>PAM (Pluggable Authentication Modules)</Title>
<Para>
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 <filename>ldd</filename>
on your <filename>login</filename> executable; if the output includes
<filename>libpam.so</filename>, you need PAM.
</Para>
<Para>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 <filename>/etc/pam.conf</filename> file in your root filesystem that
looks like this:
<Programlisting>
OTHER auth optional /lib/security/pam&lowbar;permit.so
OTHER account optional /lib/security/pam&lowbar;permit.so
OTHER password optional /lib/security/pam&lowbar;permit.so
OTHER session optional /lib/security/pam&lowbar;permit.so
</Programlisting>
Also copy the file <filename>/lib/security/pam&lowbar;permit.so</filename> to
your root filesystem. This library is only about 8K so it imposes minimal
overhead.
</Para>
<Para>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 <filename>/lib/security</filename> onto your root
filesystem.
</Para>
<Para>
You must also include <Filename>/lib/libpam.so</Filename> on your bootdisk.
But you already know this since you ran ldd on
<Filename>/bin/login</Filename>, which showed this dependency.
</Para>
</Sect3>
<Sect3>
<Title>NSS (Name Service Switch)</Title>
<Para>
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
<Filename>/etc/nsswitch.conf</Filename> 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
<Filename>nsswitch.conf</Filename> file that looks like this:
<Programlisting>
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
</Programlisting>
This specifies that every service be provided only by local files.
You will also need to include
<Filename>/lib/libnss&lowbar;files.so.</Filename><Emphasis>X</Emphasis>,
where <Emphasis>X</Emphasis> is 1 for glibc 2.0 and 2 for glibc 2.1.
This library will be loaded dynamically to handle the file lookups.
</Para>
<Para>
If you plan to access the network from your bootdisk, you may want to create a
more elaborate <filename>nsswitch.conf</filename> file. See the
<Filename>nsswitch</Filename> man page for details. You must include a file
<Filename>/lib/libnss&lowbar;</Filename><Emphasis>service</Emphasis><Filename>.so.1</Filename>
for each <Emphasis>service</Emphasis> you specify.
</para>
</sect3>
</sect2>
<sect2>
<title>Modules</title>
<Indexterm><Primary>modules</Primary></Indexterm>
<para> 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 <command>ftape</command> and <command>zftape</command> 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.
</para>
<para>
These modules may be placed in <filename>/lib/modules</filename>. You should also
include <command>insmod</command>, <command>rmmod</command> and <command>lsmod</command>. Depending on whether you
want to load modules automatically, you might also include <command>modprobe</command>,
<command>depmod</command> and <command>swapout</command>. If you use
<command>kerneld</command>, include it along
with <filename>/etc/conf.modules</filename>.
</para>
<para>
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.
</para>
<Important>
<Para>
In order to boot a compressed ext2 filesystem, you must have ramdisk and
ext2 support built-in. <Emphasis>They cannot be supplied as
modules.</Emphasis>
</Para>
</Important>
</sect2>
<sect2>
<title>Some final details</title>
<para> Some system programs, such as <command>login</command>, complain if
the file <filename>/var/run/utmp</filename> and the directory
<filename>/var/log</filename> do not exist. So:
</para>
<Screen width=60>
mkdir -p /mnt/var/&lcub;log,run&rcub;
touch /mnt/var/run/utmp
</Screen>
<para>
Finally, after you have set up all the libraries you need, run
<command>ldconfig</command> to remake <filename>/etc/ld.so.cache</filename> on
the root filesystem. The cache tells the loader where to find the libraries.
You can do this with:
<Screen width=60>
ldconfig -r /mnt
</Screen>
<Indexterm><Primary><Filename>ldconfig</Filename></Primary></Indexterm>
<Indexterm><Primary><Filename>ld.so.cache</Filename></Primary></Indexterm>
</para>
</sect2>
<Sect2 id="WrappingItUp"><Title>Wrapping it up</Title>
<para>
When you have finished constructing the root filesystem, unmount it, copy it
to a file and compress it:
<Screen width=50>
umount /mnt
dd if=<Symbol>DEVICE</Symbol> bs=1k | gzip -v9 > rootfs.gz
</Screen>
When this finishes you will have a file <filename>rootfs.gz</filename>. 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 <xref
linkend="Slimfast">.
</para>
</sect2>
</sect1>
<sect1><title>Choosing a kernel</title>
<Indexterm><Primary>kernel, choosing</Primary></Indexterm>
<para>
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.
</para>
<para>
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 <emphasis>must</emphasis> have ramdisk and ext2 support
built into it.
</para>
<para> 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 <Command>ftape</Command>, and then try to read
your backups.
</para>
<para>
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.
</para>
<Indexterm><Primary>kernel, building from source</Primary></Indexterm>
<para>
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 <filename>/usr/src/linux</filename>. If you have trouble
building a kernel, you should probably not attempt to build boot/root
systems anyway. Remember to compress the kernel with ``<command>make zImage</command>''.
</para>
</sect1>
<sect1>
<title>Putting them together: Making the diskette(s)</title>
<para>
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.
</para>
<para> 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 <filename>/etc/lilo.conf</filename> on your
system. If it exists and has a line like
``<literal>append=...</literal>'', 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 <emphasis>kernel
filesystem</emphasis>, where you transfer the kernel and a few other files
that LILO needs.
</para>
<Indexterm><Primary>lilo filesystem</Primary></Indexterm>
<Indexterm><Primary><Filename>lilo.conf</Filename></Primary></Indexterm>
<Indexterm><Primary>kernel</Primary><Secondary>parameters</Secondary></Indexterm>
<para> If you are going to use LILO, read on; if you are going to transfer
the kernel directly, skip ahead to <xref
linkend="TransferringWithoutLILO">.
</para>
<sect2 id="TransferringWithLILO">
<title>Transferring the kernel with LILO</title>
<para>
First, make sure you have a recent version of LILO.
</para>
<para>
You must create a small configuration file for LILO.
It should look like this:
<Programlisting>
boot =/dev/fd0
install =/boot/boot.b
map =/boot/map
read-write
backup =/dev/null
compact
image = KERNEL
label = Bootdisk
root =/dev/fd0
</Programlisting>
For an explanation of these parameters, see LILO's user documentation. You
will probably also want to add an <literal>append=...</literal> line to
this file from your hard disk's <filename>/etc/lilo.conf</filename> file.
</para>
<para>
Save this file as <filename>bdlilo.conf</filename>.
</para>
<para> You now have to create a small filesystem, which we shall call a
<emphasis>kernel filesystem</emphasis>, to distinguish it from the root
filesystem.
</para>
<para>
First, figure out how large the filesystem should be. Take the size of your
kernel in blocks (the size shown by ``<command>ls -s KERNEL</command>'') 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
<literal>KERNEL&lowbar;BLOCKS</literal>.
</para>
<para>
Put a floppy diskette in the drive (for simplicity we'll assume
<filename>/dev/fd0</filename>) and create an ext2 kernel filesystem on it:
<Screen width=50>
mke2fs -N 24 -m 0 /dev/fd0 KERNEL&lowbar;BLOCKS
</Screen>
<Indexterm><Primary>inodes</Primary><Secondary>allocation</Secondary></Indexterm>
The ``<literal>-N 24</literal>'' specifies 24 inodes, which is all you should
need for this filesystem. Next, mount the filesystem, remove the
<filename>lost+found</filename> directory, and create <filename>dev</filename>
and <filename>boot</filename> directories for LILO:
<Screen>
mount -o dev /dev/fd0 /mnt
rm -rf /mnt/lost+found
mkdir /mnt/&lcub;boot,dev&rcub;
</Screen>
</Para>
<Para>
Next, create devices <filename>/dev/null</filename> and
<Filename>/dev/fd0</Filename>. Instead of looking up the device numbers, you
can just copy them from your hard disk using <literal>-R</literal>:
<Screen>
cp -R /dev/{null,fd0} /mnt/dev
</Screen>
LILO needs a copy of its boot loader, <filename>boot.b</filename>, which
you can take from your hard disk. It is usually kept in the
<filename>/boot</filename> directory.
<Screen>
cp /boot/boot.b /mnt/boot
</Screen>
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:
<Screen>
cp bdlilo.conf KERNEL /mnt
</Screen>
Everything LILO needs is now on the kernel filesystem, so you are ready to run
it. LILO's <literal>-r</literal> flag is used for installing the boot loader on some other
root:
<Screen>
lilo -v -C bdlilo.conf -r /mnt
</Screen>
LILO should run without error, after which the kernel filesystem
should look something like this:
<Screen width=75>
total 361
1 &ndash;rw&ndash;r&ndash;&ndash;r&ndash;&ndash; 1 root root 176 Jan 10 07:22 bdlilo.conf
1 drwxr&ndash;xr&ndash;x 2 root root 1024 Jan 10 07:23 boot/
1 drwxr&ndash;xr&ndash;x 2 root root 1024 Jan 10 07:22 dev/
358 &ndash;rw&ndash;r&ndash;&ndash;r&ndash;&ndash; 1 root root 362707 Jan 10 07:23 vmlinuz
boot:
total 8
4 &ndash;rw&ndash;r&ndash;&ndash;r&ndash;&ndash; 1 root root 3708 Jan 10 07:22 boot.b
4 &ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 3584 Jan 10 07:23 map
dev:
total 0
0 brw&ndash;r&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 2, 0 Jan 10 07:22 fd0
0 crw&ndash;r&ndash;&ndash;r&ndash;&ndash; 1 root root 1, 3 Jan 10 07:22 null
</Screen>
</Para>
<Indexterm><Primary>kernel</Primary><Secondary>filesystem</Secondary></Indexterm>
<Para>
Do not worry if the file sizes are slightly different from yours.
</Para>
<Para>
Now leave the diskette in the drive and go to <xref
linkend="SettingRamdiskWord">.
</Para>
</Sect2>
<Sect2 id="TransferringWithoutLILO">
<Title>Transferring the kernel without LILO</Title>
<Para>
If you are <emphasis>not</emphasis> using LILO, transfer the kernel to the
bootdisk with <command>dd</command>:
<Screen width=50>
% dd if=KERNEL of=/dev/fd0 bs=1k
353+1 records in
353+1 records out
</Screen>
In this example, <command>dd</command> wrote 353 complete records + 1
partial record, so the kernel occupies the first 354 blocks of the
diskette. Call this number <literal>KERNEL&lowbar;BLOCKS</literal> and
remember it for use in the next section.
</para>
<para>
Finally, set the root device to be the diskette itself, then set the
root to be loaded read/write:
<Screen>
rdev /dev/fd0 /dev/fd0
rdev -R /dev/fd0 0
</Screen>
<Indexterm><Primary>rdev</Primary></Indexterm>
Be careful to use a capital <literal>-R</literal> in the second
<Command>rdev</Command> command.
</para>
</sect2>
<sect2 id="SettingRamdiskWord"><title>Setting the ramdisk word</title>
<para>
Inside the kernel image is the <Emphasis>ramdisk word</Emphasis> that
specifies where the root filesystem is to be found, along with other
options. The word can be accessed and set via the <Command>rdev</Command>
command, and its contents are interpreted as follows:
<InformalTable>
<Tgroup cols=2 align=left>
<Colspec colname=Bit align=right colwidth="1in">
<Colspec colname=Descrip align=left>
<Thead>
<Row>
<entry>Bit field</entry>
<entry>Description</entry>
</Row>
</Thead>
<Tbody>
<Row>
<entry>0-10</entry>
<entry>Offset to start of ramdisk, in 1024 byte blocks</entry>
</Row>
<Row>
<entry>11-13</entry>
<entry>unused</entry>
</Row>
<Row>
<entry>14</entry>
<entry>Flag indicating that ramdisk is to be loaded</entry>
</Row>
<Row>
<entry>15</entry>
<entry>Flag indicating to prompt before loading rootfs</entry>
</Row>
</Tbody>
</TGroup>
</InformalTable>
</para>
<para>
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.
</para>
<para>
There are two cases, depending on whether you are building a single
boot/root diskette or a double ``boot+root'' diskette set.
</para>
<orderedlist>
<listitem>
<para> 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
<literal>KERNEL&lowbar;BLOCKS</literal>). 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&circ;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,
</para>
</listitem>
<listitem>
<para>
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&circ;14 + 2&circ;15 = 49152 in this case.
</para>
</listitem>
</orderedlist>
<Indexterm><Primary>ramdisk word</Primary></Indexterm>
<Indexterm><Primary>rdev</Primary></Indexterm>
<para>
After carefully calculating the value for the ramdisk word, set it with
<command>rdev -r</command>. Be sure to use the
<emphasis>decimal</emphasis> value. If you used LILO, the argument to
<command>rdev</command> here should be the <emphasis>mounted kernel
path</emphasis>,
e.g. <filename>/mnt/vmlinuz</filename>; if you copied the kernel with
<command>dd</command>, instead
use the floppy device name (<emphasis>e.g.,</emphasis> <filename>/dev/fd0</filename>).
<Screen>
rdev -r KERNEL&lowbar;OR&lowbar;FLOPPY&lowbar;DRIVE VALUE
</Screen>
</Para>
<Para>
If you used LILO, unmount the diskette now.
</Para>
<Important>
<Para>Do not believe what the rdev/ramsize manpage says about ramdisk
size.
The manpage is obsolete. As of kernel 2.0 or so, the ramdisk word no
longer determines the ramdisk size; the word is instead interpreted
according to the table at the beginning of section <xref
linkend="SettingRamdiskWord">. For a detailed
explanation, see the documentation file <Ulink
url="file:/usr/src/linux/Documentation/ramdisk.txt">ramdisk.txt</ULink> or
<ULink
url="http://www.linuxhq.com/kernel/v2.4/doc/ramdisk.txt.html"></ULink>.
</Para>
</Important>
</Sect2>
<Sect2><title>Transferring the root filesystem</title>
<Para>
The last step is to transfer the root filesystem.
</para>
<para>
<itemizedlist>
<listitem>
<para> If the root filesystem will be placed on the
<emphasis>same</emphasis> disk as the kernel, transfer it using
<Command>dd</Command> with the <Option>seek</Option> option, which
specifies how many blocks to skip:
<Screen>
dd if=rootfs.gz of=/dev/fd0 bs=1k seek=<Emphasis>KERNEL&lowbar;BLOCKS</Emphasis>
</Screen>
</para>
</listitem>
<listitem>
<para>
If the root filesystem will be placed on a <emphasis>second</emphasis>
disk, remove the first diskette, put the second diskette in the drive, then
transfer the root filesystem to it:
<Screen>
dd if=rootfs.gz of=/dev/fd0 bs=1k
</Screen>
</para>
</listitem>
</itemizedlist>
</para>
<para>
Congratulations, you are done!
</para>
<Important>
<Para>
You should always test a bootdisk before putting it aside for an emergency.
If it fails to boot, read on.
</Para>
</Important>
</Sect2>
</Sect1>
<Sect1 id="Troubleshooting">
<Title>Troubleshooting, or The Agony of Defeat</title>
<Indexterm><Primary>Troubleshooting</Primary></Indexterm>
<Para>
When building bootdisks, the first few tries often will not boot. The general
approach to building a root disk is to assemble components from your existing
system, and try and get the diskette-based system to the point where it displays
messages on the console. Once it starts talking to you, the battle is half over
because you can see what it is complaining about, and you can fix individual
problems until the system works smoothly. If the system just hangs with no
explanation, finding the cause can be difficult. The recommended procedure for
investigating the problem where the system will not talk to you is as follows:
</para>
<para>
<itemizedlist>
<listitem>
<para>
You may see a message like this:
<Screen>
Kernel panic: VFS: Unable to mount root fs on XX:YY
</Screen>
This is a common problem and it has only a few causes. First, check the device
<emphasis>XX:YY</emphasis> against the list of device codes in
<Filename>/usr/src/linux/Documentation/devices.txt</Filename>. If it is
incorrect, you probably didn't do an <command>rdev -R</command>, 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.
</para>
</listitem>
<listitem>
<para>
If you see many errors like:
<Screen>
end&lowbar;request: I/O error, dev 01:00 (ramdisk), sector NNN
</Screen>
This is an I/O error from the ramdisk driver, usually because the kernel is
trying to write beyond the end of the device. The ramdisk is too small to hold
the root filesystem. Check your bootdisk kernel's initialization messages for a
line like:
<Screen>
Ramdisk driver initialized : 16 ramdisks of 4096K size
</Screen>
Check this size against the <Emphasis>uncompressed</Emphasis> size of
the root filesystem. If the ramdisks aren't large enough, make them
larger.
</para>
</listitem>
<listitem>
<para>
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 <filename>/rootdisk/bin</filename> instead of
<filename>/bin</filename> on your root diskette.
</para>
</listitem>
<listitem>
<para>
Check that there is a <filename>/lib/libc.so</filename> with the same link that
appears in your <filename>/lib</filename> directory on your hard disk.
</para>
</listitem>
<listitem>
<para>
Check that any symbolic links in your <filename>/dev</filename>
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,
<filename>/dev/console</filename> links are essential in many cases.
</para>
<Indexterm><Primary>device (dev) directory</Primary></Indexterm>
</listitem>
<listitem>
<para>
Check that you have included <filename>/dev/tty1, /dev/null, /dev/zero,
/dev/mem, /dev/ram</filename> and <filename>/dev/kmem</filename> files.
</para>
</listitem>
<listitem>
<para>
Check your kernel configuration -- support for all resources
required up to login point must be built in, not modules.
So <emphasis>ramdisk and ext2 support must be built-in</emphasis>.
</para>
</listitem>
<listitem>
<para>
Check that your kernel root device and ramdisk settings are correct.
</para>
</Listitem>
</Itemizedlist>
</Para>
<para>
Once these general aspects have been covered, here are some more
specific files to check:
<orderedlist>
<Listitem>
<Para>
Make sure <command>init</command> is included as
<filename>/sbin/init</filename> or <filename>/bin/init</filename>.
Make sure it is executable.
</Para>
</Listitem>
<Listitem>
<Para>
Run <command>ldd init</command> to check init's libraries. Usually
this is just <filename>libc.so</filename>, but check anyway. Make
sure you included the necessary libraries and loaders.
</Para>
</Listitem>
<listitem>
<para>
Make sure you have the right loader for your libraries --
<filename>ld.so</filename> for a.out or <filename>ld-linux.so</filename>
for ELF.
<Indexterm><Primary>loaders</Primary></Indexterm>
</para>
</listitem>
<listitem>
<para>
Check the <filename>/etc/inittab</filename> on your bootdisk filesystem for
the calls to <command>getty</command> (or some <command>getty</command>-like
program, such as <command>agetty</command>, <command>mgetty</command> or
<command>getty&lowbar;ps</command>). Double-check these against your hard
disk <filename>inittab</filename>. Check the man pages of the program you use
to make sure these make sense. <filename>inittab</filename> 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 <command>init</command> and <filename>inittab</filename> and work
out exactly what your existing system is doing when it boots. Check to make
sure <filename>/etc/inittab</filename> has a system initialisation entry.
This should contain a command to execute the system initialization script,
which must exist.
</para>
</listitem>
<listitem>
<para> As with <command>init</command>, run <command>ldd</command> on your
<Command>getty</Command> to see what it needs, and make sure the necessary
library files and loaders were included in your root filesystem.
</para>
</listitem>
<listitem>
<para>
Be sure you have included a shell program (e.g., <command>bash</command> or
<command>ash</command>)
capable of running all of your rc scripts.
<Indexterm><Primary>shells</Primary></Indexterm>
</para>
</listitem>
<listitem>
<para>
If you have a <filename>/etc/ld.so.cache</filename> file on your rescue disk,
remake it.
</para>
</listitem>
</orderedlist>
</para>
<para>
If <Command>init</Command> starts, but you get a message like:
<Screen width=80>
Id xxx respawning too fast: disabled for 5 minutes
</Screen>
it is coming from <Command>init</Command>, usually indicating that
<Command>getty</Command> or <Command>login</Command> is dying as soon as it
starts up. Check the <command>getty</command> and <command>login</command>
executables and the libraries they depend upon. Make sure the invocations in
<filename>/etc/inittab</filename> are correct. If you get strange messages
from <command>getty</command>, it may mean the calling form in
<filename>/etc/inittab</filename> is wrong.
</para>
<para> 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 <xref linkend="PAMandNSS">. The problem may also be
that you use shadow passwords and didn't copy
<filename>/etc/shadow</filename> to your bootdisk.
</para>
<para> If you try to run some executable, such as <command>df</command>, which
is on your rescue disk but you yields a message like: <literal>df: not
found</literal>, 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. </para>
</sect1>
<sect1 id="Slimfast">
<title>Reducing root filesystem size</title>
<Para>
One of the main problems with building bootdisks is getting everything to fit
into one (or even two) diskettes. Even when files are compressed this can be
very difficult, because Linux system components keep growing. Here are some
common techniques used to make everything fit.
</Para>
<sect2>
<title>Increase the diskette density</title>
<Para>
By default, floppy diskettes are formatted at 1440K, but higher density
formats are possible. Whether you can boot from higher density
disks depends mostly on your BIOS.
<Filename>fdformat</Filename> will format disks for
the following sizes: 1600K, 1680K, 1722K, 1743K, 1760K, 1840K, and 1920K.
See the <Command>fdformat</Command> man page and
<Filename>/usr/src/linux/Documentation/devices.txt</Filename>.
</Para>
<Para> But what diskette densities/geometries will your machine support? Here
are some (lightly edited) answers from Alain Knaff, the author of fdutils.
</Para>
<BlockQuote>
<Para>
This is more an issue of the BIOS rather than the physical format of the disk.
If the BIOS decides that any sector number greater than 18 is bad, then
there is not much we can do. Indeed, short of disassembling the BIOS, trial
and error seems to be the only way to find out. However, if the BIOS supports
ED disks (extra density: 36 sectors/track and 2.88MB), there's a chance that
1722K disks are supported as well.
</Para>
<Para>
Superformatted disks with more than 21 sectors/track are likely not bootable:
indeed, those use sectors of non-standard sizes (1024 bytes in a sector
instead of 512, for example), and are likely not bootable. It should however
be possible to write a special bootsector program to work around this. If I
remember correctly, the DOS 2m utility has such a beast, as does OS/2's XDF
utilities.
</Para>
<Para>
Some BIOSes artificially claim that any sector number greater than 18
must be in error. As 1722K disks use sector numbers up to 21, these
would not be bootable. The best way to test would be to format a test
DOS or syslinus disk as 1722K and make it bootable. If you use LILO,
don't use the option linear (or else LILO would assume that the disk
is the default 18 sectors/track, and the disk will fail to boot even
if supported by the BIOS).
</Para>
</BlockQuote>
</Sect2>
<Sect2>
<Title>Replace common utilities with BusyBox</Title>
<Para> Much root filesystem space is consumed by common GNU system utilities
such as <Literal>cat, chmod, cp, dd, df</Literal>, etc. The
<Emphasis>BusyBox</Emphasis> project was designed to provide minimal
replacements for these common system utilities. BusyBox supplies one single
monolithic executable file, <Literal>/bin/busybox</Literal>, about 150K, which
implements the functions of these utilities. You then create symlinks from
different utilities to this executable; busybox sees how it was called and
invokes the correct code. BusyBox even includes a basic shell.
BusyBox is available in binary packages for many distributions, and source
code is available from <Ulink url="http://www.busybox.net/">the BusyBox
site</Ulink>.
<!-- The above link gets a 404 error, but I feel in my heart it is a correct
URL so I shall not change it. -->
</Para>
</Sect2>
<Sect2>
<Title>Use an alternate shell</Title>
<Para> Some of the popular shells for Linux, such as <Command>bash</Command>
and <Command>tcsh</Command>, are large and require many libraries. If you
don't use the BusyBox shell, you should still consider replacing your shell
anyway. Some light-weight alternatives are <command>ash</command>,
<command>lsh</command>, <command>kiss</command> and <command>smash</command>,
which are much smaller and require few (or no) libraries. Most of these
replacement shells are available from <Ulink
url="http://www.ibiblio.org/pub/Linux/system/shells/"><filename
class="directory">http://www.ibiblio.org/pub/Linux/system/shells/
</filename></ulink>. Make sure any shell you use is capable of running
commands in all the <filename>rc</filename> files you include on your
bootdisk.
<Indexterm><Primary>shells</Primary></Indexterm>
</Para>
</Sect2>
<Sect2>
<Title>Strip libraries and binaries</Title>
<Para> Many libraries and binaries are distributed with debugging information.
Running <command>file</command> on these files will tell you ``<literal>not
stripped</literal>'' if so.
<Indexterm><Primary>libraries</Primary></Indexterm> When copying binaries to
your root filesystem, it is good practice to use: <Screen>
objcopy --strip-all FROM TO
</Screen>
<Indexterm><Primary>libraries</Primary><Secondary>stripping</Secondary></Indexterm>
<Indexterm><Primary><Filename>strip</Filename></Primary></Indexterm>
<Indexterm><Primary><Filename>objcopy</Filename></Primary></Indexterm>
<Important>
<Para>
When copying libraries, be sure to use <Option>strip-debug</Option> instead of
<Option>strip-all</Option>.
</Para>
</Important>
</Para>
</Sect2>
<Sect2>
<Title>Move files to a utility disk</Title>
<Para> If some of your binaries are not needed immediately to boot or login,
you can move them to a utility disk. See <xref linkend="UtilityDisk"> for
details. You may also consider moving modules to a utility disk as well.
<Indexterm><Primary>utility diskette</Primary></Indexterm>
</Para>
</Sect2>
</Sect1>
<Sect1><title>Miscellaneous topics</title>
<sect2 id="NonRamdiskRoot">
<title>Non-ramdisk root filesystems</title>
<Indexterm><Primary>ramdisk</Primary></Indexterm>
<para>
<xref linkend="buildroot"> 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.
</para>
<para>
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 <emphasis>much less space</emphasis> available.
</para>
<para>
<orderedlist>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Using <command>mke2fs</command>, create a root filesystem on a diskette of the
appropriate size.
</para>
</listitem>
<listitem>
<para>
Populate the filesystem as described above.
</para>
</listitem>
<listitem>
<para>
When done, unmount the filesystem and transfer it to a disk file
but <emphasis>do not compress it</emphasis>.
</para>
</listitem>
<listitem>
<para>
Transfer the kernel to a floppy diskette, as described above. When
calculating the ramdisk word, <emphasis>set bit 14 to zero</emphasis>, to indicate that the
root filesystem is not to be loaded to ramdisk. Run the <command>rdev</command>'s as
described.
<Indexterm><Primary>ramdisk word</Primary></Indexterm>
<Indexterm><Primary>rdev</Primary></Indexterm>
</para>
</listitem>
<listitem>
<para>
Transfer the root filesystem as before.
</para>
</listitem>
</orderedlist>
</para>
<para> 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 <emphasis>single</emphasis> filesystem on the entire disk,
containing the kernel, LILO files and root files, and simply run LILO as
the last step.
</para>
</sect2>
<sect2 id="UtilityDisk">
<title>Building a utility disk</title>
<indexterm><primary>utility diskette</primary></indexterm>
<para>
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.
</para>
<para>
In the instructions above, we mentioned that the utility disk could be
mounted as <filename>/usr</filename>. In this case, binaries could be placed into a
<filename>/bin</filename> directory on your utility disk, so that placing
<filename>/usr/bin</filename> in your path will access them. Additional libraries
needed by the binaries are placed in <filename>/lib</filename> on the utility disk.
</para>
<para>
There are several important points to keep in mind when designing a utility
disk:
</para>
<para>
<orderedlist>
<listitem>
<para>
Do not place critical system binaries or libraries onto the utility
disk, since it will not be mountable until after the system has booted.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Access to files on the utility disk will be slow.
</para>
</listitem>
</orderedlist>
</para>
<para><xref linkend="utilitylist"> 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 (<command>format, fdisk</command>) and filesystems
(<command>mke2fs, fsck, debugfs, isofs.o</command>), a lightweight text
editor (<command>elvis, jove</command>), compression and archive utilities
(<command>gzip, bzip, tar, cpio, afio</command>), tape utilities
(<command>mt, ftmt, tob, taper</command>), communications utilities
(<command>ppp.o, slip.o, minicom</command>) and utilities for devices
(<command>setserial, mknod</command>).
</para>
</sect2>
</sect1>
<sect1 id="Pros">
<title>How the pros do it</title>
<para>
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.
</para>
<Indexterm><Primary>initial ramdisk (initrd)</Primary></Indexterm>
<para>
Some bootdisks use a feature called <emphasis>initrd</emphasis>
(<emphasis>initial ramdisk</emphasis>). 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
<command>initrd</command>, see your local file <ulink
url="file:/usr/src/linux/Documentation/initrd.txt"><filename>/usr/src/linux/Documentation/initrd.txt</filename></ulink>
and <ulink
url="ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz"><filename>ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz</filename>
</ulink>
</para>
<para>
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.
</para>
<para> Slackware (v.3.1) uses a straightforward LILO boot similar to what
is described in <xref linkend="TransferringWithLILO">. The
Slackware bootdisk prints a bootup message (&ldquo;<literal>Welcome to the
Slackware Linux bootkernel disk!</literal>&rdquo;) using LILO's
<literal>message</literal> 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 <command>setup</command>
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.
</para>
<para> RedHat (v.4.0) also uses a LILO boot. It loads a compressed ramdisk
on the first disk, which runs a custom <command>init</command> program.
This program queries for drivers then loads additional files from a
supplemental disk if necessary.
</para>
<para> 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 <Literal>initrd</Literal> image to guide the
user through installation. It appears to use both a customized
<command>init</command> and a customized shell.
</para>
</sect1>
<sect1 id="CD-ROMs"><Title>Creating bootable CD-ROMs</Title>
<note>
<para>This section was contributed by Rizwan Mohammed Darwe
(<literal>rizwan AT clovertechnologies dot com</literal>)
</para>
</note>
<para>
This section assumes that you are familiar with the process and workings of
writing CDs in linux. Consider this to be a quick reference to include the
ability to boot the CD which you will burn. The CD-Writing-HOWTO should give you
an in-depth reference.
</para>
<sect2><title>What is El Torito?</title>
<para>
For the x86 platform, many BIOS's have begun to support bootable CDs.
The patches for mkisofs is based on the standard called "El Torito".
Simply put, El Torito is a specification that says how a cdrom should
be formatted such that you can directly boot from it.
</para>
<para> The "El Torito" spec says that <emphasis>any</emphasis> cdrom drive
should work (SCSI or EIDE) as long as the BIOS supports El Torito. So far
this has only been tested with EIDE drives because none of the SCSI
controllers that has been tested so far appears to support El Torito. The
motherboard definately has to support El Torito. How do you know if your
motherboard supports "El Torito"? Well, the ones that support it let you
choose booting from hard disk, Floppy, Network or CDROM. </para>
</Sect2>
<Sect2>
<title>How it Works</title>
<para> The El Torito standard works by making the CD drive appear, through
BIOS calls, to be a normal floppy drive. This way you simply put any floppy
size image (exactly 1440k for a 1.44 meg floppy) somewhere in the ISO
filesystem. In the headers of the ISO fs you place a pointer to this image.
The BIOS will then grab this image from the CD and for all purposes it acts as
if it were booting from the floppy drive. This allows a working LILO boot
disk, for example, to simply be used as is. </para>
<para>Roughly speaking, the first 1.44 (or 2.88 if supported) Mbytes of the
CD-ROM contains a floppy-disk image supplied by you. This image is treated
like a floppy by the BIOS and booted from. (As a consequence, while booting
from this virtual floppy, your original drive A:
(<filename>/dev/fd0</filename>) may not be accessible, but you can try with
<filename>/dev/fd1</filename>). </para>
</Sect2>
<sect2><title>How to make it work</title>
<para>
First create a file, say "boot.img", which is an exact image of the bootable
floppy-disk which you want to boot via the CD-ROM. This must be an 1.44 MB
bootable floppy-disk. The command below will do this
<Screen>
dd if=/dev/fd0 of=boot.img bs=10k count=144
</Screen>
assuming the floppy is in the A: drive.
</para>
<para>
Place this image somewhere in the hierarchy which will be the source
for the iso9660 filesystem. It is a good idea to put all boot related
files in their own directory ("boot/" under the root of the iso9660 fs,
for example).
</para>
<para>
One caveat -- Your boot floppy <emphasis>must</emphasis> load any initial
ramdisk via LILO, not the kernel ramdisk driver! This is because once the
linux kernel starts up, the BIOS emulation of the CD as a floppy disk is
circumvented and will fail. LILO will load the initial ramdisk using BIOS
disk calls, so the emulation works as designed.
</para>
<para>
The El Torito specification requires a "boot catalog" to be created as
well. This is a 2048 byte file which is of no interest except it is required.
The patchwork done by the author of mkisofs will cause it to automatically
create the boot catalog, but you must specify where the boot catalog will go
in the iso9660 filesystem. Usually it is a good idea to put it in the same
place as the boot image, and a name like <filename>boot.catalog</filename>
seems appropriate.
</para>
<para>So we have our boot image in the file <filename>boot.img</filename>,
and we are going to put it in the directory <filename
class="directory">boot/</filename> under the root of the iso9660 filesystem.
We will have the boot catalog go in the same directory with the name
<filename>boot.catalog</filename>. The command to create the iso9660 fs in
the file <filename>bootcd.iso</filename> is then:
<screen>
mkisofs -r -b boot/boot.img -c boot/boot.catalog -o bootcd.iso .
</screen>
The <option>-b</option> option specifies the boot image to be used (note the
path is relative to the root of the iso9660 disk), and the <option>-c</option>
option is for the boot catalog file. The <option>-r</option> option will make
approptiate file ownerships and modes (see the <filename>mkisofs</filename>
manpage). The "." in the end says to take the source from the current
directory. </para>
<para>
Now burn the CD with the usual cdrecord command and it is ready to boot.
</para>
</sect2>
<sect2><title>Create Win9x Bootable CD-Roms</title>
<para>The first step is to get hold of the bootable image used by the source
CD. But you cannot simply mount the CD under linux and dd the first 1440k to
a floppy disk or to a file like <filename>boot.img</filename>. Instead you
simply boot with the source CD-ROM. </para>
<para>When you boot the Win98 CD you are dropped to A: prompt which is the
actual ramdisk. And D: or Z: is where all the installables are residing. By
using the diskcopy command of dos copy the A: image into the actual floppy
drive which is now B: The command below will do this.
<screen>
diskcopy A: B:
</screen>
It works just like dd. You can try booting from this newly created disk to
test if the booting process is similar to that of the source CD. Then the
usual dd of this floppy to a file like boot.img and then rest is as usual.
</para>
</sect2>
</sect1>
<sect1><title>Frequently Asked Question (FAQ) list</title>
<QandAset defaultlabel='qanda'>
<QandAentry>
<Question>
<Para>
<Emphasis>I boot from my boot/root disks and nothing happens. What do I
do?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
See <xref linkend="troubleshooting">, above.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How does the Slackware/Debian/RedHat bootdisk work?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
See <xref linkend="Pros">, above.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I use higher-density (> 1440K) diskettes? How do I figure out
which densities will work with my diskette drive?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
See Section <xref linkend="Slimfast">, above, for the comments by Alain Knaff
on this subject. His is the most authoritative answer I know of.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I increase the size of my ramdisks?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
This probably should be explained better in the text, but I'll put an answer
here for the time being.
</Para>
<Para>
First, <Emphasis>do not</Emphasis> attempt to use the <Literal>rdev</Literal>
or <Literal>ramsize</Literal> commands to do this, no matter what their
documentation says. The ramdisk word no longer determines the size of
ramdisks.
</Para>
<Para>Second, keep in mind that ramdisks are actually dynamic; when you set a
ramdisk size you aren't allocating any memory, you're just setting the limit
of how large it can grow. Don't be afraid to set these fairly large (eg, 8 or
even 16 meg). The RAM space is not actually consumed until you need it.
You can set these limits in one of several ways.
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>Use the <Literal>ramdisk&lowbar;size=NNN</Literal> command line
parameter. You can either enter this manually or use a command like
<Literal>append="ramdisk&lowbar;size=NNN"</Literal> with LILO.</Para>
</ListItem>
<ListItem><Para>If you're using LILO, you can use a kernel option like
<Literal>ramdisk=8192K</Literal> in the <Literal>lilo.conf</Literal> file.
</Para>
</ListItem>
<ListItem><Para>Change the kernel configuration option
<Literal>CONFIG_BLK_DEV_RAM_SIZE</Literal> and recompile your kernel.
</Para>
</ListItem>
</OrderedList>
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I make bootable CD-ROMs?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
See section <Xref linkend="CD-ROMs">.
</para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I make bootable LS-120 disks?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
Since I don't have an LS-120 drive, the following information is summarized
from <ULink URL="http://www.linuxrouter.org/floppy.shtml"> information
provided by Dave Cinege</Ulink> from the Linux Router Project.
</Para>
<Para>
The LS-120 is an IDE floppy drive. It is compatible with both standard 3.5"
disks and the new 120MB disks. As of Linux v2.0.31 there is full support. To
be able to boot from these you must have a BIOS that specifically allows the
LS-120 to be treated as drive 0 (whereas IDE devices normally start at 80).
If you do not have BIOS support, you can purchase a small IDE FloppyMAX card
from Promise Technologies to overcome this deficiency.
</Para>
<Para>
The kernel boot loader does not like the LS-120, and instantly dies. Also 2m
disks do not like it and will not boot. 1.44MB through 1.74MB disks will work
fine. SYSLINUX works with the 120MB disks as of v1.32. You would better off
partitioning the disk and using ext2 or minix, instead of SYSLINUX unless you
need MS-DOS compatibility.
</Para>
<Para>
LILO does work fine with 120MB disks. Here is a sample lilo.conf:
<Screen>
boot=/dev/hda
compact
disk=/dev/hda bios=0
install=/floppy/boot.b
map=/floppy/map
image=/floppy/linux
label=Linux
append="load_ramdisk=1"
initrd=/floppy/root.bin
ramdisk=8192
</Screen>
The line "disk=/dev/hda bios=0" is what does the trick to make it boot the
LS-120.
</para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How can I make a boot disk with a XYZ driver?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
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.
</para>
<para>
Go to the <Filename>a1</Filename> 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.
</para>
<Indexterm><Primary>device drivers</Primary></Indexterm>
<Para> You must then check the root device in the kernel, using the command
<Command>rdev zImage</Command>. If this is not the same as the root device
you want, use <Command>rdev</Command> to change it. For example, the kernel I
tried was set to <Filename>/dev/sda2</Filename>, but my root SCSI partition is
<Filename>/dev/sda8</Filename>. To use a root diskette, you would have to use
the command <Command>rdev zImage /dev/fd0</Command>.
</para>
<para>
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''.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I update my root diskette with new files?</Emphasis>
</Para>
</Question>
<Answer>
<Para>
<Indexterm><Primary>root
filesystems</Primary><Secondary>updating</Secondary></Indexterm>
The easiest way is to copy the filesystem from the rootdisk back to the
<Symbol>DEVICE</Symbol> you used (from <xref linkend="creatingrootfs">, above).
Then mount the filesystem and make the changes. You have to remember where
your root filesystem started and how many blocks it occupied:
<Screen width=80>
dd if=/dev/fd0 bs=1k skip=ROOTBEGIN count=BLOCKS | gunzip &#62; <Symbol>DEVICE</Symbol>
mount -t ext2 <Symbol>DEVICE</Symbol> /mnt
</Screen>
After making the changes, proceed as before (in <xref
linkend="wrappingitup">) 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.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How do I remove LILO so that I can use DOS to boot again?</Emphasis>
</Para>
</Question>
<Indexterm><Primary>Master Boot Record (MBR)</Primary></Indexterm>
<Indexterm><Primary>LILO</Primary><Secondary>removing</Secondary></Indexterm>
<Answer>
<Para>
This is not really a Bootdisk topic, but it is asked often. Within Linux, you
can run:
<Screen width=60>
/sbin/lilo -u
</Screen>
</para>
<para> You can also use the <Command>dd</Command> command to copy the
backup saved by LILO to the boot sector. Refer to the LILO documentation
if you wish to do this.
</para>
<para>
Within DOS and Windows you can use the DOS command:
<Screen width=80>
FDISK /MBR
</Screen>
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.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How can I boot if I've lost my kernel <Emphasis>and</Emphasis>
my boot disk?</Emphasis>
</Para>
</Question>
<Answer>
<Para>
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.
</para>
<para> 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 <Filename>/dev/sda2</Filename>, whereas my root
Linux partition happens to be <Filename>/dev/sda8</Filename>. In this case
the root device in the kernel will have to be changed.
</para>
<para>
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.
</para>
<Para> <Command>rdev</Command> 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:
<Indexterm><Primary>ramdisk word</Primary></Indexterm>
<Indexterm><Primary>rdev</Primary></Indexterm>
<Screen width=80>
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
</Screen>
</Para>
<Para>
The interpretation of the ramdisk word was described in <xref
linkend="SettingRamdiskWord">, above.
</Para>
<Para>
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:
<Screen width=80>
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
</Screen>
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
<Command>rawrite.exe</Command>. 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.
</para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How can I make extra copies of boot/root diskettes?</Emphasis>
</Para>
</Question>
<Answer>
<Para>
Because magnetic media may deteriorate over time, you should keep several
copies of your rescue disk, in case the original is unreadable.
</para>
<para>
The easiest way of making copies of any diskettes, including
bootable and utility diskettes, is to use the <Command>dd</Command> 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
<Command>dd</Command> uses the raw device interface.
</para>
<para>
To copy the original, enter the command:
<Screen width=60>
dd if=<Symbol/DEVICENAME/ of=<Symbol/FILENAME/
</Screen>
where <Symbol/DEVICENAME/ is the device name of the diskette drive and
<Symbol/FILENAME/ is the name of the (hard-disk) output file. Omitting the
<Literal>count</Literal> parameter causes <Command>dd</Command> to copy the
whole diskette (2880 blocks if high-density).
</para>
<para>
To copy the resulting file back to a new diskette, insert the new
diskette and enter the reverse command:
<Screen width=60>
dd if=<Symbol/FILENAME/ of=<Symbol/DEVICENAME/
</Screen>
</Para>
<Para>
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:
<Screen width=60>
dd if=/dev/fd0 of=/dev/fd1
</Screen>
</para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>How can I boot without typing in &ldquo;ahaxxxx=nn,nn,nn&rdquo; every time?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
<Indexterm><Primary>kernel</Primary><Secondary>parameters</Secondary></Indexterm>
Where a disk device cannot be autodetected it is necessary to supply the
kernel with a command device parameter string, such as:
<Screen width=60>
aha152x=0x340,11,3,1
</Screen>
This parameter string can be supplied in several ways using LILO:
<itemizedlist>
<listitem>
<para>
By entering it on the command line every time the system is booted via
LILO. This is boring, though.
</para>
</listitem>
<listitem>
<para>
By using LILO's <Literal>lock</Literal> 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.
</para>
</listitem>
<listitem>
<para>
By using the <Literal>append=</Literal> statement in the LILO config file.
Note that the parameter string must be enclosed in quotes.
</para>
</listitem>
</itemizedlist>
</para>
<para> For example, a sample command line using the above parameter string
would be:
<Screen width=60>
zImage aha152x=0x340,11,3,1 root=/dev/sda1 lock
</Screen>
</Para>
<Para> This would pass the device parameter string through, and also ask
the kernel to set the root device to <Filename>/dev/sda1</Filename> and
save the whole command line and reuse it for all future boots.
</para>
<para>
A sample APPEND statement is:
<Screen width=60>
APPEND = &ldquo;aha152x=0x340,11,3,1&rdquo;
</Screen>
</para>
<Para> Note that the parameter string must <emphasis>not</emphasis> be
enclosed in quotes on the command line, but it <emphasis>must</emphasis> be
enclosed in quotes in the <Literal>APPEND</Literal> statement.
</para>
<para> 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 <Filename>/usr/src/linux</Filename> 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.
</para>
<para>
Readers are strongly urged to read the LILO documentation before
experimenting with LILO installation. Incautious use of the
<literal>BOOT</literal> statement can damage partitions.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>At boot time, I get error &ldquo;<literal>A: cannot execute
B</literal>&rdquo;. Why?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
<Indexterm><Primary>hardcoded locations</Primary></Indexterm>
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 <Command>strings</Command> command and piping the output
through <Command>grep</Command>.
</para>
<para>
Known examples of hardcoding are:
<itemizedlist>
<listitem>
<para>
<Command>shutdown</Command> in some versions has
<filename>/etc/reboot</filename> hardcoded, so <command>reboot</command>
must be placed in the <filename>/etc</filename> directory.
</para>
</listitem>
<listitem>
<para>
<Command>init</Command> has caused problems for at least one person, with the
kernel being unable to find <Command>init</Command>.
</para>
</listitem>
</itemizedlist>
</para>
<para> To fix these problems, either move the programs to the correct
directory, or change configuration files
(e.g. <Filename>inittab</Filename>) 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 <filename>inittab</filename> and
<Filename>/etc/rc.d</Filename> files as they appear on your hard disk.
</Para>
</Answer>
</QandAentry>
<QandAentry>
<Question>
<Para>
<Emphasis>My kernel has ramdisk support, but initializes ramdisks of 0K. Why?
</Emphasis>
</Para>
</Question>
<Answer>
<Para>
Where this occurs, a kernel message like this will appear as the kernel is
booting: <Indexterm><Primary>ramdisk</Primary></Indexterm>
<Screen width=60>
Ramdisk driver initialized : 16 ramdisks of 0K size
</Screen>
</Para>
<Para>
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:
<Screen width=60>
ramdisk= 0
</Screen>
</para>
<para>
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.
</para>
<Para>
Note that if you attempt to use a ramdisk of 0 size, the
behaviour can be unpredictable, and can result in kernel panics.
</Para>
</Answer>
</QandAentry>
</QandAset>
</sect1>
<Appendix>
<Title>Resources and pointers</title>
<para>
When retrieving a package, always get the latest version unless you have
good reasons for not doing so.
</para>
<Sect1 id="PreMade" xreflabel="Appendix A.1">
<Title>Pre-made Bootdisks</title>
<para>
These are sources for distribution bootdisks. <emphasis>Please use one of
the mirror sites to reduce the load on these machines.</emphasis>
<itemizedlist>
<Listitem>
<Para>
<Ulink
url="http://distro.ibiblio.org/pub/Linux/distributions/slackware/bootdsks.144/">Slackware bootdisks</ulink>,
<ulink
url="http://distro.ibiblio.org/pub/Linux/distributions/slackware/rootdsks/">rootdisks</ulink>
and <ulink url="http://www.slackware.com/getslack/">Slackware mirror sites</ulink>
</Para>
</Listitem>
<Listitem>
<Para>
<Ulink
url="ftp://ftp.redhat.com/pub/redhat/linux/current/en/os/i386/images/">RedHat bootdisks</ulink> and <ulink url="http://www.redhat.com/mirrors.html">Red Hat mirror sites</ulink>
</Para>
</Listitem>
<Listitem>
<Para>
<Ulink
url="ftp://ftp.debian.org/debian/dists/stable/main/disks-i386/current/">Debian bootdisks</ulink> and <ulink url="ftp://ftp.debian.org/debian/README.mirrors.html">Debian mirror sites</ulink>
</Para>
</Listitem>
<Listitem>
<Para>
<ulink url="http://www.linux-mandrake.com/en/ftp.php3">Mandrake
downloads</ulink>
</Para>
</Listitem>
</Itemizedlist>
</Para>
<para>
In addition to the distribution bootdisks, the following rescue disk
images are available. Unless otherwise specified, these are available in
the directory
<ulink url="http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html">
<filename>http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html</filename></ulink>
</para>
<para>
<itemizedlist>
<listitem>
<para>
<literal>RIP</literal> is a boot/rescue system which comes in several
versions: one that fits on a 1.44M floppy diskette and one that fits on a
CD-ROM. It has large file support and many utility programs for disk
maintenance and rescue. It has support for ext2, ext3, iso9660, msdos, ntfs,
reiserfs, ufs and vfat. RIP is available from
<Ulink url="http://www.tux.org/pub/people/kent-robotti/looplinux/rip/index.html">http://www.tux.org/pub/people/kent-robotti/looplinux/rip/index.html</Ulink>
</para>
</listitem>
<listitem>
<para>
<literal>tomsrtbt</literal>, 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.
</para>
</listitem>
<listitem>
<para>
<literal>rescue02</literal>, 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.
</para>
</listitem>
<listitem>
<para>
<literal>resque&lowbar;disk-2.0.22</literal>, 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.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.ibiblio.org/pub/Linux/system/recovery/images">
<literal>cramdisk</literal> images</Ulink>, 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.
</para>
</listitem>
</itemizedlist>
</para>
</Sect1>
<Sect1><Title>Rescue packages</title>
<para> Several packages for creating rescue disks are available on
www.ibiblio.org. With these packages you specify a set of files for inclusion
and the software automates (to varying degrees) the creation of a bootdisk.
See <Ulink
url="http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html"><Filename>http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html</Filename></Ulink>
for more information. <Emphasis>Check the file dates carefully</emphasis>.
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, <ulink
url="http://www.linuxlots.com/~fawcett/yard/index.html">Yard</ulink> is the only
package that will.
</para>
</Sect1>
<Sect1>
<Title>LILO -- the Linux loader</title>
<para>
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.
</para>
<para>
Ftp from <Ulink Url="ftp://tsx-11.mit.edu/pub/linux/packages/lilo/">
ftp://tsx-11.mit.edu/pub/linux/packages/lilo/</Ulink>. It is also
available on Metalab and mirrors.
</para>
</Sect1>
<Sect1><Title>Ramdisk usage</title>
<Indexterm><Primary>ramdisk</Primary></Indexterm>
<para>
An excellent description of the how the ramdisk code works may be found
with the documentation supplied with the Linux kernel. See
<filename>/usr/src/linux/Documentation/ramdisk.txt</filename>. It is
written by Paul Gortmaker and includes a section on creating a compressed
ramdisk.
</para>
</Sect1>
<Sect1>
<title>The Linux boot process</title>
<Indexterm><Primary>boot process</Primary></Indexterm>
<para>
For more detail on the Linux boot process, here are some pointers:
<itemizedlist>
<listitem>
<para>
The <ulink url="http://linuxdoc.org/LDP/sag/index.html"><citetitle>Linux
System Administrators' Guide</citetitle></ulink> has a section on booting.
</para>
</listitem>
<listitem>
<para>
The <ulink
url="http://www.ibiblio.org/pub/Linux/system/boot/lilo/lilo-t-21.ps.gz">
LILO ``Technical overview''</ulink> has the definitive technical, low-level
description of the boot process, up to where the kernel is started.
</para>
</listitem>
<listitem> <para> 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 <filename>/usr/src/linux</filename> on your machine;
alternatively, Shigio Yamaguchi (shigio at tamacom.com) has a very nice <ulink
url="http://www.tamacom.com/tour/linux/index.html">hypertext kernel
browser</ulink> for reading kernel source files. Here are some relevant files
to look at:
<Variablelist>
<varlistentry>
<term><filename>arch/i386/boot/bootsect.S</filename> and
<filename>setup.S</filename></term>
<listitem>
<para>
Contain assembly code for the bootsector itself.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>arch/i386/boot/compressed/misc.c</filename></term>
<listitem>
<para>
Contains code for uncompressing the kernel.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>arch/i386/kernel/</filename></term>
<listitem>
<para>
Directory containing kernel initialization code.
<filename>setup.c</filename> defines the ramdisk word.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>drivers/block/rd.c</filename></term>
<listitem>
<para>
Contains the ramdisk driver. The procedures
<command>rd&lowbar;load</command> and <command>
rd&lowbar;load&lowbar;image</command> load blocks from a device into a
ramdisk. The procedure
<command>identify&lowbar;ramdisk&lowbar;image</command> determines what
kind of filesystem is found and whether it is compressed.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</listitem>
</itemizedlist>
</para>
</Sect1>
</Appendix>
<Appendix><title>LILO boot error codes</title>
<Indexterm><Primary>LILO</Primary><Secondary>error codes</Secondary></Indexterm>
<para>
Questions about these codes are asked so often on Usenet that we include
them here as a public service. This summary is excerpted from Werner
Almsberger's <ulink
url="http://www.ibiblio.org/pub/Linux/system/boot/lilo/lilo-u-21.ps.gz">
LILO User Documentation</ulink>.
</para>
<para> When LILO loads itself, it displays the word
<literal>LILO</literal>. 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.
</para>
<InformalTable>
<Tgroup cols=2 align=left>
<Colspec colname=Output align=left colwidth="1in">
<Colspec colname=Descrip align=left>
<Thead>
<Row>
<entry>Output</entry>
<entry>Problem</entry>
</Row>
</Thead>
<Tbody>
<Row>
<entry>(nothing)</entry>
<entry>
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.
</Entry>
</Row>
<Row>
<Entry>L</Entry>
<Entry>
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).
</Entry>
</Row>
<Row>
<Entry>LI</Entry>
<Entry>
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 <Filename>/boot/boot.b
</Filename>
without running the map installer.
</Entry>
</Row>
<Row>
<Entry>LIL</Entry>
<Entry>
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.
</Entry>
</Row>
<Row>
<Entry>LIL?</Entry>
<Entry>
The second stage boot loader has been loaded at an incorrect
address. This is typically caused by a subtle geometry mismatch or
by moving <filename>/boot/boot.b</filename> without running the
map installer.
</Entry>
</Row>
<Row>
<Entry>LIL-</Entry>
<Entry>
The descriptor table is corrupt. This can either be caused by a
geometry mismatch or by moving /boot/map without running the map
installer.
</Entry>
</Row>
<Row>
<Entry>LILO</Entry>
<Entry>
All parts of LILO have been successfully loaded.
</Entry>
</Row>
</Tbody>
</Tgroup>
</InformalTable>
<Para>
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
<literal>0x00</literal> through <literal>0xbb</literal>. See the LILO User
Guide for an explanation of these.
</para>
</Appendix>
<Appendix id="Listings">
<Title>Sample root filesystem listings</title>
<Indexterm><Primary>root filesystem</Primary></Indexterm>
<para>
<screen width="80">
/:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 bin
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 4096 Nov 1 15:39 dev
drwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 1024 Nov 1 15:39 etc
drwx&ndash;&ndash;x&ndash;&ndash;x 4 root root 1024 Nov 1 15:39 lib
drwx&ndash;&ndash;x&ndash;&ndash;x 5 root root 1024 Nov 1 15:39 mnt
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 proc
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 root
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 sbin
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 tmp
drwx&ndash;&ndash;x&ndash;&ndash;x 7 root root 1024 Nov 1 15:39 usr
drwx&ndash;&ndash;x&ndash;&ndash;x 5 root root 1024 Nov 1 15:39 var
/bin:
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 62660 Nov 1 15:39 ash
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 9032 Nov 1 15:39 cat
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 10276 Nov 1 15:39 chmod
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 9592 Nov 1 15:39 chown
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 23124 Nov 1 15:39 cp
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 23028 Nov 1 15:39 date
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 14052 Nov 1 15:39 dd
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 14144 Nov 1 15:39 df
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 69444 Nov 1 15:39 egrep
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 395 Nov 1 15:39 false
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 69444 Nov 1 15:39 fgrep
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 69444 Nov 1 15:39 grep
-rwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 45436 Nov 1 15:39 gunzip
-rwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 45436 Nov 1 15:39 gzip
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 8008 Nov 1 15:39 hostname
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 12736 Nov 1 15:39 ln
-rws&ndash;&ndash;x&ndash;&ndash;x 1 root root 15284 Nov 1 15:39 login
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 29308 Nov 1 15:39 ls
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 8268 Nov 1 15:39 mkdir
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 8920 Nov 1 15:39 mknod
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 24836 Nov 1 15:39 more
-rws&ndash;&ndash;x&ndash;&ndash;x 1 root root 37640 Nov 1 15:39 mount
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 12240 Nov 1 15:39 mt
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 12932 Nov 1 15:39 mv
-r-x&ndash;&ndash;x&ndash;&ndash;x 1 root root 12324 Nov 1 15:39 ps
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 5388 Nov 1 15:39 pwd
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 10092 Nov 1 15:39 rm
lrwxrwxrwx 1 root root 3 Nov 1 15:39 sh -> ash
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 25296 Nov 1 15:39 stty
-rws&ndash;&ndash;x&ndash;&ndash;x 1 root root 12648 Nov 1 15:39 su
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 4444 Nov 1 15:39 sync
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 19712 Nov 1 15:39 touch
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 395 Nov 1 15:39 true
-rws&ndash;&ndash;x&ndash;&ndash;x 1 root root 19084 Nov 1 15:39 umount
-rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 5368 Nov 1 15:39 uname
-rwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 45436 Nov 1 15:39 zcat
/dev:
lrwxrwxrwx 1 root root 6 Nov 1 15:39 cdrom -> cdu31a
brw&ndash;rw&ndash;r&ndash;&ndash; 1 root root 15, 0 May 5 1998 cdu31a
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 0 Nov 1 15:29 console
crw&ndash;rw&ndash;rw&ndash; 1 root uucp 5, 64 Sep 9 19:46 cua0
crw&ndash;rw&ndash;rw&ndash; 1 root uucp 5, 65 May 5 1998 cua1
crw&ndash;rw&ndash;rw&ndash; 1 root uucp 5, 66 May 5 1998 cua2
crw&ndash;rw&ndash;rw&ndash; 1 root uucp 5, 67 May 5 1998 cua3
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 0 Aug 8 13:54 fd0
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 36 Aug 8 13:54 fd0CompaQ
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 84 Aug 8 13:55 fd0D1040
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 88 Aug 8 13:55 fd0D1120
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 12 Aug 8 13:54 fd0D360
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 16 Aug 8 13:54 fd0D720
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 120 Aug 8 13:55 fd0D800
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 32 Aug 8 13:54 fd0E2880
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 104 Aug 8 13:55 fd0E3200
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 108 Aug 8 13:55 fd0E3520
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 112 Aug 8 13:55 fd0E3840
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 28 Aug 8 13:54 fd0H1440
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 124 Aug 8 13:55 fd0H1600
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 44 Aug 8 13:55 fd0H1680
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 60 Aug 8 13:55 fd0H1722
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 76 Aug 8 13:55 fd0H1743
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 96 Aug 8 13:55 fd0H1760
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 116 Aug 8 13:55 fd0H1840
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 100 Aug 8 13:55 fd0H1920
lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H360 &ndash;> fd0D360
lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H720 &ndash;> fd0D720
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 52 Aug 8 13:55 fd0H820
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 68 Aug 8 13:55 fd0H830
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 4 Aug 8 13:54 fd0d360
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 8 Aug 8 13:54 fd0h1200
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 40 Aug 8 13:54 fd0h1440
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 56 Aug 8 13:55 fd0h1476
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 72 Aug 8 13:55 fd0h1494
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 92 Aug 8 13:55 fd0h1600
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 20 Aug 8 13:54 fd0h360
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 48 Aug 8 13:55 fd0h410
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 64 Aug 8 13:55 fd0h420
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 24 Aug 8 13:54 fd0h720
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root floppy 2, 80 Aug 8 13:55 fd0h880
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 0 May 5 1998 hda
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 1 May 5 1998 hda1
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 2 May 5 1998 hda2
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 3 May 5 1998 hda3
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 4 May 5 1998 hda4
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 5 May 5 1998 hda5
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 6 May 5 1998 hda6
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 64 May 5 1998 hdb
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 65 May 5 1998 hdb1
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 66 May 5 1998 hdb2
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 67 May 5 1998 hdb3
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 68 May 5 1998 hdb4
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 69 May 5 1998 hdb5
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 3, 70 May 5 1998 hdb6
crw&ndash;r&ndash;&ndash;&ndash;&ndash;&ndash; 1 root kmem 1, 2 May 5 1998 kmem
crw&ndash;r&ndash;&ndash;&ndash;&ndash;&ndash; 1 root kmem 1, 1 May 5 1998 mem
lrwxrwxrwx 1 root root 12 Nov 1 15:39 modem &ndash;> ttyS1
lrwxrwxrwx 1 root root 12 Nov 1 15:39 mouse &ndash;> psaux
crw&ndash;rw&ndash;rw&ndash; 1 root root 1, 3 May 5 1998 null
crwxrwxrwx 1 root root 10, 1 Oct 5 20:22 psaux
brw&ndash;r&ndash;&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 1 May 5 1998 ram
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 0 May 5 1998 ram0
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 1 May 5 1998 ram1
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 2 May 5 1998 ram2
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 3 May 5 1998 ram3
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 4 May 5 1998 ram4
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 5 May 5 1998 ram5
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 6 May 5 1998 ram6
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 7 May 5 1998 ram7
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 8 May 5 1998 ram8
brw&ndash;rw&ndash;&ndash;&ndash;&ndash; 1 root disk 1, 9 May 5 1998 ram9
lrwxrwxrwx 1 root root 4 Nov 1 15:39 ramdisk &ndash;> ram0
<Emphasis role='bold'>
*** I have only included devices for the IDE partitions I use.
*** If you use SCSI, then use the /dev/sdXX devices instead.
</Emphasis>
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 0 May 5 1998 tty0
crw&ndash;w&ndash;&ndash;&ndash;&ndash;&ndash; 1 root tty 4, 1 Nov 1 15:39 tty1
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 2 Nov 1 15:29 tty2
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 3 Nov 1 15:29 tty3
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 4 Nov 1 15:29 tty4
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 5 Nov 1 15:29 tty5
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 6 Nov 1 15:29 tty6
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4, 7 May 5 1998 tty7
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root tty 4, 8 May 5 1998 tty8
crw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root tty 4, 9 May 8 12:57 tty9
crw&ndash;rw&ndash;rw&ndash; 1 root root 4, 65 Nov 1 12:17 ttyS1
crw&ndash;rw&ndash;rw&ndash; 1 root root 1, 5 May 5 1998 zero
/etc:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 164 Nov 1 15:39 conf.modules
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 668 Nov 1 15:39 fstab
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 71 Nov 1 15:39 gettydefs
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 389 Nov 1 15:39 group
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 413 Nov 1 15:39 inittab
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 65 Nov 1 15:39 issue
&ndash;rw&ndash;r&ndash;&ndash;r&ndash;&ndash; 1 root root 746 Nov 1 15:39 ld.so.cache
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 32 Nov 1 15:39 motd
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 949 Nov 1 15:39 nsswitch.conf
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 pam.d
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 139 Nov 1 15:39 passwd
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 516 Nov 1 15:39 profile
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 387 Nov 1 15:39 rc
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 55 Nov 1 15:39 shells
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 774 Nov 1 15:39 termcap
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 78 Nov 1 15:39 ttytype
lrwxrwxrwx 1 root root 15 Nov 1 15:39 utmp &ndash;> ../var/run/utmp
lrwxrwxrwx 1 root root 15 Nov 1 15:39 wtmp &ndash;> ../var/log/wtmp
/etc/pam.d:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 356 Nov 1 15:39 other
/lib:
&ndash;rwxr&ndash;xr&ndash;x 1 root root 45415 Nov 1 15:39 ld&ndash;2.0.7.so
lrwxrwxrwx 1 root root 11 Nov 1 15:39 ld&ndash;linux.so.2 &ndash;&#62; ld&ndash;2.0.7.so
&ndash;rwxr&ndash;xr&ndash;x 1 root root 731548 Nov 1 15:39 libc&ndash;2.0.7.so
lrwxrwxrwx 1 root root 13 Nov 1 15:39 libc.so.6 &ndash;&#62; libc&ndash;2.0.7.so
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcom&lowbar;err.so.2 &ndash;&#62; libcom&lowbar;err.so.2.0
&ndash;rwxr&ndash;xr&ndash;x 1 root root 6209 Nov 1 15:39 libcom&lowbar;err.so.2.0
&ndash;rwxr&ndash;xr&ndash;x 1 root root 153881 Nov 1 15:39 libcrypt&ndash;2.0.7.so
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcrypt.so.1 &ndash;&#62; libcrypt&ndash;2.0.7.so
&ndash;rwxr&ndash;xr&ndash;x 1 root root 12962 Nov 1 15:39 libdl&ndash;2.0.7.so
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libdl.so.2 &ndash;&#62; libdl&ndash;2.0.7.so
lrwxrwxrwx 1 root root 16 Nov 1 15:39 libext2fs.so.2 &ndash;&#62; libext2fs.so.2.4
&ndash;rwxr&ndash;xr&ndash;x 1 root root 81382 Nov 1 15:39 libext2fs.so.2.4
&ndash;rwxr&ndash;xr&ndash;x 1 root root 25222 Nov 1 15:39 libnsl&ndash;2.0.7.so
lrwxrwxrwx 1 root root 15 Nov 1 15:39 libnsl.so.1 &ndash;&#62; libnsl&ndash;2.0.7.so
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 178336 Nov 1 15:39 libnss&lowbar;files&ndash;2.0.7.so
lrwxrwxrwx 1 root root 21 Nov 1 15:39 libnss&lowbar;files.so.1 &ndash;&#62; libnss&lowbar;files&ndash;2.0.7.so
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libpam.so.0 &ndash;&#62; libpam.so.0.64
&ndash;rwxr&ndash;xr&ndash;x 1 root root 26906 Nov 1 15:39 libpam.so.0.64
lrwxrwxrwx 1 root root 19 Nov 1 15:39 libpam&lowbar;misc.so.0 &ndash;&#62; libpam&lowbar;misc.so.0.64
&ndash;rwxr&ndash;xr&ndash;x 1 root root 7086 Nov 1 15:39 libpam&lowbar;misc.so.0.64
&ndash;r&ndash;xr&ndash;xr&ndash;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 &ndash;&#62; libpwdb.so.0.54
&ndash;rw&ndash;r&ndash;r&ndash;&ndash;&ndash; 1 root root 121899 Nov 1 15:39 libpwdb.so.0.54
lrwxrwxrwx 1 root root 19 Nov 1 15:39 libtermcap.so.2 &ndash;&#62; libtermcap.so.2.0.8
&ndash;rwxr&ndash;xr&ndash;x 1 root root 12041 Nov 1 15:39 libtermcap.so.2.0.8
&ndash;rwxr&ndash;xr&ndash;x 1 root root 12874 Nov 1 15:39 libutil&ndash;2.0.7.so
lrwxrwxrwx 1 root root 16 Nov 1 15:39 libutil.so.1 &ndash;&#62; libutil&ndash;2.0.7.so
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libuuid.so.1 &ndash;&#62; libuuid.so.1.1
&ndash;rwxr&ndash;xr&ndash;x 1 root root 8039 Nov 1 15:39 libuuid.so.1.1
drwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 1024 Nov 1 15:39 modules
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 security
/lib/modules:
drwx&ndash;&ndash;x&ndash;&ndash;x 4 root root 1024 Nov 1 15:39 2.0.35
/lib/modules/2.0.35:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 block
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 cdrom
/lib/modules/2.0.35/block:
drwx&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 7156 Nov 1 15:39 loop.o
/lib/modules/2.0.35/cdrom:
drwx&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 24108 Nov 1 15:39 cdu31a.o
/lib/security:
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 8771 Nov 1 15:39 pam&lowbar;permit.so
<Emphasis role='bold'>
*** Directory stubs for mounting
</Emphasis>
/mnt:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 cdrom
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 floppy
/proc:
/root:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 176 Nov 1 15:39 .bashrc
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 182 Nov 1 15:39 .cshrc
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 455 Nov 1 15:39 .profile
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 4014 Nov 1 15:39 .tcshrc
/sbin:
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 23976 Nov 1 15:39 depmod
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 274600 Nov 1 15:39 e2fsck
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 41268 Nov 1 15:39 fdisk
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 9396 Nov 1 15:39 fsck
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 274600 Nov 1 15:39 fsck.ext2
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 29556 Nov 1 15:39 getty
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 6620 Nov 1 15:39 halt
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 23116 Nov 1 15:39 init
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 25612 Nov 1 15:39 insmod
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 10368 Nov 1 15:39 kerneld
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 110400 Nov 1 15:39 ldconfig
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 6108 Nov 1 15:39 lsmod
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 17400 Nov 1 15:39 mke2fs
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 4072 Nov 1 15:39 mkfs
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 17400 Nov 1 15:39 mkfs.ext2
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 5664 Nov 1 15:39 mkswap
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 22032 Nov 1 15:39 modprobe
lrwxrwxrwx 1 root root 4 Nov 1 15:39 reboot &ndash;&#62; halt
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 7492 Nov 1 15:39 rmmod
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 12932 Nov 1 15:39 shutdown
lrwxrwxrwx 1 root root 6 Nov 1 15:39 swapoff &ndash;&#62; swapon
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 5124 Nov 1 15:39 swapon
lrwxrwxrwx 1 root root 4 Nov 1 15:39 telinit &ndash;&#62; init
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 6944 Nov 1 15:39 update
/tmp:
/usr:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 bin
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 lib
drwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 1024 Nov 1 15:39 man
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 sbin
drwx&ndash;&ndash;x&ndash;&ndash;x 3 root root 1024 Nov 1 15:39 share
lrwxrwxrwx 1 root root 10 Nov 1 15:39 tmp &ndash;> ../var/tmp
/usr/bin:
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 37164 Nov 1 15:39 afio
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 5044 Nov 1 15:39 chroot
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 10656 Nov 1 15:39 cut
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 63652 Nov 1 15:39 diff
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 12972 Nov 1 15:39 du
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 56552 Nov 1 15:39 find
&ndash;r&ndash;x&ndash;&ndash;x&ndash;&ndash;x 1 root root 6280 Nov 1 15:39 free
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 7680 Nov 1 15:39 head
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 8504 Nov 1 15:39 id
&ndash;r&ndash;sr&ndash;xr&ndash;x 1 root bin 4200 Nov 1 15:39 passwd
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 14856 Nov 1 15:39 tail
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 19008 Nov 1 15:39 tr
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 7160 Nov 1 15:39 wc
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 4412 Nov 1 15:39 whoami
/usr/lib:
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libncurses.so.4 &ndash;> libncurses.so.4.2
&ndash;rw&ndash;r&ndash;r&ndash;&ndash;&ndash; 1 root root 260474 Nov 1 15:39 libncurses.so.4.2
/usr/sbin:
&ndash;r&ndash;x&ndash;&ndash;x&ndash;&ndash;x 1 root root 13684 Nov 1 15:39 fuser
&ndash;rwx&ndash;&ndash;x&ndash;&ndash;x 1 root root 3876 Nov 1 15:39 mklost+found
/usr/share:
drwx&ndash;&ndash;x&ndash;&ndash;x 4 root root 1024 Nov 1 15:39 terminfo
/usr/share/terminfo:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 l
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 v
/usr/share/terminfo/l:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 1552 Nov 1 15:39 linux
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 1516 Nov 1 15:39 linux&ndash;m
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 1583 Nov 1 15:39 linux&ndash;nic
/usr/share/terminfo/v:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 2 root root 1143 Nov 1 15:39 vt100
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 2 root root 1143 Nov 1 15:39 vt100&ndash;am
/var:
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 log
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 run
drwx&ndash;&ndash;x&ndash;&ndash;x 2 root root 1024 Nov 1 15:39 tmp
/var/log:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 0 Nov 1 15:39 wtmp
/var/run:
&ndash;rw&ndash;&ndash;&ndash;&ndash;&ndash;&ndash;&ndash; 1 root root 0 Nov 1 15:39 utmp
/var/tmp:
</screen>
</para>
</Appendix>
<Appendix id="UtilityList">
<Title>Sample utility disk directory listing</title>
<Indexterm><Primary>utility diskette</Primary></Indexterm>
<para>
<screen width="80">
total 579
&ndash;rwxr&ndash;xr&ndash;x 1 root root 42333 Jul 28 19:05 cpio
&ndash;rwxr&ndash;xr&ndash;x 1 root root 32844 Aug 28 19:50 debugfs
&ndash;rwxr&ndash;xr&ndash;x 1 root root 103560 Jul 29 21:31 elvis
&ndash;rwxr&ndash;xr&ndash;x 1 root root 29536 Jul 28 19:04 fdisk
&ndash;rw&ndash;r&ndash;r&ndash;&ndash;&ndash; 1 root root 128254 Jul 28 19:03 ftape.o
&ndash;rwxr&ndash;xr&ndash;x 1 root root 17564 Jul 25 03:21 ftmt
&ndash;rwxr&ndash;xr&ndash;x 1 root root 64161 Jul 29 20:47 grep
&ndash;rwxr&ndash;xr&ndash;x 1 root root 45309 Jul 29 20:48 gzip
&ndash;rwxr&ndash;xr&ndash;x 1 root root 23560 Jul 28 19:04 insmod
&ndash;rwxr&ndash;xr&ndash;x 1 root root 118 Jul 28 19:04 lsmod
lrwxrwxrwx 1 root root 5 Jul 28 19:04 mt &ndash;&#62; mt&ndash;st
&ndash;rwxr&ndash;xr&ndash;x 1 root root 9573 Jul 28 19:03 mt&ndash;st
lrwxrwxrwx 1 root root 6 Jul 28 19:05 rmmod &ndash;&#62; insmod
&ndash;rwxr&ndash;xr&ndash;x 1 root root 104085 Jul 28 19:05 tar
lrwxrwxrwx 1 root root 5 Jul 29 21:35 vi &ndash;&#62; elvis
</Screen>
</Para>
</Appendix>
</Article>
View Git Blame Copy Permalink