The boot sequence varies in details among systems
but can be roughly divided to the following steps:
(i) hardware boot, (ii) OS loader,
(iii) kernel startup, (iv) init and inittab,
(v) boot scripts.
We will describe each of these in more detail below.
After power-on or hard reset, control is given
to a program stored on read only memory (normally
PROM). In PC we usually call this program the
BIOS.
This program normally makes a basic self-test of the
machine and accesses non-volatile memory to read
further parameters. This memory in the PC is
battery-backed CMOS memory, so most people
refer to it as the CMOS, although outside
of the PC world, it is usually called nvram
(non-volatile ram).
The parameters stored in the nvram vary between
systems, but as a minimum, the hardware boot program
should know what is the boot device, or which devices
to probe as possible boot devices.
Then the hardware boot stage accesses the boot device,
loads the OS Loader, which is located on a fixed position
on the boot device, and transfers control to it.
Note:
We do not cover here booting from network. Those who want
to investigate this subject may want to research:
DHCP, TFTP, PXE, Etherboot.
In PC, the OS Loader is located in the first sector
of the boot device - this is the MBR
(Master Boot Record).
In most systems, this primary loader is very
limited due to various constraints. Even on non-PC systems
there are some limitations to the size and complexity
of this loader, but the size limitation of the PC MBR
(512 bytes including the partition table) makes it
almost impossible to squeeze a full OS Loader into it.
Therefore, most operating systems make the primary loader
call a secondary OS loader which may be located on
a specified disk partition.
In Linux the OS loader is normally
lilo(8)
or
grub(8).
Both of them may install either as secondary loaders
(where the DOS installed MBR points to them), or
as a two part loader where they provide special MBR
containing the bootstrap code to load the second part
of the loader from the root partition.
The main job of the OS Loader is to locate the kernel
on the disk, load it and run it. Most OS loaders allow
interactive use, to enable specification of alternative
kernel (maybe a backup in case the last compiled one
isn’t functioning) and to pass optional parameters
to the kernel.
When the kernel is loaded, it initializes the devices (via
their drivers), starts the swapper (it is a "kernel process",
called kswapd in modern Linux kernels), and mounts the root
file system (/).
Some of the parameters that may be passed to the kernel
relate to these activities (e.g: You can override the
default root file system). For further information
on Linux kernel parameters read
bootparam(7).
Only then the kernel creates the first (user land)
process which is numbered 1. This process executes the
program
/sbin/init, passing any parameters that weren’t handled by the kernel already.
When init starts it reads
/etc/inittab for further instructions.
This file defines what should be run in different run-levels.
This gives the system administrator an easy management scheme, where
each run-level is associated with a set of services (e.g:
S is single-user, on 2 most network
services start, etc.). The administrator may change the current
run-level via
init(8)
and query the current run-level via
runlevel(8).
However, since it is not convenient to manage individual services
by editing this file, inittab only bootstraps a set of scripts
that actually start/stop the individual services.
The following description applies to System V release 4 based system, which
currently covers most commercial Unices (Solaris, HP-UX, Irix, Tru64)
as well as the major Linux distributions (RedHat, Debian, Mandrake,
Suse, Caldera). Some systems (Slackware Linux, FreeBSD, OpenBSD)
have a somewhat different scheme of boot scripts.
For each managed service (mail, nfs server, cron, etc.) there is
a single startup script located in a specific directory
(/etc/init.d in most versions of Linux).
Each of these scripts accepts as a single argument
the word ’start’ -- causing it to start the service, or the word
’stop’ -- causing it to stop the service. The script may optionally
accept other "convenience" parameters (e.g: ’restart’, to stop and then
start, ’status’ do display the service status). Running the script
without parameters displays the possible arguments.
To make specific scripts start/stop at specific run-levels and in
specific order, there are sequencing directories. These
are normally in /etc/rc[0-6S].d. In each of these directories
there are links (usually symbolic) to the scripts in the init.d
directory.
A primary script (usually /etc/rc) is called from
inittab(5)
and calls the services scripts via the links in the sequencing directories.
All links with names that begin with ’S’ are being called with
the argument ’start’ (thereby starting the service). All links with
names that begin with ’K’ are being called with the argument ’stop’
(thereby stopping the service).
To define the starting or stopping order within the same run-level,
the names of the links contain order-numbers.
Also, to make the names clearer, they usually
end with the name of the service they refer to. Example:
the link /etc/rc2.d/S80sendmail starts the sendmail service on
runlevel 2. This happens after /etc/rc2.d/S12syslog is run
but before /etc/rc2.d/S90xfs is run.
To manage the boot order and run-levels, we have to manage these links.
However, on many versions of Linux, there are tools to help with this task
(e.g:
chkconfig(8)).
Usually the daemons started may optionally receive command line options
and parameters. To allow system administrators to change these
parameters without editing the boot scripts themselves,
configuration files are used. These are located in a specific
directory (/etc/sysconfig on RedHat systems) and are
used by the boot scripts.
In older Unices, these files contained the actual command line
options for the daemons, but in modern Linux systems (and also
in HP-UX), these files just contain shell variables. The boot
scripts in /etc/init.dsource the configuration
files, and then use the variable values.
