]>
Commit | Line | Data |
---|---|---|
fea681da MK |
1 | .\" Written by Oron Peled <oron@actcom.co.il>. |
2 | .\" May be distributed subject to the GPL. | |
3 | .\" | |
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 | |
6891999e MK |
9 | .\" |
10 | .\" Modified 2004-11-03 patch from Martin Schulze <joey@infodeom.org> | |
11 | .\" | |
fea681da MK |
12 | .TH BOOT 7 2002-06-07 "" "Linux Programmer's Manual" |
13 | .SH "NAME" | |
14 | .LP | |
15 | boot\-scripts \- General description of boot sequence | |
16 | .SH "DESCRIPTION" | |
17 | .LP | |
18 | The boot sequence varies in details among systems | |
19 | but can be roughly divided to the following steps: | |
20 | (i) hardware boot, (ii) OS loader, | |
21 | (iii) kernel startup, (iv) init and inittab, | |
22 | (v) boot scripts. | |
23 | We will describe each of these in more detail below. | |
24 | ||
25 | .SS "Hardware\-boot" | |
26 | After power\-on or hard reset, control is given | |
27 | to a program stored on read only memory (normally | |
28 | PROM). In PC we usually call this program the | |
29 | \fBBIOS\fR. | |
30 | ||
31 | This program normally makes a basic self\-test of the | |
32 | machine and accesses non\-volatile memory to read | |
33 | further parameters. This memory in the PC is | |
34 | battery\-backed CMOS memory, so most people | |
35 | refer to it as the \fBCMOS\fR, although outside | |
36 | of the PC world, it is usually called \fBnvram\fR | |
37 | (non\-volatile ram). | |
38 | ||
39 | The parameters stored in the nvram vary between | |
40 | systems, but as a minimum, the hardware boot program | |
41 | should know what is the boot device, or which devices | |
42 | to probe as possible boot devices. | |
43 | ||
44 | Then the hardware boot stage accesses the boot device, | |
45 | loads the OS Loader, which is located on a fixed position | |
46 | on the boot device, and transfers control to it. | |
47 | ||
48 | .TP | |
49 | Note: | |
50 | We do not cover here booting from network. Those who want | |
51 | to investigate this subject may want to research: | |
52 | DHCP, TFTP, PXE, Etherboot. | |
53 | ||
54 | .SS "OS Loader" | |
55 | In PC, the OS Loader is located in the first sector | |
56 | of the boot device \- this is the \fBMBR\fR | |
57 | (Master Boot Record). | |
58 | ||
59 | In most systems, this primary loader is very | |
60 | limited due to various constraints. Even on non\-PC systems | |
61 | there are some limitations to the size and complexity | |
62 | of this loader, but the size limitation of the PC MBR | |
63 | (512 bytes including the partition table) makes it | |
64 | almost impossible to squeeze a full OS Loader into it. | |
65 | ||
66 | Therefore, most operating systems make the primary loader | |
67 | call a secondary OS loader which may be located on | |
68 | a specified disk partition. | |
69 | ||
70 | In Linux the OS loader is normally | |
71 | .BR lilo (8) | |
72 | or | |
73 | .BR grub (8). | |
74 | Both of them may install either as secondary loaders | |
75 | (where the DOS installed MBR points to them), or | |
76 | as a two part loader where they provide special MBR | |
77 | containing the bootstrap code to load the second part | |
78 | of the loader from the root partition. | |
79 | ||
80 | The main job of the OS Loader is to locate the kernel | |
81 | on the disk, load it and run it. Most OS loaders allow | |
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 | |
85 | to the kernel. | |
86 | ||
87 | .SS "Kernel Startup" | |
88 | When the kernel is loaded, it initializes the devices (via | |
89 | their drivers), starts the swapper (it is a "kernel process", | |
90 | called kswapd in modern Linux kernels), and mounts the root | |
91 | file system (/). | |
92 | ||
93 | Some of the parameters that may be passed to the kernel | |
94 | relate to these activities (e.g: You can override the | |
95 | default root file system). For further information | |
96 | on Linux kernel parameters read | |
97 | .BR bootparam (7). | |
98 | ||
99 | Only then the kernel creates the first (user land) | |
100 | process which is numbered 1. This process executes the | |
101 | program | |
102 | .IR /sbin/init , | |
103 | passing any parameters that weren't handled by the kernel already. | |
104 | ||
105 | .SS "init and inittab" | |
106 | When init starts it reads | |
107 | .I /etc/inittab | |
108 | for further instructions. | |
109 | This file defines what should be run in different \fIrun-levels\fR. | |
110 | ||
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.). The administrator may change the current | |
115 | run-level via | |
116 | .BR init (8) | |
117 | and query the current run-level via | |
118 | .BR runlevel (8). | |
119 | ||
120 | However, since it is not convenient to manage individual services | |
121 | by editing this file, inittab only bootstraps a set of scripts | |
122 | that actually start/stop the individual services. | |
123 | ||
124 | .SS "Boot Scripts" | |
125 | ||
126 | .TP | |
127 | Note: | |
128 | The following description applies to SYSV\-R4 based system, which | |
129 | currently covers most commercial Unices (Solaris, HPUX, Irix, Tru64) | |
130 | as well as the major Linux distributions (RedHat, Debian, Mandrake, | |
131 | Suse, Caldera). Some systems (Slackware Linux, FreeBSD, OpenBSD) | |
132 | have a somewhat different scheme of boot scripts. | |
133 | .LP | |
134 | ||
135 | For each managed service (mail, nfs server, cron, etc.) there is | |
136 | a single startup script located in a specific directory | |
137 | .RI ( /etc/init.d | |
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 | |
6891999e | 141 | \&'stop' \-\- causing it to stop the service. The script may optionally |
fea681da MK |
142 | accept other "convenience" parameters (e.g: 'restart', to stop and then |
143 | start, 'status' do display the service status). Running the script | |
144 | without parameters displays the possible arguments. | |
145 | ||
146 | .SS "Sequencing Directories" | |
147 | To make specific scripts start/stop at specific run-levels and in | |
148 | specific order, there are \fIsequencing directories\fR. These | |
149 | are normally in \fB/etc/rc[0\-6S].d\fR. In each of these directories | |
150 | there are links (usually symbolic) to the scripts in the \fIinit.d\fR | |
151 | directory. | |
152 | ||
153 | A primary script (usually \fI/etc/rc\fR) is called from inittab(5) | |
154 | and calls the services scripts via the links in the sequencing directories. | |
155 | All links with names that begin with 'S' are being called with | |
156 | the argument 'start' (thereby starting the service). All links with | |
157 | names that begin with 'K' are being called with the argument 'stop' | |
158 | (thereby stopping the service). | |
159 | ||
160 | To define the starting or stopping order within the same run-level, | |
161 | the names of the links contain order-numbers. | |
162 | Also, to make the names clearer, they usually | |
163 | end with the name of the service they refer to. Example: | |
164 | the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on | |
165 | runlevel 2. This happens after \fI/etc/rc2.d/S12syslog\fR is run | |
166 | but before \fI/etc/rc2.d/S90xfs\fR is run. | |
167 | ||
168 | To manage the boot order and run-levels, we have to manage these links. | |
169 | However, on many versions of Linux, there are tools to help with this task | |
170 | (e.g: | |
171 | .BR chkconfig (8)). | |
172 | ||
173 | .SS "Boot Configuration" | |
174 | Usually the daemons started may optionally receive command line options | |
175 | and parameters. To allow system administrators to change these | |
176 | parameters without editing the boot scripts themselves, | |
177 | configuration files are used. These are located in a specific | |
178 | directory (\fI/etc/sysconfig\fR on RedHat systems) and are | |
179 | used by the boot scripts. | |
180 | ||
181 | In older Unices, these files contained the actual command line | |
182 | options for the daemons, but in modern Linux systems (and also | |
183 | in HPUX), these files just contain shell variables. The boot | |
184 | scripts in \fI/etc/init.d\fR \fBsource\fR the configuration | |
185 | files, and then use the variable values. | |
186 | .SH "FILES" | |
187 | .LP | |
188 | .IR /etc/init.d/ , | |
189 | .IR /etc/rc[S0\-6].d/ . | |
190 | .I /etc/sysconfig/ | |
191 | ||
192 | .SH "SEE ALSO" | |
193 | .BR inittab (5), | |
194 | .BR bootparam (7), | |
195 | .BR init (8), | |
196 | .BR runlevel (8), | |
197 | .BR shutdown (8) |