boot - 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) 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  bat-
       tery-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 parti-
       tion 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 ser-
       vices 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  indi-
       vidual services.


   Boot Scripts
       Note:  The  following  description applies to SYSV-R4 based system, which currently
              covers most commercial Unices (Solaris, HPUX, 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  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  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  argu-
       ment ’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/S80send-
       mail  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:  chkcon-
       fig(8)).


   Boot Configuration
       Usually the daemons started may optionally receive command line options and parame-
       ters. To allow system administrators to change these parameters without editing the
       boot  scripts themselves, configuration files are used. These are located in a spe-
       cific directory (/etc/sysconfig on  RedHat  systems)  and  are  used  by  the  boot
       scripts.

       In older Unices, these files contained the actual command line options for the dae-
       mons, but in modern Linux systems (and also in  HPUX),  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)



                                  2002-06-07                           BOOT(7)

Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2008-08-28 11:45 @38.103.63.61 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
Valid XHTML 1.0!Valid CSS!