Bootstrapping is the process of starting up a computer from a halted or
powered-down condition. When the computer is switched on, it activates
the memory-resident code which resides on the CPU board.
The normal facilities of the operating system are not available at this
stage and the computer must 'pull itself up by its own boot-straps' so to
speak. This procedure therefore is 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:
- The memory-resident code
- Runs self-test.
- Probes bus for the boot device
- Reads the boot program from the boot device.
- Boot program reads in the kernel and passes control to it.
- Kernel identifies and configures the devices.
- Initializes the system and starts the system processes.
- Brings up the system in single-user mode (if necessary).
- Runs the appropriate startup scripts.
- Brings up the system for multi-user operation.
Most Unix systems implement a two-stage loading process. During the first
stage, a small boot program is read into memory from a default or specified
device. It is this program that reads in the kernel and relinquishes the
control to it. The path to the kernel is vendor-dependent. For example,
it is /vmunix on SunOS 4.x, Digital Unix and Ultrix, /kernel/unix on SunOS 5.x,
/hp-ux on HP-UX, and /unix on IRIX and AIX systems.
One of the very first, probably the most difficult, tasks a system
administrator must perform, is configuring the kernel. You'll read
the details later in the sections dealing with the 'Operating System
Installation'. Once the kernel is loaded, it remains
in the memory during the running of the system and is usually run in a
fixed amount of memory. When the kernel starts, it normally displays its
size and the amount of physical memory remaining after the kernel is loaded.
The kernel probes the bus to locate the devices specified during
the configuration, and initializes the located devices (ignoring those
that it can't contact). Any device not detected and initialized during
the boot will not be accessible to system until it is properly connected
and the system is rebooted.
The kernel identifies the root, swap, and dump devices and then starts programs
to schedule processes, manage physical memory and virtual memory, and
the init process. BSD systems starts three initialization processes;
swapper, init and
pagedaemon. On the SVR4 systems the initialization processes include
sched, init, and various memory handlers (except on Solaris).
The real-time scheduler, sched, runs as process 0 on SVR5 systems.
It can be used to set priority for real-time processes so that they can
be given fast access to the kernel.
The swapper daemon runs as process 0 on BSD systems. It manages the physical
memory by moving process from physical memory to swap space when more physical memory
Various memory handlers run as process 2. When a page of virtual memory is
accessed, the page table within the kernel is consulted and if necessary, the
pagedaemon (SunOS 4.x) or pageout (SunOS 5.x) is used to move pages
in and out of physical memory and to update page tables. Similar memory handlers
exist on other SVR5 systems.
The last step in bootstrapping the kernel starts the /etc/init process. The
init process runs as process 1 and always remains in the background when
the system is running. If the system is brought up in a single user mode,
init merely creates a shell on the system console (/dev/console) and waits
for it to terminate before running other startup scripts.
Single User Mode
Single user shell is always Bourne shell (sh) and it runs as
'root'. It enables the system manager to perform various
administrative functions, such as setting the date, checking the consistency
of the file system, reconfiguring the list of on-line terminals, and so on.
At this stage only the root partition is usually mounted. Other file systems
will have to be mounted manually to use programs that do not reside on the
root volume. The file system consistency check may be performed by the
command fsck, usually found in the /etc directory.
The startup scripts are merely shell scripts, so init spawns a copy of sh
to interpret them. The startup scripts are defined and organized differently
on different systems. On BSD systems the startup scripts may be found in
the /etc directory and their names begin with rc, e.g.,
/etc/rc.boot, /etc/rc.single, /etc/rc.local and so on.
SVR5 systems define various run levels in which a specific set of processes
are allowed to run. This set of processes is defined in the
/etc/inittab file. Each line in the inittab file describes an action
to take. The syntax of inittab entries is:
- id uniquely identifies the entry. It may be a one or characters
- run-level defines the run level in which the entry can be processed.
If this field is empty, all run levels are assumed.
- action identifies what actions to take for this entry. These actions
- sysinit - perform system initialization,
- wait - wait for the process to complete,
- once - run the process only once,
- respawn - restart the process whenever it dies.
- process specifies the shell command to be run, if the entry's
run level matches the run level, and/or the action field indicates such action.
In general, the following tasks are performed in the startup scripts.
- Set the hostname.
- Set the time zone.
- Run the file system consistency check.
- Mount the system's disk partitions.
- Start the daemons and network services.
- Configure the network interface.
- Turn on the accounting and quotas.
Terms used: boot, bootstrapping