The ROM bootstrap program does the following, though not necessarily in this order:

• Performs POST, including testing memory, keyboard, and console.
• Polls all addresses where a device can reside, and either runs diagnostics in the ROM or asks the device to run a self-diagnostic and report the results.
• Finds the device that is bootable, usually the first drive.
• Determines whether that device has a program in its own ROM that needs to be loaded in order to control the device, then loads it.
• Jumps to the now-loaded device control program that lets you load the disk bootstrap program, and loads it. The program resides in the boot block or boot sector of a disk. That sector has become a favorite target area for virus writers, because it's very hard to boot a computer without loading and executing the boot sector.
• Jumps to the beginning of the now-loaded disk bootstrap program and executes it.

Then the disk bootstrap program locates and loads a larger program (usually the Unix/Linux kernel) and begins executing. In an alternative version, the disk bootstrap program loads and runs a very extensive booting program. When complete, that booting program finally loads and executes the Unix kernel.

You can see why this process is called booting. The ROM program A loads small disk program B (the boot sector) and executes it. Disk program B loads larger program C and executes it. Possible program C ends by loading program D and executing it.

This process is similar for all machines, unless you're working with an embedded operating system, in which most or all of the operating system is preburned into a ROM and doesn't have to load from a disk drive.

In the above example, the standalone program that's loaded, the kernel, doesn't have to be a full operating system. For example, if you boot a SPARC system in diagnostic mode, a diagnostic monitor operating system is loaded for running tests on system hardware. That operating system is used only for SPARC testing.

A typical Unix boot sequence is:

• Power-on
• ROM boot starts and runs POST
• ROM boot loads and executes the boot sector or boot block (commonly called primary boot)
• Boot block executes by loading and executing the secondary boot program, which does a local or network boot
• Unix kernel is loaded from a local disk drive or over the network, then executed

The boot procedure on an x86 machine is slightly different, but the same basic steps are performed. The primary boot is implemented in the Basic Input Output System (BIOS) ROM that exists on the system board and on BIOS extensions in ROMs that are plugged into the various peripheral boards.

The combination of system-board ROM and peripheral ROM programs loaded from peripheral boards provides all the basic abilities to control the installed peripheral devices and provide I/O services through software interrupts.

After the ROM boot is complete, the ROM program loads and executes the first physical sector from either a floppy or hard disk. (There's the boot sector again.) This load and execution is still part of the primary boot process.

The secondary boot loads and runs a more extensive boot program, which determines the installed devices in the system, possibly with the user's help. The secondary boot then reads in a script file, such as /etc/bootrc, which controls the booting process. That file contains boot interpreter commands, which can be modified to change defaults or adapt to a specific machine.

The boot script completes by loading the kernel. The kernel then starts the operating system, loads the necessary modules, mounts the necessary filesystems, and runs an init program to bring the system to the initialized default state.

The init program also has to spawn all system processes that need to run as part of a Unix startup. Those processes are listed in the /etc/inittab file, with the action code respawn. The first time through, the processes are spawned, and respawn occurs whenever the process stops running, or during changes in run state while booting or shutting down.

Here are some typical respawn entries from an /etc/inittab file. These are used to launch the getty (or in this case, mingetty) program that sits on the Unix/Linux box waiting for someone to log in at a terminal.

# run gettys in standard run levels 
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 

The action codes in /etc/inittab might include:

• respawn: If the process doesn't exist, start it. When the process dies, restart it. If the process currently exists, do nothing and continue scanning the inittab file.
• once: Start the process. When it dies, do not restart it.
• boot: This entry is to be processed only at the init boot-time read of the inittab file.
• powerfail: Execute the process associated with this entry only when init receives a power failure signal.

There are many more action types in the /etc/inittab file. I wanted to give you a taste of what it contains, as reading and executing the entries is the last formal act before the login prompts appear on the terminals.

At this point the computer is booted and (pant, pant) you can log in.

A bootstrap process has been necessary since the very first computer was switched on. Without it, you would have to hand-enter a startup program using switches and other arcane controls on a front loading panel. That was how the earliest personal computers were started. As computers became more sophisticated, so did the process, but it's interesting that the general description of the bootstrap process would look familiar to even to a mainframe administrator. Comprehending it helps you understand one of your computer's most basic functions.