diff options
Diffstat (limited to 'man7/boot.7')
| -rw-r--r-- | man7/boot.7 | 230 |
1 files changed, 0 insertions, 230 deletions
diff --git a/man7/boot.7 b/man7/boot.7 deleted file mode 100644 index b66f6596e..000000000 --- a/man7/boot.7 +++ /dev/null @@ -1,230 +0,0 @@ -.\" 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 (date) "Linux man-pages (unreleased)" -.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 -.P -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". -.P -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). -.P -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. -.P -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). -.P -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. -.P -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. -.P -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 / . -.P -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). -.P -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). -.P -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). -.P -The administrator may change the current run level via -.BR init (1), -and query the current run level via -.BR runlevel (8). -.P -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. -.P -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. -.P -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). -.P -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. -.P -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). -.P -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) |