• When the computer is switched on, the first thing it does is to activate
  resident on the system board in a ROM (read-only memory) chip
• When the computer is switched on, the first thing it does is to activate
  resident on the system board in a ROM (read-only memory) chip.
• The operating system is not available at this stage so that the computer
  must 'pull itself up by its own boot-straps' so to speak.
• This procedure is thus often referred to as bootstrapping, also known as cold boot.
• Although the bootstrap procedure is very hardware dependent, it typically
  consists of the following steps:

Running the ROM-Resident Code

1. The system board inside a Unix/Linux box contains a minimal amount of non-volatile memory.
2. This memory is referred to as ROM (read-only memory), PROM (programmable read-only memory),
   EEPROM (electrically eraseable programmable read-only memory),
   NVRAM (non-volatile random-access memory), or firmware
3. A set of instructions embedded inside the chip are executed automatically
   when the system is powered on.

4. These instructions cause the system to perform a number of very simple yet crucial tasks.

The Power-On Self Test (POST)

• The first set of instructions from the EEPROM cause the machine to
  test its hardware, such as the RAM, system board, the CPU, the
  peripheral devices, etc.

Probe the Bus for Boot Device

• In the old days, a simple SCSI probe command in the EEPROM
  would attempt to find the boot media.
• As Intel and other PCI-bus based architectures become more common,
  SCSI is not usually available by default.
• In this case, PCI bus is probed for a boot device.
• Given access to the CMOS chip during start-up, any available
  bootable device can be selected.
• If bootable, a disk in the cdrom/dvd drive will commonly be selected by
  default for use in system installation.

Reading the Boot Program

• Once the boot device is found, the boot program is sought
  at a predictable location on the boot device (such as block 0 of the root disk).
• If found, the boot program is read in and executed.
• The purpose of the boot program is to read in the Unix kernel from a boot device.

System Initialization and Process Creation

While the exact sequence is highly vendor dependent,
system initialization usually involves the following steps:
• The kernel checks the amount of memory available.
• The kernel probes and configures hardware devices.
• Some devices are compiled into the kernel and the kernel has the ability
  to autoprobe the hardware and load the appropriate drivers or create the
  appropriate entries in the /dev directory.
• The kernel sets up a number of lists or internal tables in RAM.
  These are used to keep track of running processes, memory allocation,
  open files, etc.

Dummy Process Creation

• Depending on the Linux/Unix flavor, the kernel now creates
  the first Linux/Unix processes.
• A number of dummy processes (processes which cannot be killed)
  are created first to handle crucial system functions.

A ps -ef listing on each OS shows what these processes are:

HP-UX 10.20:


   UID     PID  PPID C  STIME   TTY       TIME COMMAND
   root     0     0  0  Apr 20  ?         0:17 swapper
   root     1     0  0  Apr 20  ?         0:00 init
   root     2     0  0  Apr 20  ?         1:02 vhand

* swapper - dummy process which provides swapping services
* vhand - dummy process providing virtual memory (paging) service


Linux RedHat 6.0:


   UID        PID  PPID  C STIME TTY      TIME CMD
   root         1     0  0 09:59 ?        00:00:07 init
   root         2     1  0 09:59 ?        00:00:00 [kflushd]
   root         3     1  0 09:59 ?        00:00:00 [kpiod]
   root         4     1  0 09:59 ?        00:00:00 [kswapd]
   root         5     1  0 10:00 ?        00:00:00 [mdrecoveryd]

* kflushd - dummy process to handle the swapping activity
* kpiod - dummy process to handle I/O activity
* kswapd - dummy process to handle the swapping activity
* mdrecoveryd - dummy process to handle the recovery of threads


Starting init

• init is the last process created at boot time.
• init always has a process ID (PID) of 1 (i.e. on all Linux/Unix systems).
• init is responsible for starting all subsequent processes.
• Consequently, it is the parent of all (non-dummy) Unix processes.

The init Command

• The init process (discussed above) is different than the
  system init command.
• The init command (usually found in /sbin or /usr/sbin)
  is used by root to put the system into a specific run level

Run Levels

• Each Unix vendor defines a number of arbitrary run levels that
  correspond to a certain system state (such as single or multiuser mode).
• When the system is in a certain run level, only a specified group of system
  processes can exist.

For example, under Linux RedHat 6.0, the default convention is:

   0 - Halt
   1 - Single user mode
   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
   3 - Full multiuser mode
   4 - unused
   5 - X11 (run a graphical login window)
   6 - Reboot

So, for example, running "init 6" as root under Linux will reboot the system.

The set of processes which are allowed to exist under a certain run level
are started by init during the boot sequence via the /etc/inittab file.

/etc/inittab:

• On most Linux/Unix systems, init reads a configuration file called
  /etc/inittab that tells init how to start the processes
  necessary to bring the system up to a default run level (usually the multiuser mode).

Here is a typical /etc/inittab (from a system running Linux RedHat 6.0):

################################################################################
# 
# inittab for Linux
#
id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0                                                 
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.
ud::once:/sbin/update

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now           # Run gettys 
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon       
#################################################################################

The general format of this file is id:runlevels:action:process

• where "id" is a unique sequence of characters which identifies
  the inittab entry
• "runlevels" lists the run levels for which the specified action is to be taken
• "action" describes the action to be taken
• "process" describes the exact process which is to be executed

System Startup Scripts

• Whenever the system transitions _to_ or _from_ a particular run level,
  scripts in a certain system directory are fired up.
• Under Linux, they are in /etc/rc.d
• They are named rcN.d where N is the run level.

Here is a directory listing for /etc/rc.d/rc3.d under
Linux RedHat 6.0 (remember, run level 3 is the multiuser mode in Linux):

./              K20rwalld@     K50snmpd@     S11portmap@   S80sendmail@
../             K20rwhod@      K55routed@    S20random@    S85gpm@
K05innd@        K25squid@      K60mars-nwe@  S30syslog@    S90xfs@
K08autofs@      K28amd@        K75gated@     S40atd@       S93sshd@
K15httpd@       K30mcserv@     K80nscd@      S40crond@     S99linuxconf@
K15postgresql@  K34yppasswdd@  K85netfs@     S50inet@      S99local@
K15sound@       K35dhcpd@      K88ypserv@    S55xntpd@
K20bootparamd@  K35smb@        K96pcmcia@    S60lpd@
K20rstatd@      K45arpwatch@   S05apmd@      S60nfs@
K20rusersd@     K45named@      S10network@   S75keytable@