Provided by: manpages_3.21-1_all bug

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  non-volatile  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
       (non-volatile 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 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.21 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/.