Last modified: Thursday, 21 August 1997 15:09 EST
The Boot Procedure
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.
Kernel
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.
System Processes
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).
sched
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.
swapper
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 is needed.
Page Daemon
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.
init
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.
Startup Scripts
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:run-level:action:process
-
id uniquely identifies the entry. It may be a one or characters
string.
-
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
may include:
-
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
kernel, init,swap, virtual memory, run level.
Last modified: Thursday, 21 August 1997 15:09 EST
<URL:http://www.uwsg.indiana.edu/usail/installation/boot-process.html>
Copyright
1996, The Trustees of Indiana University
Comments and suggestions to: usail@indiana.edu