1BOOT(7) Linux Programmer's Manual BOOT(7)
2
6 boot-scripts - General description of boot sequence
7
9 The boot sequence varies in details among systems but can be roughly
10 divided to the following steps: (i) hardware boot, (ii) OS loader,
11 (iii) kernel startup, (iv) init and inittab, (v) boot scripts. We will
12 describe each of these in more detail below.
13 Hardware-boot
15 After power-on or hard reset, control is given to a program stored on
16 read-only memory (normally PROM). In PC we usually call this program
17 the BIOS.
18 This program normally makes a basic self-test of the machine and
20 accesses nonvolatile memory to read further parameters. This memory in
21 the PC is battery-backed CMOS memory, so most people refer to it as the
22 CMOS, although outside of the PC world, it is usually called nvram
23 (nonvolatile ram).
24 The parameters stored in the nvram vary between systems, but as a mini‐
26 mum, the hardware boot program should know what is the boot device, or
27 which devices to probe as possible boot devices.
28 Then the hardware boot stage accesses the boot device, loads the OS
30 Loader, which is located on a fixed position on the boot device, and
31 transfers control to it.
32 Note: We do not cover here booting from network. Those who want to
34 investigate this subject may want to research: DHCP, TFTP, PXE,
35 Etherboot.
36 OS Loader
38 In PC, the OS Loader is located in the first sector of the boot device
39 - this is the MBR (Master Boot Record).
40 In most systems, this primary loader is very limited due to various
42 constraints. Even on non-PC systems there are some limitations to the
43 size and complexity of this loader, but the size limitation of the PC
44 MBR (512 bytes including the partition table) makes it almost impossi‐
45 ble to squeeze a full OS Loader into it.
46 Therefore, most operating systems make the primary loader call a sec‐
48 ondary OS loader which may be located on a specified disk partition.
49 In Linux the OS loader is normally lilo(8) or grub(8). Both of them
51 may install either as secondary loaders (where the DOS installed MBR
52 points to them), or as a two part loader where they provide special MBR
53 containing the bootstrap code to load the second part of the loader
54 from the root partition.
55 The main job of the OS Loader is to locate the kernel on the disk, load
57 it and run it. Most OS loaders allow interactive use, to enable speci‐
58 fication of alternative kernel (maybe a backup in case the last com‐
59 piled one isn't functioning) and to pass optional parameters to the
60 kernel.
61 Kernel Startup
63 When the kernel is loaded, it initializes the devices (via their driv‐
64 ers), starts the swapper (it is a "kernel process", called kswapd in
65 modern Linux kernels), and mounts the root file system (/).
66 Some of the parameters that may be passed to the kernel relate to these
68 activities (e.g: You can override the default root file system). For
69 further information on Linux kernel parameters read bootparam(7).
70 Only then the kernel creates the first (user land) process which is
72 numbered 1. This process executes the program /sbin/init, passing any
73 parameters that weren't handled by the kernel already.
74 init and inittab
76 When init starts it reads /etc/inittab for further instructions. This
77 file defines what should be run in different run-levels.
78 This gives the system administrator an easy management scheme, where
80 each run-level is associated with a set of services (e.g: S is single-
81 user, on 2 most network services start, etc.). The administrator may
82 change the current run-level via init(8) and query the current run-
83 level via runlevel(8).
84 However, since it is not convenient to manage individual services by
86 editing this file, inittab only bootstraps a set of scripts that actu‐
87 ally start/stop the individual services.
88 Boot Scripts
90 Note: The following description applies to System V release 4 based
91 system, which currently covers most commercial Unix systems
92 (Solaris, HP-UX, Irix, Tru64) as well as the major Linux distri‐
93 butions (RedHat, Debian, Mandrake, Suse, Caldera). Some systems
94 (Slackware Linux, FreeBSD, OpenBSD) have a somewhat different
95 scheme of boot scripts.
96 For each managed service (mail, nfs server, cron, etc.) there is a sin‐
98 gle startup script located in a specific directory (/etc/init.d in most
99 versions of Linux). Each of these scripts accepts as a single argument
100 the word "start" -- causing it to start the service, or the word "stop"
101 -- causing it to stop the service. The script may optionally accept
102 other "convenience" parameters (e.g: "restart", to stop and then start,
103 "status" do display the service status). Running the script without
104 parameters displays the possible arguments.
105 Sequencing Directories
107 To make specific scripts start/stop at specific run-levels and in spe‐
108 cific order, there are sequencing directories. These are normally in
109 /etc/rc[0-6S].d. In each of these directories there are links (usually
110 symbolic) to the scripts in the /etc/init.d directory.
111 A primary script (usually /etc/rc) is called from inittab(5) and calls
113 the services scripts via the links in the sequencing directories. All
114 links with names that begin with 'S' are being called with the argument
115 "start" (thereby starting the service). All links with names that
116 begin with 'K' are being called with the argument "stop" (thereby stop‐
117 ping the service).
118 To define the starting or stopping order within the same run-level, the
120 names of the links contain order-numbers. Also, to make the names
121 clearer, they usually end with the name of the service they refer to.
122 Example: the link /etc/rc2.d/S80sendmail starts the sendmail service on
123 runlevel 2. This happens after /etc/rc2.d/S12syslog is run but before
124 /etc/rc2.d/S90xfs is run.
125 To manage the boot order and run-levels, we have to manage these links.
127 However, on many versions of Linux, there are tools to help with this
128 task (e.g: chkconfig(8)).
129 Boot Configuration
131 Usually the daemons started may optionally receive command-line options
132 and parameters. To allow system administrators to change these parame‐
133 ters without editing the boot scripts themselves, configuration files
134 are used. These are located in a specific directory (/etc/sysconfig on
135 RedHat systems) and are used by the boot scripts.
136 In older Unix systems, these files contained the actual command line
138 options for the daemons, but in modern Linux systems (and also in HP-
139 UX), these files just contain shell variables. The boot scripts in
140 /etc/init.d source the configuration files, and then use the variable
141 values.
142
144 /etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/
145
147 inittab(5), bootparam(7), init(8), runlevel(8), shutdown(8)
148
150 This page is part of release 3.25 of the Linux man-pages project. A
151 description of the project, and information about reporting bugs, can
152 be found at http://www.kernel.org/doc/man-pages/.
153Linux 2007-06-03 BOOT(7)