1 .\" Written by Oron Peled <oron@actcom.co.il>.
2 .\" May be distributed subject to the GPL.
4 .\" I tried to be as much generic in the description as possible:
5 .\" - General boot sequence is applicable to almost any
6 .\" OS/Machine (DOS/PC, Linux/PC, Solaris/SPARC, CMS/S390)
7 .\" - kernel and init(8) is applicable to almost any UNIX/Linux
8 .\" - boot scripts are applicable to SYSV-R4 based UNIX/Linux
10 .\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org>
12 .TH BOOT 7 2010-09-19 "Linux" "Linux Programmer's Manual"
14 boot-scripts \- General description of boot sequence
17 The boot sequence varies in details among systems
18 but can be roughly divided to the following steps:
19 (i) hardware boot, (ii) OS loader,
20 (iii) kernel startup, (iv) init and inittab,
22 We will describe each of these in more detail below.
24 After power-on or hard reset, control is given
25 to a program stored on read-only memory (normally
27 In PC we usually call this program the \fBBIOS\fR.
29 This program normally makes a basic self-test of the
30 machine and accesses nonvolatile memory to read
32 This memory in the PC is
33 battery-backed CMOS memory, so most people
34 refer to it as the \fBCMOS\fR, although outside
35 of the PC world, it is usually called \fBnvram\fR
38 The parameters stored in the nvram vary between
39 systems, but as a minimum, the hardware boot program
40 should know what is the boot device, or which devices
41 to probe as possible boot devices.
43 Then the hardware boot stage accesses the boot device,
44 loads the OS Loader, which is located on a fixed position
45 on the boot device, and transfers control to it.
48 We do not cover here booting from network.
50 to investigate this subject may want to research:
51 DHCP, TFTP, PXE, Etherboot.
53 In PC, the OS Loader is located in the first sector
54 of the boot device \- this is the \fBMBR\fR
57 In most systems, this primary loader is very
58 limited due to various constraints.
59 Even on non-PC systems
60 there are some limitations to the size and complexity
61 of this loader, but the size limitation of the PC MBR
62 (512 bytes including the partition table) makes it
63 almost impossible to squeeze a full OS Loader into it.
65 Therefore, most operating systems make the primary loader
66 call a secondary OS loader which may be located on
67 a specified disk partition.
69 In Linux the OS loader is normally
73 Both of them may install either as secondary loaders
74 (where the DOS installed MBR points to them), or
75 as a two part loader where they provide special MBR
76 containing the bootstrap code to load the second part
77 of the loader from the root partition.
79 The main job of the OS Loader is to locate the kernel
80 on the disk, load it and run it.
82 interactive use, to enable specification of alternative
83 kernel (maybe a backup in case the last compiled one
84 isn't functioning) and to pass optional parameters
87 When the kernel is loaded, it initializes the devices (via
88 their drivers), starts the swapper (it is a "kernel process",
89 called kswapd in modern Linux kernels), and mounts the root
92 Some of the parameters that may be passed to the kernel
93 relate to these activities (e.g: You can override the
94 default root file system).
95 For further information
96 on Linux kernel parameters read
99 Only then the kernel creates the first (user land)
100 process which is numbered 1.
101 This process executes the
104 passing any parameters that weren't handled by the kernel already.
105 .SS "init and inittab"
106 When init starts it reads
108 for further instructions.
109 This file defines what should be run in different \fIrun-levels\fR.
111 This gives the system administrator an easy management scheme, where
112 each run-level is associated with a set of services (e.g:
113 \fBS\fR is \fIsingle-user\fR, on \fB2\fR most network
114 services start, etc.).
115 The administrator may change the current
118 and query the current run-level via
121 However, since it is not convenient to manage individual services
122 by editing this file, inittab only bootstraps a set of scripts
123 that actually start/stop the individual services.
128 The following description applies to System V release 4-based systems, which
129 currently covers most commercial UNIX systems (Solaris, HP-UX, Irix, Tru64)
130 as well as the major Linux distributions (Red Hat, Debian, Mandrake,
132 Some systems (Slackware Linux, FreeBSD, OpenBSD)
133 have a somewhat different scheme of boot scripts.
135 For each managed service (mail, nfs server, cron, etc.) there is
136 a single startup script located in a specific directory
138 in most versions of Linux).
139 Each of these scripts accepts as a single argument
140 the word "start" \-\- causing it to start the service, or the word
141 \&"stop" \-\- causing it to stop the service.
142 The script may optionally
143 accept other "convenience" parameters (e.g: "restart", to stop and then
144 start, "status" do display the service status).
146 without parameters displays the possible arguments.
147 .SS "Sequencing Directories"
148 To make specific scripts start/stop at specific run-levels and in
149 specific order, there are \fIsequencing directories\fR.
151 are normally in \fI/etc/rc[0\-6S].d\fR.
152 In each of these directories
153 there are links (usually symbolic) to the scripts in the \fI/etc/init.d\fR
156 A primary script (usually \fI/etc/rc\fR) is called from
158 and calls the services scripts via the links in the sequencing directories.
159 All links with names that begin with \(aqS\(aq are being called with
160 the argument "start" (thereby starting the service).
162 names that begin with \(aqK\(aq are being called with the argument "stop"
163 (thereby stopping the service).
165 To define the starting or stopping order within the same run-level,
166 the names of the links contain order-numbers.
167 Also, to make the names clearer, they usually
168 end with the name of the service they refer to.
170 the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on
172 This happens after \fI/etc/rc2.d/S12syslog\fR is run
173 but before \fI/etc/rc2.d/S90xfs\fR is run.
175 To manage the boot order and run-levels, we have to manage these links.
176 However, on many versions of Linux, there are tools to help with this task
179 .SS "Boot Configuration"
180 Usually the daemons started may optionally receive command-line options
182 To allow system administrators to change these
183 parameters without editing the boot scripts themselves,
184 configuration files are used.
185 These are located in a specific
186 directory (\fI/etc/sysconfig\fR on Red Hat systems) and are
187 used by the boot scripts.
189 In older UNIX systems, these files contained the actual command line
190 options for the daemons, but in modern Linux systems (and also
191 in HP-UX), these files just contain shell variables.
192 The boot scripts in \fI/etc/init.d\fR
193 \fBsource\fR the configuration
194 files, and then use the variable values.
198 .IR /etc/rc[S0\-6].d/ ,