OSDN Git Service

(split) LDP man-pages の original/ を v3.29 に更新。
[linuxjm/LDP_man-pages.git] / original / man7 / boot.7
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
9 .\"
10 .\" Modified 2004-11-03 patch from Martin Schulze <joey@infodrom.org>
11 .\"
12 .TH BOOT 7 2010-09-19 "Linux" "Linux Programmer's Manual"
13 .SH NAME
14 boot-scripts \- General description of boot sequence
15 .SH DESCRIPTION
16 .LP
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,
21 (v) boot scripts.
22 We will describe each of these in more detail below.
23 .SS "Hardware-boot"
24 After power-on or hard reset, control is given
25 to a program stored on read-only memory (normally
26 PROM).
27 In PC we usually call this program the \fBBIOS\fR.
28
29 This program normally makes a basic self-test of the
30 machine and accesses nonvolatile memory to read
31 further parameters.
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
36 (nonvolatile ram).
37
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.
42
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.
46 .TP
47 Note:
48 We do not cover here booting from network.
49 Those who want
50 to investigate this subject may want to research:
51 DHCP, TFTP, PXE, Etherboot.
52 .SS "OS Loader"
53 In PC, the OS Loader is located in the first sector
54 of the boot device \- this is the \fBMBR\fR
55 (Master Boot Record).
56
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.
64
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.
68
69 In Linux the OS loader is normally
70 .BR lilo (8)
71 or
72 .BR grub (8).
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.
78
79 The main job of the OS Loader is to locate the kernel
80 on the disk, load it and run it.
81 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 .SS "Kernel Startup"
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
90 file system (/).
91
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
97 .BR bootparam (7).
98
99 Only then the kernel creates the first (user land)
100 process which is numbered 1.
101 This process executes the
102 program
103 .IR /sbin/init ,
104 passing any parameters that weren't handled by the kernel already.
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.).
115 The administrator may change the current
116 run-level via
117 .BR init (8)
118 and query the current run-level via
119 .BR runlevel (8).
120
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.
124 .SS "Boot Scripts"
125
126 .TP
127 Note:
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,
131 SUSE, Ubuntu).
132 Some systems (Slackware Linux, FreeBSD, OpenBSD)
133 have a somewhat different scheme of boot scripts.
134 .LP
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
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).
145 Running the script
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.
150 These
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
154 directory.
155
156 A primary script (usually \fI/etc/rc\fR) is called from
157 .BR inittab (5)
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).
161 All links with
162 names that begin with \(aqK\(aq are being called with the argument "stop"
163 (thereby stopping the service).
164
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.
169 Example:
170 the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on
171 runlevel 2.
172 This happens after \fI/etc/rc2.d/S12syslog\fR is run
173 but before \fI/etc/rc2.d/S90xfs\fR is run.
174
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
177 (e.g:
178 .BR chkconfig (8)).
179 .SS "Boot Configuration"
180 Usually the daemons started may optionally receive command-line options
181 and parameters.
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.
188
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.
195 .SH FILES
196 .LP
197 .IR /etc/init.d/ ,
198 .IR /etc/rc[S0\-6].d/ ,
199 .I /etc/sysconfig/
200 .SH SEE ALSO
201 .BR inittab (5),
202 .BR bootparam (7),
203 .BR init (8),
204 .BR runlevel (8),
205 .BR shutdown (8)