1BOOT(7)                    Linux Programmer's Manual                   BOOT(7)
2
3
4

NAME

6       boot-scripts - General description of boot sequence
7

DESCRIPTION

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

FILES

152       /etc/init.d/, /etc/rc[S0-6].d/.  /etc/sysconfig/
153
154

SEE ALSO

156       inittab(5), bootparam(7), init(8), runlevel(8), shutdown(8)
157
158
159
160                                  2002-06-07                           BOOT(7)
Impressum