man7/boot.7

   1 .\" Written by Oron Peled <oron@actcom.co.il>.
   2 .\"
   3 .\" %%%LICENSE_START(GPL_NOVERSION_ONELINE)
   4 .\" May be distributed subject to the GPL.
   5 .\" %%%LICENSE_END
   6 .\"
   7 .\" I tried to be as much generic in the description as possible:
   8 .\" - General boot sequence is applicable to almost any
   9 .\" OS/Machine (DOS/PC, Linux/PC, Solaris/SPARC, CMS/S390)
  10 .\" - kernel and init(1) is applicable to almost any UNIX/Linux
  11 .\" - boot scripts are applicable to SYSV-R4 based UNIX/Linux
  12 .\"
  13 .\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org>
  14 .\"
  15 .TH BOOT 7 2015-03-11 "Linux" "Linux Programmer's Manual"
  16 .SH NAME
  17 boot \- System bootup process based on UNIX System V Release 4
  18 .SH DESCRIPTION
  19 .LP
  20 The \fBbootup process\fR (or "\fBboot sequence\fR") varies in details
  21 among systems, but can be roughly divided into phases controlled by
  22 the following components:
  23 .IP 1. 4
  24 hardware
  25 .IP 2. 4
  26 operating system (OS) loader
  27 .IP 3. 4
  28 kernel
  29 .IP 4. 4
  30 root user-space process (\fIinit\fR and \fIinittab\fR)
  31 .IP 5. 4
  32 boot scripts
  33 .PP
  34 Each of these is described below in more detail.
  35 .SS Hardware
  36 After power-on or hard reset, control is given
  37 to a program stored in read-only memory (normally
  38 PROM); for historical reasons involving the personal
  39 computer, this program is often called "the \fBBIOS\fR".
  40
  41 This program normally performs a basic self-test of the
  42 machine and accesses nonvolatile memory to read
  43 further parameters.
  44 This memory in the PC is
  45 battery-backed CMOS memory, so most people
  46 refer to it as "the \fBCMOS\fR"; outside
  47 of the PC world, it is usually called "the \fBNVRAM\fR"
  48 (nonvolatile RAM).
  49
  50 The parameters stored in the NVRAM vary among
  51 systems, but as a minimum, they should specify
  52 which device can supply an OS loader, or at least which
  53 devices may be probed for one; such a device is known as "the
  54 \fBboot device\fR".
  55 The hardware boot stage loads the OS loader from a fixed position on
  56 the boot device, and then transfers control to it.
  57 .TP
  58 Note:
  59 The device from which the OS loader is read may be attached via a network, in which
  60 case the details of booting are further specified by protocols such as
  61 DHCP, TFTP, PXE, Etherboot, etc.
  62 .SS OS loader
  63 The main job of the OS loader is to locate the kernel
  64 on some device, load it, and run it.
  65 Most OS loaders allow
  66 interactive use, in order to enable specification of an alternative
  67 kernel (maybe a backup in case the one last compiled
  68 isn't functioning) and to pass optional parameters
  69 to the kernel.
  70
  71 In a traditional PC, the OS loader is located in the initial 512-byte block
  72 of the boot device; this block is known as "the \fBMBR\fR"
  73 (Master Boot Record).
  74
  75 In most systems, the OS loader is very
  76 limited due to various constraints.
  77 Even on non-PC systems,
  78 there are some limitations on the size and complexity
  79 of this loader, but the size limitation of the PC MBR
  80 (512 bytes, including the partition table) makes it
  81 almost impossible to squeeze much functionality into it.
  82
  83 Therefore, most systems split the role of loading the OS between
  84 a primary OS loader and a secondary OS loader; this secondary
  85 OS loader may be located within a larger portion of persistent
  86 storage, such as a disk partition.
  87
  88 In Linux, the OS loader is often either
  89 .BR lilo (8)
  90 or
  91 .BR grub (8).
  92 .SS Kernel
  93 When the kernel is loaded, it initializes various components of
  94 the computer and operating system; each portion of software
  95 responsible for such a task is usually consider "a \fBdriver\fR" for
  96 the applicable component.
  97 The kernel starts the virtual memory
  98 swapper (it is a kernel process, called "kswapd" in a modern Linux
  99 kernel), and mounts some filesystem at the root path,
 100 .IR / .
 101
 102 Some of the parameters that may be passed to the kernel
 103 relate to these activities (for example, the default root filesystem
 104 can be overridden); for further information
 105 on Linux kernel parameters, read
 106 .BR bootparam (7).
 107
 108 Only then does the kernel create the initial userland
 109 process, which is given the number 1 as its
 110 .B PID
 111 (process ID).
 112 Traditionally, this process executes the
 113 program
 114 .IR /sbin/init ,
 115 to which are passed the parameters that haven't already been
 116 handled by the kernel.
 117 .SS Root user-space process
 118 .TP
 119 Note:
 120 The following description applies to an OS based on UNIX System V Release 4.
 121 However, a number of widely used systems have adopted a related but
 122 fundamentally different approach known as
 123 .BR systemd (1),
 124 for which the bootup process is detailed in its associated
 125 .BR bootup (7).
 126 .LP
 127 When
 128 .I /sbin/init
 129 starts, it reads
 130 .I /etc/inittab
 131 for further instructions.
 132 This file defines what should be run when the
 133 .I /sbin/init
 134 program is instructed to enter a particular \fIrun-level\fR, giving
 135 the administrator an easy way to establish an environment
 136 for some usage; each run-level is associated with a set of services
 137 (for example, run-level \fBS\fR is \fIsingle-user\fR mode,
 138 and run-level \fB2\fR entails running most network services).
 139
 140 The administrator may change the current
 141 run-level via
 142 .BR init (1),
 143 and query the current run-level via
 144 .BR runlevel (8).
 145
 146 However, since it is not convenient to manage individual services
 147 by editing this file,
 148 .I /etc/inittab
 149 only bootstraps a set of scripts
 150 that actually start/stop the individual services.
 151 .SS Boot scripts
 152 .TP
 153 Note:
 154 The following description applies to an OS based on UNIX System V Release 4.
 155 However, a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD)
 156 have a somewhat different scheme for boot scripts.
 157 .LP
 158 For each managed service (mail, nfs server, cron, etc.), there is
 159 a single startup script located in a specific directory
 160 .RI ( /etc/init.d
 161 in most versions of Linux).
 162 Each of these scripts accepts as a single argument
 163 the word "start" (causing it to start the service) or the word
 164 \&"stop" (causing it to stop the service).
 165 The script may optionally
 166 accept other "convenience" parameters (e.g., "restart" to stop and then
 167 start, "status" to display the service status, etc.).
 168 Running the script
 169 without parameters displays the possible arguments.
 170 .SS Sequencing directories
 171 To make specific scripts start/stop at specific run-levels and in a
 172 specific order, there are \fIsequencing directories\fR, normally
 173 of the form  \fI/etc/rc[0\-6S].d\fR.
 174 In each of these directories,
 175 there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR
 176 directory.
 177
 178 A primary script (usually \fI/etc/rc\fR) is called from
 179 .BR inittab (5);
 180 this primary script calls each service's script via a link in the
 181 relevant sequencing directory.
 182 Each link whose name begins with \(aqS\(aq is called with
 183 the argument "start" (thereby starting the service).
 184 Each link whose name begins with \(aqK\(aq is called with
 185 the argument "stop" (thereby stopping the service).
 186
 187 To define the starting or stopping order within the same run-level,
 188 the name of a link contains an \fBorder-number\fR.
 189 Also, for clarity, the name of a link usually
 190 ends with the name of the service to which it refers.
 191 For example,
 192 the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on
 193 runlevel 2.
 194 This happens after \fI/etc/rc2.d/S12syslog\fR is run
 195 but before \fI/etc/rc2.d/S90xfs\fR is run.
 196
 197 To manage these links is to manage the boot order and run-levels;
 198 under many systems, there are tools to help with this task
 199 (e.g.,
 200 .BR chkconfig (8)).
 201 .SS Boot configuration
 202 A program that provides a service is often called a "\fBdaemon\fR".
 203 Usually, a daemon may receive various command-line options
 204 and parameters.
 205 To allow a system administrator to change these
 206 inputs without editing an entire boot script,
 207 some separate configuration file is used, and is located in a specific
 208 directory where an associated boot script may find it
 209 (\fI/etc/sysconfig\fR on older Red Hat systems).
 210
 211 In older UNIX systems, such a file contained the actual command line
 212 options for a daemon, but in modern Linux systems (and also
 213 in HP-UX), it just contains shell variables.
 214 A boot script in \fI/etc/init.d\fR reads and includes its configuration
 215 file (that is, it "\fBsources\fR" its configuration file) and then uses
 216 the variable values.
 217 .SH FILES
 218 .LP
 219 .IR /etc/init.d/ ,
 220 .IR /etc/rc[S0\-6].d/ ,
 221 .I /etc/sysconfig/
 222 .SH SEE ALSO
 223 .BR init (1),
 224 .BR systemd (1),
 225 .BR inittab (5),
 226 .BR bootparam (7),
 227 .BR bootup (7),
 228 .BR runlevel (8),
 229 .BR shutdown (8)