Provided by: manpages_3.35-0.1ubuntu1_all bug


       boot-scripts - General description of boot sequence


       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.

       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,

   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 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
              systems, which currently covers  most  commercial  UNIX  systems
              (Solaris,  HP-UX,  Irix,  Tru64)  as  well  as  the  major Linux
              distributions (Red Hat, Debian, Mandriva, SUSE,  Ubuntu).   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 Red Hat 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


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


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


       This page is part of release 3.35 of the Linux  man-pages  project.   A
       description  of  the project, and information about reporting bugs, can
       be found at