diff options
Diffstat (limited to '')
| -rw-r--r-- | upstream/opensuse-leap-15-6/man7/boot.7 | 230 |
1 files changed, 230 insertions, 0 deletions
diff --git a/upstream/opensuse-leap-15-6/man7/boot.7 b/upstream/opensuse-leap-15-6/man7/boot.7 new file mode 100644 index 00000000..11d00fcf --- /dev/null +++ b/upstream/opensuse-leap-15-6/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-03-12 "Linux man-pages 6.04" +.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 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 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) |