mirror of https://github.com/tLDP/LDP
3897 lines
140 KiB
Plaintext
3897 lines
140 KiB
Plaintext
|
|
<!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 © 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 © 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 — often when booting from a diskette
|
|
— 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 — 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 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 — 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> — 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 => /lib/libext2fs.so.2 (0x40014000)
|
|
libcom_err.so.2 => /lib/libcom_err.so.2 (0x40026000)
|
|
libuuid.so.1 => /lib/libuuid.so.1 (0x40028000)
|
|
libc.so.6 => /lib/libc.so.6 (0x4002c000)
|
|
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
|
|
</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_permit.so
|
|
OTHER account optional /lib/security/pam_permit.so
|
|
OTHER password optional /lib/security/pam_permit.so
|
|
OTHER session optional /lib/security/pam_permit.so
|
|
</Programlisting>
|
|
|
|
Also copy the file <filename>/lib/security/pam_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_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_</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/{log,run}
|
|
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_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_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/{boot,dev}
|
|
</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 –rw–r––r–– 1 root root 176 Jan 10 07:22 bdlilo.conf
|
|
1 drwxr–xr–x 2 root root 1024 Jan 10 07:23 boot/
|
|
1 drwxr–xr–x 2 root root 1024 Jan 10 07:22 dev/
|
|
358 –rw–r––r–– 1 root root 362707 Jan 10 07:23 vmlinuz
|
|
boot:
|
|
total 8
|
|
4 –rw–r––r–– 1 root root 3708 Jan 10 07:22 boot.b
|
|
4 –rw––––––– 1 root root 3584 Jan 10 07:23 map
|
|
dev:
|
|
total 0
|
|
0 brw–r––––– 1 root root 2, 0 Jan 10 07:22 fd0
|
|
0 crw–r––r–– 1 root root 1, 3 Jan 10 07:22 null
|
|
</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_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_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ˆ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ˆ14 + 2ˆ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_OR_FLOPPY_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_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_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_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 (“<literal>Welcome to the
|
|
Slackware Linux bootkernel disk!</literal>”) 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_size=NNN</Literal> command line
|
|
parameter. You can either enter this manually or use a command like
|
|
<Literal>append="ramdisk_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 > <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 “ahaxxxx=nn,nn,nn” 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 = “aha152x=0x340,11,3,1”
|
|
</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 “<literal>A: cannot execute
|
|
B</literal>”. 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_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_load</command> and <command>
|
|
rd_load_image</command> load blocks from a device into a
|
|
ramdisk. The procedure
|
|
<command>identify_ramdisk_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––x––x 2 root root 1024 Nov 1 15:39 bin
|
|
drwx––x––x 2 root root 4096 Nov 1 15:39 dev
|
|
drwx––x––x 3 root root 1024 Nov 1 15:39 etc
|
|
drwx––x––x 4 root root 1024 Nov 1 15:39 lib
|
|
drwx––x––x 5 root root 1024 Nov 1 15:39 mnt
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 proc
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 root
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 sbin
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 tmp
|
|
drwx––x––x 7 root root 1024 Nov 1 15:39 usr
|
|
drwx––x––x 5 root root 1024 Nov 1 15:39 var
|
|
|
|
/bin:
|
|
-rwx––x––x 1 root root 62660 Nov 1 15:39 ash
|
|
-rwx––x––x 1 root root 9032 Nov 1 15:39 cat
|
|
-rwx––x––x 1 root root 10276 Nov 1 15:39 chmod
|
|
-rwx––x––x 1 root root 9592 Nov 1 15:39 chown
|
|
-rwx––x––x 1 root root 23124 Nov 1 15:39 cp
|
|
-rwx––x––x 1 root root 23028 Nov 1 15:39 date
|
|
-rwx––x––x 1 root root 14052 Nov 1 15:39 dd
|
|
-rwx––x––x 1 root root 14144 Nov 1 15:39 df
|
|
-rwx––x––x 1 root root 69444 Nov 1 15:39 egrep
|
|
-rwx––x––x 1 root root 395 Nov 1 15:39 false
|
|
-rwx––x––x 1 root root 69444 Nov 1 15:39 fgrep
|
|
-rwx––x––x 1 root root 69444 Nov 1 15:39 grep
|
|
-rwx––x––x 3 root root 45436 Nov 1 15:39 gunzip
|
|
-rwx––x––x 3 root root 45436 Nov 1 15:39 gzip
|
|
-rwx––x––x 1 root root 8008 Nov 1 15:39 hostname
|
|
-rwx––x––x 1 root root 12736 Nov 1 15:39 ln
|
|
-rws––x––x 1 root root 15284 Nov 1 15:39 login
|
|
-rwx––x––x 1 root root 29308 Nov 1 15:39 ls
|
|
-rwx––x––x 1 root root 8268 Nov 1 15:39 mkdir
|
|
-rwx––x––x 1 root root 8920 Nov 1 15:39 mknod
|
|
-rwx––x––x 1 root root 24836 Nov 1 15:39 more
|
|
-rws––x––x 1 root root 37640 Nov 1 15:39 mount
|
|
-rwx––x––x 1 root root 12240 Nov 1 15:39 mt
|
|
-rwx––x––x 1 root root 12932 Nov 1 15:39 mv
|
|
-r-x––x––x 1 root root 12324 Nov 1 15:39 ps
|
|
-rwx––x––x 1 root root 5388 Nov 1 15:39 pwd
|
|
-rwx––x––x 1 root root 10092 Nov 1 15:39 rm
|
|
lrwxrwxrwx 1 root root 3 Nov 1 15:39 sh -> ash
|
|
-rwx––x––x 1 root root 25296 Nov 1 15:39 stty
|
|
-rws––x––x 1 root root 12648 Nov 1 15:39 su
|
|
-rwx––x––x 1 root root 4444 Nov 1 15:39 sync
|
|
-rwx––x––x 1 root root 19712 Nov 1 15:39 touch
|
|
-rwx––x––x 1 root root 395 Nov 1 15:39 true
|
|
-rws––x––x 1 root root 19084 Nov 1 15:39 umount
|
|
-rwx––x––x 1 root root 5368 Nov 1 15:39 uname
|
|
-rwx––x––x 3 root root 45436 Nov 1 15:39 zcat
|
|
|
|
/dev:
|
|
lrwxrwxrwx 1 root root 6 Nov 1 15:39 cdrom -> cdu31a
|
|
brw–rw–r–– 1 root root 15, 0 May 5 1998 cdu31a
|
|
crw––––––– 1 root root 4, 0 Nov 1 15:29 console
|
|
crw–rw–rw– 1 root uucp 5, 64 Sep 9 19:46 cua0
|
|
crw–rw–rw– 1 root uucp 5, 65 May 5 1998 cua1
|
|
crw–rw–rw– 1 root uucp 5, 66 May 5 1998 cua2
|
|
crw–rw–rw– 1 root uucp 5, 67 May 5 1998 cua3
|
|
brw–rw–––– 1 root floppy 2, 0 Aug 8 13:54 fd0
|
|
brw–rw–––– 1 root floppy 2, 36 Aug 8 13:54 fd0CompaQ
|
|
brw–rw–––– 1 root floppy 2, 84 Aug 8 13:55 fd0D1040
|
|
brw–rw–––– 1 root floppy 2, 88 Aug 8 13:55 fd0D1120
|
|
brw–rw–––– 1 root floppy 2, 12 Aug 8 13:54 fd0D360
|
|
brw–rw–––– 1 root floppy 2, 16 Aug 8 13:54 fd0D720
|
|
brw–rw–––– 1 root floppy 2, 120 Aug 8 13:55 fd0D800
|
|
brw–rw–––– 1 root floppy 2, 32 Aug 8 13:54 fd0E2880
|
|
brw–rw–––– 1 root floppy 2, 104 Aug 8 13:55 fd0E3200
|
|
brw–rw–––– 1 root floppy 2, 108 Aug 8 13:55 fd0E3520
|
|
brw–rw–––– 1 root floppy 2, 112 Aug 8 13:55 fd0E3840
|
|
brw–rw–––– 1 root floppy 2, 28 Aug 8 13:54 fd0H1440
|
|
brw–rw–––– 1 root floppy 2, 124 Aug 8 13:55 fd0H1600
|
|
brw–rw–––– 1 root floppy 2, 44 Aug 8 13:55 fd0H1680
|
|
brw–rw–––– 1 root floppy 2, 60 Aug 8 13:55 fd0H1722
|
|
brw–rw–––– 1 root floppy 2, 76 Aug 8 13:55 fd0H1743
|
|
brw–rw–––– 1 root floppy 2, 96 Aug 8 13:55 fd0H1760
|
|
brw–rw–––– 1 root floppy 2, 116 Aug 8 13:55 fd0H1840
|
|
brw–rw–––– 1 root floppy 2, 100 Aug 8 13:55 fd0H1920
|
|
lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H360 –> fd0D360
|
|
lrwxrwxrwx 1 root root 7 Nov 1 15:39 fd0H720 –> fd0D720
|
|
brw–rw–––– 1 root floppy 2, 52 Aug 8 13:55 fd0H820
|
|
brw–rw–––– 1 root floppy 2, 68 Aug 8 13:55 fd0H830
|
|
brw–rw–––– 1 root floppy 2, 4 Aug 8 13:54 fd0d360
|
|
brw–rw–––– 1 root floppy 2, 8 Aug 8 13:54 fd0h1200
|
|
brw–rw–––– 1 root floppy 2, 40 Aug 8 13:54 fd0h1440
|
|
brw–rw–––– 1 root floppy 2, 56 Aug 8 13:55 fd0h1476
|
|
brw–rw–––– 1 root floppy 2, 72 Aug 8 13:55 fd0h1494
|
|
brw–rw–––– 1 root floppy 2, 92 Aug 8 13:55 fd0h1600
|
|
brw–rw–––– 1 root floppy 2, 20 Aug 8 13:54 fd0h360
|
|
brw–rw–––– 1 root floppy 2, 48 Aug 8 13:55 fd0h410
|
|
brw–rw–––– 1 root floppy 2, 64 Aug 8 13:55 fd0h420
|
|
brw–rw–––– 1 root floppy 2, 24 Aug 8 13:54 fd0h720
|
|
brw–rw–––– 1 root floppy 2, 80 Aug 8 13:55 fd0h880
|
|
brw–rw–––– 1 root disk 3, 0 May 5 1998 hda
|
|
brw–rw–––– 1 root disk 3, 1 May 5 1998 hda1
|
|
brw–rw–––– 1 root disk 3, 2 May 5 1998 hda2
|
|
brw–rw–––– 1 root disk 3, 3 May 5 1998 hda3
|
|
brw–rw–––– 1 root disk 3, 4 May 5 1998 hda4
|
|
brw–rw–––– 1 root disk 3, 5 May 5 1998 hda5
|
|
brw–rw–––– 1 root disk 3, 6 May 5 1998 hda6
|
|
brw–rw–––– 1 root disk 3, 64 May 5 1998 hdb
|
|
brw–rw–––– 1 root disk 3, 65 May 5 1998 hdb1
|
|
brw–rw–––– 1 root disk 3, 66 May 5 1998 hdb2
|
|
brw–rw–––– 1 root disk 3, 67 May 5 1998 hdb3
|
|
brw–rw–––– 1 root disk 3, 68 May 5 1998 hdb4
|
|
brw–rw–––– 1 root disk 3, 69 May 5 1998 hdb5
|
|
brw–rw–––– 1 root disk 3, 70 May 5 1998 hdb6
|
|
crw–r––––– 1 root kmem 1, 2 May 5 1998 kmem
|
|
crw–r––––– 1 root kmem 1, 1 May 5 1998 mem
|
|
lrwxrwxrwx 1 root root 12 Nov 1 15:39 modem –> ttyS1
|
|
lrwxrwxrwx 1 root root 12 Nov 1 15:39 mouse –> psaux
|
|
crw–rw–rw– 1 root root 1, 3 May 5 1998 null
|
|
crwxrwxrwx 1 root root 10, 1 Oct 5 20:22 psaux
|
|
brw–r––––– 1 root disk 1, 1 May 5 1998 ram
|
|
brw–rw–––– 1 root disk 1, 0 May 5 1998 ram0
|
|
brw–rw–––– 1 root disk 1, 1 May 5 1998 ram1
|
|
brw–rw–––– 1 root disk 1, 2 May 5 1998 ram2
|
|
brw–rw–––– 1 root disk 1, 3 May 5 1998 ram3
|
|
brw–rw–––– 1 root disk 1, 4 May 5 1998 ram4
|
|
brw–rw–––– 1 root disk 1, 5 May 5 1998 ram5
|
|
brw–rw–––– 1 root disk 1, 6 May 5 1998 ram6
|
|
brw–rw–––– 1 root disk 1, 7 May 5 1998 ram7
|
|
brw–rw–––– 1 root disk 1, 8 May 5 1998 ram8
|
|
brw–rw–––– 1 root disk 1, 9 May 5 1998 ram9
|
|
lrwxrwxrwx 1 root root 4 Nov 1 15:39 ramdisk –> ram0
|
|
<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––––––– 1 root root 4, 0 May 5 1998 tty0
|
|
crw–w––––– 1 root tty 4, 1 Nov 1 15:39 tty1
|
|
crw––––––– 1 root root 4, 2 Nov 1 15:29 tty2
|
|
crw––––––– 1 root root 4, 3 Nov 1 15:29 tty3
|
|
crw––––––– 1 root root 4, 4 Nov 1 15:29 tty4
|
|
crw––––––– 1 root root 4, 5 Nov 1 15:29 tty5
|
|
crw––––––– 1 root root 4, 6 Nov 1 15:29 tty6
|
|
crw––––––– 1 root root 4, 7 May 5 1998 tty7
|
|
crw––––––– 1 root tty 4, 8 May 5 1998 tty8
|
|
crw––––––– 1 root tty 4, 9 May 8 12:57 tty9
|
|
crw–rw–rw– 1 root root 4, 65 Nov 1 12:17 ttyS1
|
|
crw–rw–rw– 1 root root 1, 5 May 5 1998 zero
|
|
|
|
/etc:
|
|
–rw––––––– 1 root root 164 Nov 1 15:39 conf.modules
|
|
–rw––––––– 1 root root 668 Nov 1 15:39 fstab
|
|
–rw––––––– 1 root root 71 Nov 1 15:39 gettydefs
|
|
–rw––––––– 1 root root 389 Nov 1 15:39 group
|
|
–rw––––––– 1 root root 413 Nov 1 15:39 inittab
|
|
–rw––––––– 1 root root 65 Nov 1 15:39 issue
|
|
–rw–r––r–– 1 root root 746 Nov 1 15:39 ld.so.cache
|
|
–rw––––––– 1 root root 32 Nov 1 15:39 motd
|
|
–rw––––––– 1 root root 949 Nov 1 15:39 nsswitch.conf
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 pam.d
|
|
–rw––––––– 1 root root 139 Nov 1 15:39 passwd
|
|
–rw––––––– 1 root root 516 Nov 1 15:39 profile
|
|
–rwx––x––x 1 root root 387 Nov 1 15:39 rc
|
|
–rw––––––– 1 root root 55 Nov 1 15:39 shells
|
|
–rw––––––– 1 root root 774 Nov 1 15:39 termcap
|
|
–rw––––––– 1 root root 78 Nov 1 15:39 ttytype
|
|
lrwxrwxrwx 1 root root 15 Nov 1 15:39 utmp –> ../var/run/utmp
|
|
lrwxrwxrwx 1 root root 15 Nov 1 15:39 wtmp –> ../var/log/wtmp
|
|
|
|
/etc/pam.d:
|
|
–rw––––––– 1 root root 356 Nov 1 15:39 other
|
|
|
|
/lib:
|
|
–rwxr–xr–x 1 root root 45415 Nov 1 15:39 ld–2.0.7.so
|
|
lrwxrwxrwx 1 root root 11 Nov 1 15:39 ld–linux.so.2 –> ld–2.0.7.so
|
|
–rwxr–xr–x 1 root root 731548 Nov 1 15:39 libc–2.0.7.so
|
|
lrwxrwxrwx 1 root root 13 Nov 1 15:39 libc.so.6 –> libc–2.0.7.so
|
|
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcom_err.so.2 –> libcom_err.so.2.0
|
|
–rwxr–xr–x 1 root root 6209 Nov 1 15:39 libcom_err.so.2.0
|
|
–rwxr–xr–x 1 root root 153881 Nov 1 15:39 libcrypt–2.0.7.so
|
|
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libcrypt.so.1 –> libcrypt–2.0.7.so
|
|
–rwxr–xr–x 1 root root 12962 Nov 1 15:39 libdl–2.0.7.so
|
|
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libdl.so.2 –> libdl–2.0.7.so
|
|
lrwxrwxrwx 1 root root 16 Nov 1 15:39 libext2fs.so.2 –> libext2fs.so.2.4
|
|
–rwxr–xr–x 1 root root 81382 Nov 1 15:39 libext2fs.so.2.4
|
|
–rwxr–xr–x 1 root root 25222 Nov 1 15:39 libnsl–2.0.7.so
|
|
lrwxrwxrwx 1 root root 15 Nov 1 15:39 libnsl.so.1 –> libnsl–2.0.7.so
|
|
–rwx––x––x 1 root root 178336 Nov 1 15:39 libnss_files–2.0.7.so
|
|
lrwxrwxrwx 1 root root 21 Nov 1 15:39 libnss_files.so.1 –> libnss_files–2.0.7.so
|
|
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libpam.so.0 –> libpam.so.0.64
|
|
–rwxr–xr–x 1 root root 26906 Nov 1 15:39 libpam.so.0.64
|
|
lrwxrwxrwx 1 root root 19 Nov 1 15:39 libpam_misc.so.0 –> libpam_misc.so.0.64
|
|
–rwxr–xr–x 1 root root 7086 Nov 1 15:39 libpam_misc.so.0.64
|
|
–r–xr–xr–x 1 root root 35615 Nov 1 15:39 libproc.so.1.2.6
|
|
lrwxrwxrwx 1 root root 15 Nov 1 15:39 libpwdb.so.0 –> libpwdb.so.0.54
|
|
–rw–r–r––– 1 root root 121899 Nov 1 15:39 libpwdb.so.0.54
|
|
lrwxrwxrwx 1 root root 19 Nov 1 15:39 libtermcap.so.2 –> libtermcap.so.2.0.8
|
|
–rwxr–xr–x 1 root root 12041 Nov 1 15:39 libtermcap.so.2.0.8
|
|
–rwxr–xr–x 1 root root 12874 Nov 1 15:39 libutil–2.0.7.so
|
|
lrwxrwxrwx 1 root root 16 Nov 1 15:39 libutil.so.1 –> libutil–2.0.7.so
|
|
lrwxrwxrwx 1 root root 14 Nov 1 15:39 libuuid.so.1 –> libuuid.so.1.1
|
|
–rwxr–xr–x 1 root root 8039 Nov 1 15:39 libuuid.so.1.1
|
|
drwx––x––x 3 root root 1024 Nov 1 15:39 modules
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 security
|
|
|
|
/lib/modules:
|
|
drwx––x––x 4 root root 1024 Nov 1 15:39 2.0.35
|
|
|
|
/lib/modules/2.0.35:
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 block
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 cdrom
|
|
|
|
/lib/modules/2.0.35/block:
|
|
drwx–––––– 1 root root 7156 Nov 1 15:39 loop.o
|
|
|
|
/lib/modules/2.0.35/cdrom:
|
|
drwx–––––– 1 root root 24108 Nov 1 15:39 cdu31a.o
|
|
|
|
/lib/security:
|
|
–rwx––x––x 1 root root 8771 Nov 1 15:39 pam_permit.so
|
|
|
|
<Emphasis role='bold'>
|
|
*** Directory stubs for mounting
|
|
</Emphasis>
|
|
/mnt:
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 cdrom
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 floppy
|
|
|
|
/proc:
|
|
|
|
/root:
|
|
–rw––––––– 1 root root 176 Nov 1 15:39 .bashrc
|
|
–rw––––––– 1 root root 182 Nov 1 15:39 .cshrc
|
|
–rwx––x––x 1 root root 455 Nov 1 15:39 .profile
|
|
–rw––––––– 1 root root 4014 Nov 1 15:39 .tcshrc
|
|
|
|
/sbin:
|
|
–rwx––x––x 1 root root 23976 Nov 1 15:39 depmod
|
|
–rwx––x––x 2 root root 274600 Nov 1 15:39 e2fsck
|
|
–rwx––x––x 1 root root 41268 Nov 1 15:39 fdisk
|
|
–rwx––x––x 1 root root 9396 Nov 1 15:39 fsck
|
|
–rwx––x––x 2 root root 274600 Nov 1 15:39 fsck.ext2
|
|
–rwx––x––x 1 root root 29556 Nov 1 15:39 getty
|
|
–rwx––x––x 1 root root 6620 Nov 1 15:39 halt
|
|
–rwx––x––x 1 root root 23116 Nov 1 15:39 init
|
|
–rwx––x––x 1 root root 25612 Nov 1 15:39 insmod
|
|
–rwx––x––x 1 root root 10368 Nov 1 15:39 kerneld
|
|
–rwx––x––x 1 root root 110400 Nov 1 15:39 ldconfig
|
|
–rwx––x––x 1 root root 6108 Nov 1 15:39 lsmod
|
|
–rwx––x––x 2 root root 17400 Nov 1 15:39 mke2fs
|
|
–rwx––x––x 1 root root 4072 Nov 1 15:39 mkfs
|
|
–rwx––x––x 2 root root 17400 Nov 1 15:39 mkfs.ext2
|
|
–rwx––x––x 1 root root 5664 Nov 1 15:39 mkswap
|
|
–rwx––x––x 1 root root 22032 Nov 1 15:39 modprobe
|
|
lrwxrwxrwx 1 root root 4 Nov 1 15:39 reboot –> halt
|
|
–rwx––x––x 1 root root 7492 Nov 1 15:39 rmmod
|
|
–rwx––x––x 1 root root 12932 Nov 1 15:39 shutdown
|
|
lrwxrwxrwx 1 root root 6 Nov 1 15:39 swapoff –> swapon
|
|
–rwx––x––x 1 root root 5124 Nov 1 15:39 swapon
|
|
lrwxrwxrwx 1 root root 4 Nov 1 15:39 telinit –> init
|
|
–rwx––x––x 1 root root 6944 Nov 1 15:39 update
|
|
|
|
/tmp:
|
|
|
|
/usr:
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 bin
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 lib
|
|
drwx––x––x 3 root root 1024 Nov 1 15:39 man
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 sbin
|
|
drwx––x––x 3 root root 1024 Nov 1 15:39 share
|
|
lrwxrwxrwx 1 root root 10 Nov 1 15:39 tmp –> ../var/tmp
|
|
|
|
/usr/bin:
|
|
–rwx––x––x 1 root root 37164 Nov 1 15:39 afio
|
|
–rwx––x––x 1 root root 5044 Nov 1 15:39 chroot
|
|
–rwx––x––x 1 root root 10656 Nov 1 15:39 cut
|
|
–rwx––x––x 1 root root 63652 Nov 1 15:39 diff
|
|
–rwx––x––x 1 root root 12972 Nov 1 15:39 du
|
|
–rwx––x––x 1 root root 56552 Nov 1 15:39 find
|
|
–r–x––x––x 1 root root 6280 Nov 1 15:39 free
|
|
–rwx––x––x 1 root root 7680 Nov 1 15:39 head
|
|
–rwx––x––x 1 root root 8504 Nov 1 15:39 id
|
|
–r–sr–xr–x 1 root bin 4200 Nov 1 15:39 passwd
|
|
–rwx––x––x 1 root root 14856 Nov 1 15:39 tail
|
|
–rwx––x––x 1 root root 19008 Nov 1 15:39 tr
|
|
–rwx––x––x 1 root root 7160 Nov 1 15:39 wc
|
|
–rwx––x––x 1 root root 4412 Nov 1 15:39 whoami
|
|
|
|
/usr/lib:
|
|
lrwxrwxrwx 1 root root 17 Nov 1 15:39 libncurses.so.4 –> libncurses.so.4.2
|
|
–rw–r–r––– 1 root root 260474 Nov 1 15:39 libncurses.so.4.2
|
|
|
|
/usr/sbin:
|
|
–r–x––x––x 1 root root 13684 Nov 1 15:39 fuser
|
|
–rwx––x––x 1 root root 3876 Nov 1 15:39 mklost+found
|
|
|
|
/usr/share:
|
|
drwx––x––x 4 root root 1024 Nov 1 15:39 terminfo
|
|
|
|
/usr/share/terminfo:
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 l
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 v
|
|
|
|
/usr/share/terminfo/l:
|
|
–rw––––––– 1 root root 1552 Nov 1 15:39 linux
|
|
–rw––––––– 1 root root 1516 Nov 1 15:39 linux–m
|
|
–rw––––––– 1 root root 1583 Nov 1 15:39 linux–nic
|
|
|
|
/usr/share/terminfo/v:
|
|
–rw––––––– 2 root root 1143 Nov 1 15:39 vt100
|
|
–rw––––––– 2 root root 1143 Nov 1 15:39 vt100–am
|
|
|
|
/var:
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 log
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 run
|
|
drwx––x––x 2 root root 1024 Nov 1 15:39 tmp
|
|
|
|
/var/log:
|
|
–rw––––––– 1 root root 0 Nov 1 15:39 wtmp
|
|
|
|
/var/run:
|
|
–rw––––––– 1 root root 0 Nov 1 15:39 utmp
|
|
|
|
/var/tmp:
|
|
</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
|
|
–rwxr–xr–x 1 root root 42333 Jul 28 19:05 cpio
|
|
–rwxr–xr–x 1 root root 32844 Aug 28 19:50 debugfs
|
|
–rwxr–xr–x 1 root root 103560 Jul 29 21:31 elvis
|
|
–rwxr–xr–x 1 root root 29536 Jul 28 19:04 fdisk
|
|
–rw–r–r––– 1 root root 128254 Jul 28 19:03 ftape.o
|
|
–rwxr–xr–x 1 root root 17564 Jul 25 03:21 ftmt
|
|
–rwxr–xr–x 1 root root 64161 Jul 29 20:47 grep
|
|
–rwxr–xr–x 1 root root 45309 Jul 29 20:48 gzip
|
|
–rwxr–xr–x 1 root root 23560 Jul 28 19:04 insmod
|
|
–rwxr–xr–x 1 root root 118 Jul 28 19:04 lsmod
|
|
lrwxrwxrwx 1 root root 5 Jul 28 19:04 mt –> mt–st
|
|
–rwxr–xr–x 1 root root 9573 Jul 28 19:03 mt–st
|
|
lrwxrwxrwx 1 root root 6 Jul 28 19:05 rmmod –> insmod
|
|
–rwxr–xr–x 1 root root 104085 Jul 28 19:05 tar
|
|
lrwxrwxrwx 1 root root 5 Jul 29 21:35 vi –> elvis
|
|
</Screen>
|
|
</Para>
|
|
</Appendix>
|
|
</Article>
|
|
|