Man Pages

boot(7) - phpMan boot(7) - phpMan

Command: man perldoc info search(apropos)  


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) hard-
       ware 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 posi-
       tion 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 pro-
       gram /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  dif-
       ferent 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  com-
              mercial  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 dif-
              ferent 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  dis-
       play 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 directo-
       ries.  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-num-
       bers.   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 admin-
       istrators 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.22 of the Linux man-pages project.  A description of the project, and informa-
       tion about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/.



Linux                             2007-06-03                           BOOT(7)