mirror of https://github.com/mkerrisk/man-pages
230 lines
8.1 KiB
Groff
230 lines
8.1 KiB
Groff
.\" Written by Oron Peled <oron@actcom.co.il>.
|
|
.\"
|
|
.\" %%%LICENSE_START(GPL_NOVERSION_ONELINE)
|
|
.\" May be distributed subject to the GPL.
|
|
.\" %%%LICENSE_END
|
|
.\"
|
|
.\" 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(1) 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 2015-03-11 "Linux" "Linux Programmer's Manual"
|
|
.SH NAME
|
|
boot \- System bootup process based on UNIX System V Release 4
|
|
.SH DESCRIPTION
|
|
.PP
|
|
The \fBbootup process\fR (or "\fBboot sequence\fR") varies in details
|
|
among systems, but can be roughly divided into phases controlled by
|
|
the following components:
|
|
.IP 1. 4
|
|
hardware
|
|
.IP 2. 4
|
|
operating system (OS) loader
|
|
.IP 3. 4
|
|
kernel
|
|
.IP 4. 4
|
|
root user-space process (\fIinit\fR and \fIinittab\fR)
|
|
.IP 5. 4
|
|
boot scripts
|
|
.PP
|
|
Each of these is described below in more detail.
|
|
.SS Hardware
|
|
After power-on or hard reset, control is given
|
|
to a program stored in read-only memory (normally
|
|
PROM); for historical reasons involving the personal
|
|
computer, this program is often called "the \fBBIOS\fR".
|
|
.PP
|
|
This program normally performs 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 \fBCMOS\fR"; outside
|
|
of the PC world, it is usually called "the \fBNVRAM\fR"
|
|
(nonvolatile RAM).
|
|
.PP
|
|
The parameters stored in the NVRAM vary among
|
|
systems, but as a minimum, they should specify
|
|
which device can supply an OS loader, or at least which
|
|
devices may be probed for one; such a device is known as "the
|
|
\fBboot device\fR".
|
|
The hardware boot stage loads the OS loader from a fixed position on
|
|
the boot device, and then transfers control to it.
|
|
.TP
|
|
Note:
|
|
The device from which the OS loader is read may be attached via a network, in which
|
|
case the details of booting are further specified by protocols such as
|
|
DHCP, TFTP, PXE, Etherboot, etc.
|
|
.SS OS loader
|
|
The main job of the OS loader is to locate the kernel
|
|
on some device, load it, and run it.
|
|
Most OS loaders allow
|
|
interactive use, in order to enable specification of an alternative
|
|
kernel (maybe a backup in case the one last compiled
|
|
isn't functioning) and to pass optional parameters
|
|
to the kernel.
|
|
.PP
|
|
In a traditional PC, the OS loader is located in the initial 512-byte block
|
|
of the boot device; this block is known as "the \fBMBR\fR"
|
|
(Master Boot Record).
|
|
.PP
|
|
In most systems, the OS loader is very
|
|
limited due to various constraints.
|
|
Even on non-PC systems,
|
|
there are some limitations on 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 much functionality into it.
|
|
.PP
|
|
Therefore, most systems split the role of loading the OS between
|
|
a primary OS loader and a secondary OS loader; this secondary
|
|
OS loader may be located within a larger portion of persistent
|
|
storage, such as a disk partition.
|
|
.PP
|
|
In Linux, the OS loader is often either
|
|
.BR lilo (8)
|
|
or
|
|
.BR grub (8).
|
|
.SS Kernel
|
|
When the kernel is loaded, it initializes various components of
|
|
the computer and operating system; each portion of software
|
|
responsible for such a task is usually consider "a \fBdriver\fR" for
|
|
the applicable component.
|
|
The kernel starts the virtual memory
|
|
swapper (it is a kernel process, called "kswapd" in a modern Linux
|
|
kernel), and mounts some filesystem at the root path,
|
|
.IR / .
|
|
.PP
|
|
Some of the parameters that may be passed to the kernel
|
|
relate to these activities (for example, the default root filesystem
|
|
can be overridden); for further information
|
|
on Linux kernel parameters, read
|
|
.BR bootparam (7).
|
|
.PP
|
|
Only then does the kernel create the initial userland
|
|
process, which is given the number 1 as its
|
|
.B PID
|
|
(process ID).
|
|
Traditionally, this process executes the
|
|
program
|
|
.IR /sbin/init ,
|
|
to which are passed the parameters that haven't already been
|
|
handled by the kernel.
|
|
.SS Root user-space process
|
|
.TP
|
|
Note:
|
|
The following description applies to an OS based on UNIX System V Release 4.
|
|
However, a number of widely used systems have adopted a related but
|
|
fundamentally different approach known as
|
|
.BR systemd (1),
|
|
for which the bootup process is detailed in its associated
|
|
.BR bootup (7).
|
|
.PP
|
|
When
|
|
.I /sbin/init
|
|
starts, it reads
|
|
.I /etc/inittab
|
|
for further instructions.
|
|
This file defines what should be run when the
|
|
.I /sbin/init
|
|
program is instructed to enter a particular \fIrun-level\fR, giving
|
|
the administrator an easy way to establish an environment
|
|
for some usage; each run-level is associated with a set of services
|
|
(for example, run-level \fBS\fR is \fIsingle-user\fR mode,
|
|
and run-level \fB2\fR entails running most network services).
|
|
.PP
|
|
The administrator may change the current
|
|
run-level via
|
|
.BR init (1),
|
|
and query the current run-level via
|
|
.BR runlevel (8).
|
|
.PP
|
|
However, since it is not convenient to manage individual services
|
|
by editing this file,
|
|
.I /etc/inittab
|
|
only bootstraps a set of scripts
|
|
that actually start/stop the individual services.
|
|
.SS Boot scripts
|
|
.TP
|
|
Note:
|
|
The following description applies to an OS based on UNIX System V Release 4.
|
|
However, a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD)
|
|
have a somewhat different scheme for boot scripts.
|
|
.PP
|
|
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" to display the service status, etc.).
|
|
Running the script
|
|
without parameters displays the possible arguments.
|
|
.SS Sequencing directories
|
|
To make specific scripts start/stop at specific run-levels and in a
|
|
specific order, there are \fIsequencing directories\fR, normally
|
|
of the form \fI/etc/rc[0\-6S].d\fR.
|
|
In each of these directories,
|
|
there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR
|
|
directory.
|
|
.PP
|
|
A primary script (usually \fI/etc/rc\fR) is called from
|
|
.BR inittab (5);
|
|
this primary script calls each service's script via a link in the
|
|
relevant sequencing directory.
|
|
Each link whose name begins with \(aqS\(aq is called with
|
|
the argument "start" (thereby starting the service).
|
|
Each link whose name begins with \(aqK\(aq is called with
|
|
the argument "stop" (thereby stopping the service).
|
|
.PP
|
|
To define the starting or stopping order within the same run-level,
|
|
the name of a link contains an \fBorder-number\fR.
|
|
Also, for clarity, the name of a link usually
|
|
ends with the name of the service to which it refers.
|
|
For 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.
|
|
.PP
|
|
To manage these links is to manage the boot order and run-levels;
|
|
under many systems, there are tools to help with this task
|
|
(e.g.,
|
|
.BR chkconfig (8)).
|
|
.SS Boot configuration
|
|
A program that provides a service is often called a "\fBdaemon\fR".
|
|
Usually, a daemon may receive various command-line options
|
|
and parameters.
|
|
To allow a system administrator to change these
|
|
inputs without editing an entire boot script,
|
|
some separate configuration file is used, and is located in a specific
|
|
directory where an associated boot script may find it
|
|
(\fI/etc/sysconfig\fR on older Red Hat systems).
|
|
.PP
|
|
In older UNIX systems, such a file contained the actual command line
|
|
options for a daemon, but in modern Linux systems (and also
|
|
in HP-UX), it just contains shell variables.
|
|
A boot script in \fI/etc/init.d\fR reads and includes its configuration
|
|
file (that is, it "\fBsources\fR" its configuration file) and then uses
|
|
the variable values.
|
|
.SH FILES
|
|
.PP
|
|
.IR /etc/init.d/ ,
|
|
.IR /etc/rc[S0\-6].d/ ,
|
|
.I /etc/sysconfig/
|
|
.SH SEE ALSO
|
|
.BR init (1),
|
|
.BR systemd (1),
|
|
.BR inittab (5),
|
|
.BR bootparam (7),
|
|
.BR bootup (7),
|
|
.BR runlevel (8),
|
|
.BR shutdown (8)
|