Rute User's Tutorial and Exposition. 31. lilo, initrd, and Booting
Next: 32. init, ? getty,
Up: rute
Previous: 30. exim and sendmail
Contents
Subsections
lilo stands for
linux
loader.
LILO:
is the prompt you first see after boot up, from which you can usually
choose the OS you would like to boot and give certain
boot options to the kernel. This chapter explains how to configure
lilo and kernel boot options, and to get otherwise
non-booting systems to boot.
The
lilo package itself contains the files
|
/boot/boot.b /boot/message /sbin/lilo
/boot/chain.b /boot/os2_d.b /usr/bin/keytab-lilo
/usr/share/doc/lilo-<version>
|
which is not that interesting, except to know that
the technical and user documentation is there if hard-core details
are needed.
When you first start your LINUX system, the
LILO: prompt, at which you
can enter boot options, is displayed. Pressing  displays a list of
things to type. The purpose is to allow the booting of different
LINUX installations on the same machine, or different operating
systems stored in
different partitions on the same disk. Later, you
can actually view the file
/proc/cmdline
to see what boot options (including default boot options) were used.
A UNIX kernel, to be booted, must be loaded into memory from
disk and be executed. The execution of the kernel causes it to
uncompress itself and then run. [The word boot itself
comes from the concept that a computer cannot begin executing
without program code, and program code cannot get into memory
without other program code--like trying to lift yourself up by your
bootstraps, and hence the name.] The first thing the kernel does
after it runs is initialize various hardware devices.
It then mounts the root file system on a specified partition. Once the root
file system is mounted, the kernel executes
/sbin/init to begin
the UNIX operating system. This is how all UNIX systems begin
life.
PCs begin life with a small program in the ROM BIOS that loads the
very first sector of the disk into memory, called the boot sector
of the master boot record or MBR. This piece
of code is up to 512 bytes long and is expected to start the
operating system. In the case of LINUX, the boot sector loads the
file
/boot/map, which contains a list of the precise
location of the disk sectors that the LINUX kernel image
(usually the file
/boot/vmlinuz) spans. It loads each
of these sectors, thus
reconstructing the kernel image in memory. Then it jumps to the kernel
to execute it.
You may ask how it is possible to load a file from a file system when
the file system is not mounted. Further, the boot partition is a small
and simple program and certainly does not support the
many types of file systems and devices that the kernel image may reside
in. Actually,
lilo doesn't have to support a file system to
access a file, as long as it has a list of the sectors that the file
spans and is prepared to use the BIOS
interrupts [Nothing to do with ``interrupting'' or
hardware interrupts, but refers to BIOS functions that are available
for use by the operating system. Hardware devices may insert custom
BIOS functions to provided rudimentary support needed for themselves
at startup. This support is distinct from
that provided by the hardware device drivers
of the booted kernel.] to read those sectors. If the file is never
modified, that sector list will never change; this is how the
/boot/map and
/boot/vmlinuz files are loaded.
In addition to the MBR, each primary
partition has a boot sector that
can boot the operating system in that partition.
MS-DOS (Windows)
partitions have this, and hence
lilo can optionally load and
execute these partition boot sectors
to start a Windows installation in another partition.
BIOSs have inherited several limitations because of lack
of foresight of their designers.
First, some BIOSs do not support more than one
IDE. [At least according to the
lilo
documentation.] I myself have not come across this as a problem.
The second limitation is most important to note. As explained,
lilo uses BIOS functions to access the IDE drive, but
the BIOS of a PC is often limited to accessing the
first 1024 cylinders of
the disk. Hence, whatever LILO reads must reside within
the first 1024 cylinders (the first 500 megabytes of disk space). Here
is the list of things whose sectors are required to be within this
space:
- 1.
-
/boot/vmlinuz
- 2.
- Various
lilo files
/boot/*.b
- 3.
- Any non-LINUX partition boot sector you would like to
boot
However a LINUX root partition can reside anywhere
because the boot sector program never reads this partition except
for the abovementioned files. A scenario where the
/boot/
directory is a small partition below the 500 megabyte boundary and
the
/ partition is above the 500 megabyte boundary, is quite
common. See page ![[*]](crossref.png) .
Note that newer ``LBA'' BIOS's support more than the first
512 megabytes--even up to 8 Gigabytes. I personally do
not count on this.
To ``do a
lilo'' means running the
lilo command as
root, with a correct
/etc/lilo.conf file. The
lilo.conf file will doubtless have been set up by your
distribution (check yours). A typical
lilo.conf file that allows
booting of a Windows partition and two LINUX partitions is as follows:
5
10
15
20
|
boot=/dev/hda
prompt
timeout = 50
compact
vga = extended
lock
password = jAN]")Wo
restricted
append = "ether=9,0x300,0xd0000,0xd4000,eth0 hisax=1,3,5,0xd8000,0xd80,HiSax"
image = /boot/vmlinuz-2.2.17
label = linux
root = /dev/hda5
read-only
image = /boot/vmlinuz-2.0.38
label = linux-old
root = /dev/hda6
read-only
other = /dev/hda2
label = win
table = /dev/hda
|
Running
lilo will install into the MBR a boot loader that
understands where to get the
/boot/map file, which in turn
understands where to get the
/boot/vmlinuz-2.2.12-20 file. It
gives output like:
|
[root@cericon]# lilo
Added linux *
Added linux-old
Added win
|
It also backs up your existing MBR, if this has not previously been
done, into a file
/boot/boot.0300 (where
0300 refers to
the device's major and minor number).
Let's go through the options:
-
boot
- Device to boot. It will most always be
/dev/hda or
/dev/sda.
-
prompt
- Display a prompt where the user can enter the OS to boot.
-
timeout
- How many tenths of a seconds to display the prompt (after which the first image is booted).
-
compact
- String together adjacent sector reads. This makes the kernel load much faster.
-
vga
- We would like 80x50 text mode. Your startup scripts may reset this to
80x25--search
/etc/rc.d recursively for any file containing ``
textmode''.
-
lock
- Always default to boot the last OS booted [A very useful feature which is seldom used.].
-
password
- Require a password to boot.
-
restricted
- Require a password only if someone attempts to enter
special options at the
LILO: prompt.
-
append
- A kernel boot option.
Kernel boot options are central to
lilo
and kernel modules and are discussed in
Chapter 42.5. They are mostly
not needed in simple installations.
-
image
- A LINUX kernel to boot.
-
label
- The text to type at the boot prompt to cause this kernel/partition to boot.
-
root
- The root file system that the kernel must mount.
-
read-only
- Flag to specify that the root file system must initially be mounted read-only.
-
other
- Some other operating system to boot: in this case, a Windows partition.
-
table
- Partition table info to be passed to the partition boot sector.
Further
other = partitions can follow, and many
image = kernel
images are allowed.
The preceding
lilo.conf file assumed a partition scheme as follows:
-
/dev/hda1
- 10-megabyte
ext2 partition to be mounted on
/boot.
-
/dev/hda2
- Windows 98 partition over 500 megabytes in size.
-
/dev/hda3
- Extended partition.
-
/dev/hda4
- Unused primary partition.
-
/dev/hda5
-
ext2 root file system.
-
/dev/hda6
- Second
ext2 root file system containing an older distribution.
-
/dev/hda?
- LINUX swap,
/home, and other partitions.
If LILO is broken or absent, we require an alternative boot method.
A floppy disk capable of booting our system must contain a kernel
image, the means to load the image into memory, and the means to
mount
/dev/hda5 as the root file system. To create such a
floppy, insert a new floppy disk into a running LINUX
system, and overwrite it with the following commands:
|
dd if=/boot/vmlinuz-2.2.17 of=/dev/fd0
rdev /dev/fd0 /dev/hda5
|
Then simply boot the floppy. This procedure requires a second
LINUX installation at least. If you only have an MS-DOS or Windows
system at your disposal then you will have to download the
RAWRITE.EXE utility as well as a raw boot disk image.
Many of these are available and will enable you to create
a boot floppy from a DOS prompt. I will not go into detail
about this here.
Some of the following descriptions may be difficult to understand
without knowledge of kernel modules explained in Chapter
42. You may want to come back to it later.
Consider a system with zero IDE disks and one SCSI disk
containing a LINUX installation. There are BIOS interrupts to read
the SCSI disk, just as there were for the IDE, so LILO can happily
access a kernel image somewhere inside the SCSI partition.
However, the kernel is going to be lost without a kernel
module [See Chapter 42. The kernel
doesn't support every possible kind of hardware out there all by
itself. It is actually divided into a main part (the kernel image
discussed in this chapter) and hundreds of modules (loadable parts
that reside in
/lib/modules/)
that support the many type of SCSI,
network, sound etc., peripheral devices.] that understands the
particular SCSI driver. So although the kernel can load and execute, it
won't be able to mount its root file system without loading a SCSI module
first. But the module itself resides in the root file system in
/lib/modules/. This is a tricky situation to solve and is done
in one of two ways: either (a) using a kernel with preenabled
SCSI support or (b) using what is known as an
initrd
preliminary root file system image.
The first method is what I recommend. It's a straightforward (though
time-consuming) procedure to create a kernel with SCSI support
for your SCSI card built-in (and not in a separate module). Built-in
SCSI and network drivers will also autodetect cards most of the
time, allowing immediate access to the
device--they will
work without being given any options [Discussed in Chapter
42.] and, most importantly, without your having to read
up on how to configure them. This setup is known as compiled-in
support for a hardware driver (as opposed to module support
for the driver). The resulting kernel image will be larger by an
amount equal to the size of module. Chapter 42
discusses such kernel compiles.
The second method is faster but trickier. LINUX supports
what is known as an
initrd image (
initial
rAM
disk image). This is a small, +1.5 megabyte file system that
is loaded by LILO and mounted by the kernel instead of the real
file system. The kernel mounts this file system as a RAM disk,
executes the file
/linuxrc, and then only mounts the real
file system.
Start by creating a small file system. Make a
directory
~/initrd and copy the following files into it.
5
10
15
|
drwxr-xr-x 7 root root 1024 Sep 14 20:12 initrd/
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/bin/
-rwxr-xr-x 1 root root 436328 Sep 14 20:12 initrd/bin/insmod
-rwxr-xr-x 1 root root 424680 Sep 14 20:12 initrd/bin/sash
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/dev/
crw-r--r-- 1 root root 5, 1 Sep 14 20:12 initrd/dev/console
crw-r--r-- 1 root root 1, 3 Sep 14 20:12 initrd/dev/null
brw-r--r-- 1 root root 1, 1 Sep 14 20:12 initrd/dev/ram
crw-r--r-- 1 root root 4, 0 Sep 14 20:12 initrd/dev/systty
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty1
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty2
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty3
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty4
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/etc/
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/lib/
-rwxr-xr-x 1 root root 76 Sep 14 20:12 initrd/linuxrc
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/loopfs/
|
On my system, the file
initrd/bin/insmod is the
statically linked [meaning it does not require shared
libraries.] version copied from
/sbin/insmod.static--a member of
the
modutils-2.3.13 package.
initrd/bin/sash is a statically
linked shell from the
sash-3.4 package. You can recompile
insmod from source if you don't have a statically linked version.
Alternatively, copy the needed DLLs from
/lib/ to
initrd/lib/. (You can
get the list of required DLLs by running
ldd /sbin/insmod. Don't forget
to also copy symlinks and run
strip -s <lib> to
reduce the size of the DLLs.)
Now copy into the
initrd/lib/ directory the SCSI modules
you require. For example, if we have an Adaptec AIC-7850 SCSI
adapter, we would require the
aic7xxx.o module
from
/lib/modules/<version>/scsi/aic7xxx.o. Then, place it in the
initrd/lib/ directory.
|
-rw-r--r-- 1 root root 129448 Sep 27 1999 initrd/lib/aic7xxx.o
|
The file
initrd/linuxrc should contain a script to load all
the modules needed for the kernel to access the SCSI partition. In this
case, just the
aic7xxx module [
insmod can take options
such as the IRQ and IO-port for the device. See Chapter 42.]:
5
|
#!/bin/sash
aliasall
echo "Loading aic7xxx module"
insmod /lib/aic7xxx.o
|
Now double-check all your permissions and then
chroot to the
file system for testing.
|
chroot ~/initrd /bin/sash
/linuxrc
|
Now, create a file system image similar to that in
Section 19.9:
5
|
dd if=/dev/zero of=~/file-inird count=2500 bs=1024
losetup /dev/loop0 ~/file-inird
mke2fs /dev/loop0
mkdir ~/mnt
mount /dev/loop0 ~/mnt
cp -a initrd/* ~/mnt/
umount ~/mnt
losetup -d /dev/loop0
|
Finally,
gzip the file system to an appropriately named file:
|
gzip -c ~/file-inird > initrd-<kernel-version>
|
Your
lilo.conf file can be changed slightly to force
use of an
initrd file system. Simply add the
initrd
option. For example:
5
10
|
boot=/dev/sda
prompt
timeout = 50
compact
vga = extended
linear
image = /boot/vmlinuz-2.2.17
initrd = /boot/initrd-2.2.17
label = linux
root = /dev/sda1
read-only
|
Notice the use of the
linear option. This is a BIOS
trick that you can read about in
lilo(5). It is often necessary
but can make SCSI disks nonportable to different BIOSs (meaning
that you will have to rerun
lilo if you move the disk to a
different computer).
Now that you have learned the manual method of creating an
initrd image, you can read the
mkinitrd man page. It
creates an image in a single command. This is command is peculiar
to RedHat.
Next: 32. init, ? getty,
Up: rute
Previous: 30. exim and sendmail
Contents
|
