mirror of https://github.com/mkerrisk/man-pages
199 lines
7.2 KiB
Groff
199 lines
7.2 KiB
Groff
.\" Written by Oron Peled <oron@actcom.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 <joey@infodrom.org>
|
|
.\"
|
|
.TH BOOT 7 2002-06-07 "" "Linux Programmer's Manual"
|
|
.SH "NAME"
|
|
.LP
|
|
boot\-scripts \- General description of boot sequence
|
|
.SH "DESCRIPTION"
|
|
.LP
|
|
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.
|
|
|
|
.SS "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
|
|
\fBBIOS\fR.
|
|
|
|
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 \fBCMOS\fR, although outside
|
|
of the PC world, it is usually called \fBnvram\fR
|
|
(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.
|
|
|
|
.TP
|
|
Note:
|
|
We do not cover here booting from network. Those who want
|
|
to investigate this subject may want to research:
|
|
DHCP, TFTP, PXE, Etherboot.
|
|
|
|
.SS "OS Loader"
|
|
In PC, the OS Loader is located in the first sector
|
|
of the boot device \- this is the \fBMBR\fR
|
|
(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
|
|
.BR lilo (8)
|
|
or
|
|
.BR 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.
|
|
|
|
.SS "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
|
|
.BR bootparam (7).
|
|
|
|
Only then the kernel creates the first (user land)
|
|
process which is numbered 1. This process executes the
|
|
program
|
|
.IR /sbin/init ,
|
|
passing any parameters that weren't handled by the kernel already.
|
|
|
|
.SS "init and inittab"
|
|
When init starts it reads
|
|
.I /etc/inittab
|
|
for further instructions.
|
|
This file defines what should be run in different \fIrun-levels\fR.
|
|
|
|
This gives the system administrator an easy management scheme, where
|
|
each run-level is associated with a set of services (e.g:
|
|
\fBS\fR is \fIsingle\-user\fR, on \fB2\fR most network
|
|
services start, etc.). The administrator may change the current
|
|
run-level via
|
|
.BR init (8)
|
|
and query the current run-level via
|
|
.BR 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.
|
|
|
|
.SS "Boot Scripts"
|
|
|
|
.TP
|
|
Note:
|
|
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.
|
|
.LP
|
|
|
|
For each managed service (mail, nfs server, cron, etc.) there is
|
|
a single startup script located in a specific directory
|
|
.RI ( /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.
|
|
|
|
.SS "Sequencing Directories"
|
|
To make specific scripts start/stop at specific run-levels and in
|
|
specific order, there are \fIsequencing directories\fR. These
|
|
are normally in \fI/etc/rc[0\-6S].d\fR. In each of these directories
|
|
there are links (usually symbolic) to the scripts in the \fIinit.d\fR
|
|
directory.
|
|
|
|
A primary script (usually \fI/etc/rc\fR) is called from
|
|
.BR 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 \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on
|
|
runlevel 2. This happens after \fI/etc/rc2.d/S12syslog\fR is run
|
|
but before \fI/etc/rc2.d/S90xfs\fR 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:
|
|
.BR chkconfig (8)).
|
|
|
|
.SS "Boot Configuration"
|
|
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 (\fI/etc/sysconfig\fR 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 \fI/etc/init.d\fR \fBsource\fR the configuration
|
|
files, and then use the variable values.
|
|
.SH "FILES"
|
|
.LP
|
|
.IR /etc/init.d/ ,
|
|
.IR /etc/rc[S0\-6].d/ .
|
|
.I /etc/sysconfig/
|
|
|
|
.SH "SEE ALSO"
|
|
.BR inittab (5),
|
|
.BR bootparam (7),
|
|
.BR init (8),
|
|
.BR runlevel (8),
|
|
.BR shutdown (8)
|