BOOT(7) 						     Linux Programmer's Manual							   BOOT(7)

NAME

       boot-scripts - General description of boot sequence

DESCRIPTION

       The  boot  sequence  varies  in details among systems but can be roughly divided to the following steps: (i) hardware boot, (ii) OS loader,
       (iii) kernel startup, (iv) init and inittab, (v) boot scripts.  We will describe each of these in more detail below.

   Hardware-boot
       After power-on or hard reset, control is given to a program stored on read-only memory (normally PROM).	In PC we usually call this program
       the BIOS.

       This  program  normally	makes a basic self-test of the machine and accesses nonvolatile memory to read further parameters.  This memory in
       the PC is battery-backed CMOS memory, so most people refer to it as the CMOS, although outside of the PC world, it is usually called  nvram
       (nonvolatile ram).

       The  parameters	stored in the nvram vary between systems, but as a minimum, the hardware boot program should know what is the boot device,
       or which devices to probe as possible boot devices.

       Then the hardware boot stage accesses the boot device, loads the OS Loader, which is located on a fixed position on the	boot  device,  and
       transfers control to it.

       Note:  We do not cover here booting from network.  Those who want to investigate this subject may want to research: DHCP, TFTP, PXE, Ether-
	      boot.

   OS Loader
       In PC, the OS Loader is located in the first sector of the boot device - this is the MBR (Master Boot Record).

       In most systems, this primary loader is very limited due to various constraints.  Even on non-PC systems there are some limitations to  the
       size  and complexity of this loader, but the size limitation of the PC MBR (512 bytes including the partition table) makes it almost impos-
       sible to squeeze a full OS Loader into it.

       Therefore, most operating systems make the primary loader call a secondary OS loader which may be located on a specified disk partition.

       In Linux the OS loader is normally lilo(8) or grub(8).  Both of them may install either as secondary loaders (where the DOS  installed  MBR
       points to them), or as a two part loader where they provide special MBR containing the bootstrap code to load the second part of the loader
       from the root partition.

       The main job of the OS Loader is to locate the kernel on the disk, load it and run it.  Most OS loaders allow interactive  use,	to  enable
       specification of alternative kernel (maybe a backup in case the last compiled one isn't functioning) and to pass optional parameters to the
       kernel.

   Kernel Startup
       When the kernel is loaded, it initializes the devices (via their drivers), starts the swapper (it is a "kernel process", called	kswapd	in
       modern Linux kernels), and mounts the root file system (/).

       Some  of  the  parameters that may be passed to the kernel relate to these activities (e.g: You can override the default root file system).
       For further information on Linux kernel parameters read bootparam(7).

       Only then the kernel creates the first (user land) process which is numbered 1.	This process executes the program /sbin/init, passing  any
       parameters that weren't handled by the kernel already.

   init and inittab
       When init starts it reads /etc/inittab for further instructions.  This file defines what should be run in different run-levels.

       This gives the system administrator an easy management scheme, where each run-level is associated with a set of services (e.g: S is single-
       user, on 2 most network services start, etc.).  The administrator may change the current run-level via init(8) and query the  current  run-
       level via runlevel(8).

       However, since it is not convenient to manage individual services by editing this file, inittab only bootstraps a set of scripts that actu-
       ally start/stop the individual services.

   Boot Scripts
       Note:  The following description applies to System V release 4 based system, which currently covers most commercial Unix systems  (Solaris,
	      HP-UX,  Irix,  Tru64)  as  well as the major Linux distributions (RedHat, Debian, Mandrake, Suse, Caldera).  Some systems (Slackware
	      Linux, FreeBSD, OpenBSD) have a somewhat different scheme of boot scripts.

       For each managed service (mail, nfs server, cron, etc.) there is a single startup script located in a specific  directory  (/etc/init.d	in
       most  versions  of  Linux).  Each of these scripts accepts as a single argument the word "start" -- causing it to start the service, or the
       word "stop" -- causing it to stop the service.  The script may optionally accept other "convenience" parameters (e.g:  "restart",  to  stop
       and then start, "status" do display the service status).  Running the script without parameters displays the possible arguments.

   Sequencing Directories
       To  make specific scripts start/stop at specific run-levels and in specific order, there are sequencing directories.  These are normally in
       /etc/rc[0-6S].d.  In each of these directories there are links (usually symbolic) to the scripts in the /etc/init.d directory.

       A primary script (usually /etc/rc) is called from inittab(5) and calls the services scripts via the links in  the  sequencing  directories.
       All  links  with names that begin with 'S' are being called with the argument "start" (thereby starting the service).  All links with names
       that begin with 'K' are being called with the argument "stop" (thereby stopping the service).

       To define the starting or stopping order within the same run-level, the names of the links contain order-numbers.  Also, to make the  names
       clearer, they usually end with the name of the service they refer to.  Example: the link /etc/rc2.d/S80sendmail starts the sendmail service
       on runlevel 2.  This happens after /etc/rc2.d/S12syslog is run but before /etc/rc2.d/S90xfs is run.

       To manage the boot order and run-levels, we have to manage these links.	However, on many versions of Linux, there are tools to	help  with
       this task (e.g: chkconfig(8)).

   Boot Configuration
       Usually	the  daemons  started  may optionally receive command-line options and parameters.  To allow system administrators to change these
       parameters without editing the boot scripts themselves,	configuration  files  are  used.   These  are  located	in  a  specific  directory
       (/etc/sysconfig on RedHat systems) and are used by the boot scripts.

       In  older Unix systems, these files contained the actual command line options for the daemons, but in modern Linux systems (and also in HP-
       UX), these files just contain shell variables.  The boot scripts in /etc/init.d source the configuration files, and then use  the  variable
       values.

FILES

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

SEE ALSO

       inittab(5), bootparam(7), init(8), runlevel(8), shutdown(8)

COLOPHON

       This  page is part of release 3.25 of the Linux man-pages project.  A description of the project, and information about reporting bugs, can
       be found at http://www.kernel.org/doc/man-pages/.

Linux								    2007-06-03								   BOOT(7)