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, Etherboot.

   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 impossible 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 actually 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 sequenc-
       ing 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)