summaryrefslogtreecommitdiffstats
path: root/man7/boot.7
diff options
context:
space:
mode:
Diffstat (limited to 'man7/boot.7')
-rw-r--r--man7/boot.7230
1 files changed, 230 insertions, 0 deletions
diff --git a/man7/boot.7 b/man7/boot.7
new file mode 100644
index 0000000..f69e8c1
--- /dev/null
+++ b/man7/boot.7
@@ -0,0 +1,230 @@
+.\" Written by Oron Peled <oron@actcom.co.il>.
+.\"
+.\" SPDX-License-Identifier: GPL-1.0-or-later
+.\"
+.\" 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 2023-07-08 "Linux man-pages 6.05.01"
+.SH NAME
+boot \- System bootup process based on UNIX System V Release 4
+.SH DESCRIPTION
+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) 5
+hardware
+.IP (2)
+operating system (OS) loader
+.IP (3)
+kernel
+.IP (4)
+root user-space process (\fIinit\fR and \fIinittab\fR)
+.IP (5)
+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
+.BR grub (8)
+(an alternative is
+.BR lilo (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 run level, 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
+.B S
+is single-user mode,
+and run level
+.B 2
+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 \[aq]S\[aq] is called with
+the argument "start" (thereby starting the service).
+Each link whose name begins with \[aq]K\[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
+.BR sendmail (8)
+service on
+run level 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
+.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)