boot-scripts — General description of boot sequence
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.
Note | |
---|---|
The following description applies to System V release 4 based system, which currently covers most commercial Unix systems (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 Unix systems, 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.d
source
the configuration
files, and then use the variable values.
This page is part of release 2.79 of the Linux man-pages
project. A
description of the project, and information about reporting
bugs, can be found at
http://www.kernel.org/doc/man-pages/.
Written by Oron Peled <oronactcom.co.il>. May be distributed subject to the GPL. I tried to be as much generic in the description as possible: - General boot sequence is applicable to almost any OS/Machine (DOS/PC, Linux/PC, Solaris/SPARC, CMS/S390) - kernel and init(8) is applicable to almost any Unix/Linux - boot scripts are applicable to SYSV-R4 based Unix/Linux Modified 2004-11-03 patch from Martin Schulze <joeyinfodrom.org> |