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
This program normally makes a basic self-test of the machine and
accesses nonvolatile 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
The parameters stored in the nvram vary between systems, but as a mini-
mum, 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,
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 impossi-
ble to squeeze a full OS Loader into it.
Therefore, most operating systems make the primary loader call a sec-
ondary 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 speci-
fication of alternative kernel (maybe a backup in case the last com-
piled one isn't functioning) and to pass optional parameters to the
parameters that weren't handled by the kernel already.
init and inittab
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 actu-
ally start/stop the individual services.
Note: The following description applies to System V release 4-based
systems, which currently covers most commercial UNIX systems
(Solaris, HP-UX, Irix, Tru64) as well as the major Linux distri-
butions (Red Hat, Debian, Mandriva, SUSE, Ubuntu). 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 sin-
gle 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 spe-
cific 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 /etc/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 stop-
ping 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.
UX), these files just contain shell variables. The boot scripts in
/etc/init.d source the configuration files, and then use the variable
/etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/
inittab(5), bootparam(7), init(8), runlevel(8), shutdown(8)
This page is part of release 3.35 of the Linux man-pages project. A
description of the project, and information about reporting bugs, can
be found at http://man7.org/linux/man-pages/.
Linux 2010-09-19 BOOT(7)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2017
All Rights Reserved.