Revision: $Revision: 1.8 $
Candidate should be able to: determine, from bootup text, the 4 stages of boot sequence and distinguish between each.
Key files, terms and utilities include:
| boot loader start and hand off to kernel |
| kernel loading |
| hardware initialization and setup |
| daemon initialization and setup |
Resources: the man pages for the various commands.
The boot process has been described at length in Chapter 2, System Startup (202). This section underlines and enhances that description. We will limit our discussion to PC hardware, though most other hardware uses similar schemes.
The PC boot process is started on powerup. The processor will start execution of code contained in the Basic In- and Output System (BIOS). The BIOS is a program stored in Read Only Memory (ROM) and is a part of the PC hardware. Apart from the bootstrap code it contains routines to set up your hardware and to communicate with it. Most of the code in the BIOS is never used by Linux, but the bootstrap code is.
The bootstrap code will load a block of data from sector 0, cylinder 0 of what has been configured to be your boot drive. In most cases this will be the first floppy drive. If reading the floppy disk fails or no floppy disk was inserted, the program in the BIOS will try to load the first sector from the first (specified) hard disk. Most BIOSes allow you to set up an alternate order, i.e. to try the hard disk first or first try to boot from CD.
Wherever the data was found (and if it was found, of course) the BIOS will load it into memory and try to execute it as if it were a program. In most cases the data either consists of code from a boot loader such as LILO, or the start of an operating system kernel like Linux. If the code on the boot sector is illegible or invalid, the BIOS will try the next bootdevice.
As can be determined from the text above, there are two ways for the kernel to be loaded:
by using the kernelcode itself. The first sector of the boot disk will contain the first sector of the Linux kernel itself. That code loads the rest of the kernel from the boot device.
by using a bootstrap loader. There are 2 well-known bootstrap loaders for Linux: GRUB (GRand Unified Bootloader) and LILO. LILO is still widely used, but most modern distributions employ GRUB. GRUB has a number of advantages over LILO, such as built in knowledge of filesystems. Hence GRUB is capable of loading configuration files and the kernel directly by their filename. LILO uses a different method: the physical location (track/sector/offset) for the kernel is stored at installation time. The bootloader part of LILO doesn't need knowledge of the filesystem it is booting from.
If a bootstrap loader has been used, it will locate the kernel, load it and execute it. If the kernel has been raw-copied to a diskette its first sector also contains code that loads the rest of the kernelcode from the boot device and consequently executes it.
The kernel will initialize its internal data structures and device drivers.
Once it is completely initialized, it consults the contents of the
ramdisk word, a fixed address in its binary that
specifies where the kernel can find the filesystem that will be mounted as
root (`/', the root filesystem). The ramdisk word
also can specify that the filesystem is a RAMdisk. A RAMdisk is a memory
region that is loaded with a (optionally compressed) image of a filesystem,
and that is used if it were a hard disk. If the kernel can not find the
root filesystem it halts.
Assuming all went well the kernel now is up and running and has mounted its
root filesystem. Next, the kernel Will start up the init
program, located in either /bin or /sbin.
init uses the configuration file
/etc/inittab to determine which program(s) to start
next.
The way init is used to start up the initial processes
varies from distribution to distribution. init can be
configured in many ways. But in all cases a number of commands will be issued
to set up the basic system such as running fsck on hard
disks, initializing swapping and mount disks that are configured in
/etc/fstab. Next, a group of commands (often scripts)
are executed. They define a so called runlevel.
Such runlevels define a set of processes that need to be run to get the
system in a certain state, for example multi-user mode or single-user mode.
The initdefault entry in the /etc/inittab
file defines the initial runlevel of the system. If there is no such entry
or the configuration file was not found init will prompt
for a runlevel at the system console. Consequently, all processes specified
for that runlevel in the inittab file will be started.
In some cases the initial scripts are specified by the sysinit
label in the init, in other cases they are considered
part of a runlevel.
When a runlevel defines multi-user use, typically a number of daemons is started
next. This is done by using start-up scripts, that can be in various location,
depending on the distribution you use. Typically such start-up scripts are
located in the /etc/rc.d/ directory and named aptly after
the software they run, e.g. sendmail, inetd
or sshd. Typically, these scripts are linked to another level
of directories, one per runlevel. In all runlevels one or more getty
programs will be spawned, to enable user logins.
From what was written before you now should be able to identify the four stages of the bootsequence:
boot loader start and hand off to kernel - typically you can recognize this stage because LILO displays the four letters “L”, “I”, “L”, and “O”. Each of these letters identifies a certain stage in the initial bootprocess. Their meaning is described in more detail in the section called “LILO errors”;
kernel loading - this stage can be recognized since the kernel will
display various messages, starting with the message
“Loading ” followed by the name
of your kernel, e.g. Linux-2.2.20.
hardware initialization and setup - can be identified by various messages that inform you about the various hardware components that were found and initialized.
daemon initialization and setup - this is fairly distribution specific, but this stage can be recognized by messages that typically contain lines like “Starting the ... daemon”.
The kernel stores its messages is a ring buffer. On most Linux systems that ring buffer is flushed to a file during the last phase of the boot process for later inspection. The command dmesg will display the contents of the current buffer (and actually often is used to flush the ring buffer to a file during the last phase of the boot sequence). Check the manual page for more information.