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) operating system (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 filesystem (/).

       Some of the parameters that may be passed to the kernel relate to these activities (e.g: You can override
       the default root filesystem).  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).  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 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.54 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                                              2010-09-19                                            BOOT(7)