BOOT(7) Linux Programmer’s Manual BOOT(7)
NAME
boot-scripts - General description of boot sequence
DESCRIPTION
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.
Hardware-boot
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 bat-
tery-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.
OS Loader
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 parti-
tion 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.
Kernel Startup
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.
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 ser-
vices 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 indi-
vidual services.
Boot Scripts
Note: The following description applies to SYSV-R4 based system, which currently
covers most commercial Unices (Solaris, HPUX, 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 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.
Sequencing Directories
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 argu-
ment ’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/S80send-
mail 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: chkcon-
fig(8)).
Boot Configuration
Usually the daemons started may optionally receive command line options and parame-
ters. To allow system administrators to change these parameters without editing the
boot scripts themselves, configuration files are used. These are located in a spe-
cific 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 dae-
mons, but in modern Linux systems (and also in HPUX), these files just contain
shell variables. The boot scripts in /etc/init.d source the configuration files,
and then use the variable values.
FILES
/etc/init.d/, /etc/rc[S0-6].d/. /etc/sysconfig/
SEE ALSO
inittab(5), bootparam(7), init(8), runlevel(8), shutdown(8)
2002-06-07 BOOT(7)
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2008-08-28 11:45 @38.103.63.61 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)