| .\" 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 |
| 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 |
| .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) |