boot

       The  bootup  process  (or "boot sequence") varies in details among sys-
       tems, but can be roughly divided into phases controlled by the  follow-
       ing components:

       1.  hardware

       2.  operating system (OS) loader

       3.  kernel

       4.  root user-space process (init and inittab)

       5.  boot scripts

       Each of these is described below in more detail.

   Hardware
       After  power-on  or hard reset, control is given to a program stored in
       read-only memory (normally PROM); for historical reasons involving  the
       personal computer, this program is often called "the BIOS".

       This  program  normally  performs  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"; outside of the PC world, it is usually called  "the  NVRAM"
       (nonvolatile RAM).

       The  parameters  stored in the NVRAM vary among systems, but as a mini-
       mum, they should specify which device can supply an OS  loader,  or  at
       least  which  devices  may be probed for one; such a device is known as
       "the boot device".  The hardware boot stage loads the OS loader from  a
       fixed position on the boot device, and then transfers control to it.

       Note:  The  device from which the OS loader is read may be attached via
              a network, in which case the  details  of  booting  are  further
              specified by protocols such as DHCP, TFTP, PXE, Etherboot, etc.

   OS loader
       The  main  job of the OS loader is to locate the kernel on some device,
       load it, and run it.  Most OS loaders allow interactive use,  in  order
       to  enable  specification  of  an alternative kernel (maybe a backup in
       case the one last compiled isn't  functioning)  and  to  pass  optional
       parameters to the kernel.

       In  a  traditional PC, the OS loader is located in the initial 512-byte
       block of the boot device; this block is known as "the MBR" (Master Boot
       Record).

       In  most  systems,  the  OS  loader is very limited due to various con-
       straints.  Even on non-PC systems, there are some  limitations  on  the
       size  and  complexity of this loader, but the size limitation of the PC
       MBR (512 bytes, including the partition table) makes it almost impossi-
       ble to squeeze much functionality into it.

       process, called "kswapd" in a modern Linux  kernel),  and  mounts  some
       filesystem at the root path, /.

       Some of the parameters that may be passed to the kernel relate to these
       activities (for example, the default root filesystem  can  be  overrid-
       den);  for  further  information on Linux kernel parameters, read boot-
       param(7).

       Only then does the kernel create the initial userland process, which is
       given  the  number  1  as  its  PID  (process ID).  Traditionally, this
       process executes the program /sbin/init, to which are passed the param-
       eters that haven't already been handled by the kernel.

   Root user-space process
       Note:  The  following description applies to an OS based on UNIX System
              V Release 4.  However, a number  of  widely  used  systems  have
              adopted  a related but fundamentally different approach known as
              systemd(1), for which the bootup  process  is  detailed  in  its
              associated bootup(7).

       When /sbin/init starts, it reads /etc/inittab for further instructions.
       This file defines what should be run when  the  /sbin/init  program  is
       instructed to enter a particular run-level, giving the administrator an
       easy way to establish an environment for some usage; each run-level  is
       associated  with a set of services (for example, run-level S is single-
       user mode, and run-level 2 entails running most network services).

       The administrator may change the current  run-level  via  init(1),  and
       query the current run-level via runlevel(8).

       However,  since  it  is not convenient to manage individual services by
       editing this file, /etc/inittab only bootstraps a set of  scripts  that
       actually start/stop the individual services.

   Boot scripts
       Note:  The  following description applies to an OS based on UNIX System
              V Release 4.  However, a number of widely used  systems  (Slack-
              ware  Linux,  FreeBSD, OpenBSD) have a somewhat different scheme
              for 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" to display the  service  status,  etc.).   Running  the
       script without parameters displays the possible arguments.

   Sequencing directories
       To  make  specific  scripts  start/stop at specific run-levels and in a
       specific order, there are sequencing directories, normally of the  form
       /etc/rc[0-6S].d.   In  each of these directories, there are links (usu-
       ally symbolic) to the scripts in the /etc/init.d directory.
       vice on runlevel 2.  This happens after /etc/rc2.d/S12syslog is run but
       before /etc/rc2.d/S90xfs is run.

       To manage these links is to manage the boot order and run-levels; under
       many  systems,  there  are  tools to help with this task (e.g., chkcon-
       fig(8)).

   Boot configuration
       A program that provides a service is often called a "daemon".  Usually,
       a  daemon  may receive various command-line options and parameters.  To
       allow a system administrator to change these inputs without editing  an
       entire  boot  script,  some separate configuration file is used, and is
       located in a specific directory where an  associated  boot  script  may
       find it (/etc/sysconfig on older Red Hat systems).

       In  older  UNIX  systems, such a file contained the actual command line
       options for a daemon, but in modern Linux systems (and also in  HP-UX),
       it  just  contains shell variables.  A boot script in /etc/init.d reads
       and includes its configuration file (that is, it "sources" its configu-
       ration file) and then uses the variable values.

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

SEE ALSO
       bootup(7)  systemd(1)  inittab(5),  bootparam(7), init(1), runlevel(8),
       shutdown(8)

COLOPHON
       This page is part of release 4.04 of the Linux  man-pages  project.   A
       description  of  the project, information about reporting bugs, and the
       latest    version    of    this    page,    can     be     found     at
       http://www.kernel.org/doc/man-pages/.

Linux                             2015-03-11                           BOOT(7)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2019 Hurricane Electric. All Rights Reserved.