In computing, booting (also known as booting up) is the initial set of operations that a computer system performs when electrical power to the CPU is switched on. The process begins when a computer is turned on for the first time or is re-energized after being turned off, and ends when the computer is ready to perform its normal operations.
Restarting a computer or its operating system software. It is of two types (1) Cold booting: when the computer is started after having been switched off. (2) Warm booting: when the operating system alone is restarted (without being switched off) after a system crash or 'freeze.' Both types of booting clear out (for the time being) the bugs, bombs, memoryconflicts, and other idiosyncrasies of the operating system.

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 initprocess. 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, thepagedaemon (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.