Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for boot (redhat section 7)

BOOT(7) 										  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 fol-
       lowing steps: (i) hardware boot, (ii) OS loader, (iii) kernel startup, (iv) init and init-
       tab, (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  sub-
	      ject 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 SYSV-R4 based system, which currently covers
	      most commercial Unices (Solaris, HPUX, Irix, Tru64) as well as the major Linux dis-
	      tributions  (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 direc-
       tories 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 argument 'stop' (thereby stopping
       the service).

       To assert order withing the same run-level, the names of the links contains order-numbers.
       Also, to make the names clearer, they usually ends with the name of the service they refer
       to.  Example: the link /etc/rc2.d/S80sendmail is starting the sendmail service on runlevel
       2. This is happening 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  Unices,  these files contained the actual command line options for the daemons,
       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)


All times are GMT -4. The time now is 01:23 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
UNIX.COM Login
Username:
Password:  
Show Password