boot.7: Copy edit

While a lot of the changes are issues of presentation,
there are also issues of grammar and punctuation.

Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Witten 2015-03-11 19:54:44 +00:00 committed by Michael Kerrisk
parent 526c53f04b
commit a879ea438c
1 changed files with 127 additions and 114 deletions

View File

@ -12,188 +12,201 @@
.\" .\"
.\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org> .\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org>
.\" .\"
.TH BOOT 7 2010-09-19 "Linux" "Linux Programmer's Manual" .TH BOOT 7 2015-03-11 "Linux" "Linux Programmer's Manual"
.SH NAME .SH NAME
boot-scripts \- general description of boot sequence boot \- System bootup process based on UNIX System V Release 4
.SH DESCRIPTION .SH DESCRIPTION
.LP .LP
The boot sequence varies in details among systems The \fBbootup process\fR (or "\fBboot sequence\fR") varies in details
but can be roughly divided to the following steps: among systems, but can be roughly divided into phases controlled by
(i) hardware boot, (ii) operating system (OS) loader, the following components:
(iii) kernel startup, (iv) init and inittab, .IP 1. 4
(v) boot scripts. hardware
We will describe each of these in more detail below. .IP 2. 4
.SS Hardware-boot 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 After power-on or hard reset, control is given
to a program stored on read-only memory (normally to a program stored in read-only memory (normally
PROM). PROM); for historical reasons involving the personal
In PC we usually call this program the \fBBIOS\fR. computer, this program is often called "the \fBBIOS\fR".
This program normally makes a basic self-test of the This program normally performs a basic self-test of the
machine and accesses nonvolatile memory to read machine and accesses nonvolatile memory to read
further parameters. further parameters.
This memory in the PC is This memory in the PC is
battery-backed CMOS memory, so most people battery-backed CMOS memory, so most people
refer to it as the \fBCMOS\fR, although outside refer to it as "the \fBCMOS\fR"; outside
of the PC world, it is usually called \fBnvram\fR of the PC world, it is usually called "the \fBNVRAM\fR"
(nonvolatile ram). (nonvolatile RAM).
The parameters stored in the nvram vary between The parameters stored in the NVRAM vary among
systems, but as a minimum, the hardware boot program systems, but as a minimum, they should specify
should know what is the boot device, or which devices which device can supply an OS loader, or at least which
to probe as possible boot devices. devices may be probed for one; such a device is known as "the
\fBboot device\fR".
Then the hardware boot stage accesses the boot device, The hardware boot stage loads the OS loader from a fixed position on
loads the OS loader, which is located on a fixed position the boot device, and then transfers control to it.
on the boot device, and transfers control to it.
.TP .TP
Note: Note:
We do not cover here booting from network. The device from which the OS loader is read may be attached via a network, in which
Those who want case the details of booting are further specified by protocols such as
to investigate this subject may want to research: DHCP, TFTP, PXE, Etherboot, etc.
DHCP, TFTP, PXE, Etherboot.
.SS OS loader .SS OS loader
In PC, the OS loader is located in the first sector The main job of the OS loader is to locate the kernel
of the boot device \- this is the \fBMBR\fR 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.
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). (Master Boot Record).
In most systems, this primary loader is very In most systems, the OS loader is very
limited due to various constraints. limited due to various constraints.
Even on non-PC systems Even on non-PC systems,
there are some limitations to the size and complexity there are some limitations on the size and complexity
of this loader, but the size limitation of the PC MBR of this loader, but the size limitation of the PC MBR
(512 bytes including the partition table) makes it (512 bytes, including the partition table) makes it
almost impossible to squeeze a full OS loader into it. almost impossible to squeeze much functionality into it.
Therefore, most operating systems make the primary loader Therefore, most systems split the role of loading the OS between
call a secondary OS loader which may be located on a primary OS loader and a secondary OS loader; this secondary
a specified disk partition. OS loader may be located within a larger portion of persistent
storage, such as a disk partition.
In Linux the OS loader is normally In Linux, the OS loader is often either
.BR lilo (8) .BR lilo (8)
or or
.BR grub (8). .BR grub (8).
Both of them may install either as secondary loaders .SS Kernel
(where the DOS installed MBR points to them), or When the kernel is loaded, it initializes various components of
as a two part loader where they provide special MBR the computer and operating system; each portion of software
containing the bootstrap code to load the second part responsible for such a task is usually consider "a \fBdriver\fR" for
of the loader from the root partition. the applicable component. The kernel starts the virtual memory
swapper (it is a kernel process, called "kswapd" in a modern Linux
The main job of the OS loader is to locate the kernel kernel), and mounts some filesystem at the root path,
on the disk, load it and run it. .IR / .
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
filesystem (/).
Some of the parameters that may be passed to the kernel Some of the parameters that may be passed to the kernel
relate to these activities (e.g: You can override the relate to these activities (for example, the default root filesystem
default root filesystem). can be overriden); for further information
For further information on Linux kernel parameters, read
on Linux kernel parameters read
.BR bootparam (7). .BR bootparam (7).
Only then the kernel creates the first (user land) Only then does the kernel create the initial userland
process which is numbered 1. process, which is given the number 1 as its
This process executes the .B PID
(process ID).
Traditionally, this process executes the
program program
.IR /sbin/init , .IR /sbin/init ,
passing any parameters that weren't handled by the kernel already. to which are passed the parameters that haven't already been
.SS init and inittab handled by the kernel.
When init starts it reads .SS Root user-space process
When
.I /sbin/init
starts, it reads
.I /etc/inittab .I /etc/inittab
for further instructions. for further instructions.
This file defines what should be run in different \fIrun-levels\fR. 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).
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).
The administrator may change the current The administrator may change the current
run-level via run-level via
.BR init (1) .BR init (1),
and query the current run-level via and query the current run-level via
.BR runlevel (8). .BR runlevel (8).
However, since it is not convenient to manage individual services However, since it is not convenient to manage individual services
by editing this file, inittab only bootstraps a set of scripts by editing this file,
.I /etc/inittab
only bootstraps a set of scripts
that actually start/stop the individual services. that actually start/stop the individual services.
.SS Boot scripts .SS Boot scripts
.TP .TP
Note: Note:
The following description applies to System V release 4-based systems, which The following description applies to an OS based on UNIX System V Release 4,
currently covers most commercial UNIX systems (Solaris, HP-UX, Irix, Tru64) which currently covers most commercial UNIX systems (Solaris, HP-UX, Irix,
as well as the major Linux distributions (Red Hat, Debian, Mandriva, Tru64) as well as the major Linux distributions (Red Hat, Debian, Mandriva,
SUSE, Ubuntu). SUSE, Ubuntu).
Some systems (Slackware Linux, FreeBSD, OpenBSD) Some systems (Slackware Linux, FreeBSD, OpenBSD)
have a somewhat different scheme of boot scripts. have a somewhat different scheme for boot scripts.
.LP .LP
For each managed service (mail, nfs server, cron, etc.) there is For each managed service (mail, nfs server, cron, etc.), there is
a single startup script located in a specific directory a single startup script located in a specific directory
.RI ( /etc/init.d .RI ( /etc/init.d
in most versions of Linux). in most versions of Linux).
Each of these scripts accepts as a single argument Each of these scripts accepts as a single argument
the word "start" \-\- causing it to start the service, or the word the word "start" (causing it to start the service) or the word
\&"stop" \-\- causing it to stop the service. \&"stop" (causing it to stop the service).
The script may optionally The script may optionally
accept other "convenience" parameters (e.g: "restart", to stop and then accept other "convenience" parameters (e.g,. "restart" to stop and then
start, "status" to display the service status). start, "status" to display the service status, etc.).
Running the script Running the script
without parameters displays the possible arguments. without parameters displays the possible arguments.
.SS Sequencing directories .SS Sequencing directories
To make specific scripts start/stop at specific run-levels and in To make specific scripts start/stop at specific run-levels and in a
specific order, there are \fIsequencing directories\fR. specific order, there are \fIsequencing directories\fR, normally
These of the form \fI/etc/rc[0\-6S].d\fR.
are normally in \fI/etc/rc[0\-6S].d\fR. In each of these directories,
In each of these directories
there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR
directory. directory.
A primary script (usually \fI/etc/rc\fR) is called from A primary script (usually \fI/etc/rc\fR) is called from
.BR inittab (5) .BR inittab (5);
and calls the services scripts via the links in the sequencing directories. this primary script calls each service's script via a link in the
All links with names that begin with \(aqS\(aq are being called with relevant sequencing directory.
Each link whose name begins with \(aqS\(aq is called with
the argument "start" (thereby starting the service). the argument "start" (thereby starting the service).
All links with Each link whose name begins with \(aqK\(aq is called with
names that begin with \(aqK\(aq are being called with the argument "stop" the argument "stop" (thereby stopping the service).
(thereby stopping the service).
To define the starting or stopping order within the same run-level, To define the starting or stopping order within the same run-level,
the names of the links contain order-numbers. the name of a link contains an \fBorder-number\fR.
Also, to make the names clearer, they usually Also, for clarity, the name of a link usually
end with the name of the service they refer to. ends with the name of the service to which it refers.
Example: For example,
the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on
runlevel 2. runlevel 2.
This happens after \fI/etc/rc2.d/S12syslog\fR is run This happens after \fI/etc/rc2.d/S12syslog\fR is run
but before \fI/etc/rc2.d/S90xfs\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. To manage these links is to manage the boot order and run-levels;
However, on many versions of Linux, there are tools to help with this task under many systems, there are tools to help with this task
(e.g: (e.g.,
.BR chkconfig (8)). .BR chkconfig (8)).
.SS Boot configuration .SS Boot configuration
Usually the daemons started may optionally receive command-line options A program that provides a service is often called a "\fBdaemon\fR".
Usually, a daemon may receive various command-line options
and parameters. and parameters.
To allow system administrators to change these To allow a system administrator to change these
parameters without editing the boot scripts themselves, inputs without editing an entire boot script,
configuration files are used. some separate configuration file is used, and is located in a specific
These are located in a specific directory where an associated boot script may find it
directory (\fI/etc/sysconfig\fR on Red Hat systems) and are (\fI/etc/sysconfig\fR on Red Hat systems).
used by the boot scripts.
In older UNIX systems, these files contained the actual command line In older UNIX systems, such a file contained the actual command line
options for the daemons, but in modern Linux systems (and also options for a daemon, but in modern Linux systems (and also
in HP-UX), these files just contain shell variables. in HP-UX), it just contains shell variables.
The boot scripts in \fI/etc/init.d\fR A boot script in \fI/etc/init.d\fR reads and includes its configuration
\fBsource\fR the configuration file (that is, it "\fBsources\fR" its configuration file) and then uses
files, and then use the variable values. the variable values.
.SH FILES .SH FILES
.LP .LP
.IR /etc/init.d/ , .IR /etc/init.d/ ,