Matt Carpenter


In the beginning.

When your computer is first turned on, it goes through what is called a POST (Power-On Self Test) which checks the hardware (memory, Hard Drive Controllers, BIOS, etc.). If it completes this test, the BIOS (Basic Input/Output Services) begins its "Bootstrapping" (also known as Boot) procedure, so named for its purpose: to start the computer from nothing (picking itself up by the bootstraps, so to speak)

Bootstraps to Boot Record

The BIOS is given the responsibility of loading software to control the computer. Modern Day Operating Systems (OSes) have stemmed from this need. In order to understand the next step, you must understand a bit about Hard Disk Drives (harddrives or harddisks for short). In order to better manage the ever-increasing capacities of a hard-drive, a scheme called Partitioning was created, which physically splits up the hard drive into chunks, or "Partitions". Each partition has a 512byte chunk of data at the beginning called the Boot Record. At the beginning of all the partitions lies a special Boot Record called the Master Boot Record. To that end, I call the other Boot Records "Partition Boot Records". A visual representation of this looks like:

[MBR]

[[PBR]Partition1-------]
[[PBR]Partition2-------]
[[PBR]Partition3-------]

Continuing on in our boot process, the BIOS finds the first floppy disk drive. If there is a bootable floppy disk in the drive, the BIOS uses that. Otherwise it boots from the first harddrive. For our purposes, we will focus on the hard-drive. Typically, if a SCSI Host Adapter is present with HD's, they are checked (in increasing order starting at SCSI ID0), otherwise it's the Master Drive on IDE Controller 1. On the hard drive in question, the BIOS checks for a boot program (known as a Boot Loader) in the Master Boot Record. If one exists, it is executed. The default MBR bootloader checks the partition table (also maintained in the MBR) for the partition marked as active and attempts to execute the bootloader in that partition's Boot Record.

Boot Loader to init

The Boot Program is a special program. Why? It determines what Operating System to load, where to load it from, and essentially determines if you can use your computer. Why not use the Operating System as the boot program? Because the Boot Record is limited to 512bytes. Can't fit a whole lot in that space.

Common boot programs include LILO (LInux LOader) and GRUB (GRand, Unified Bootloader) are the more common boot loaders for Linux and are capable of loading virtually any OS. These can be loaded into either the MBR or any PBR's. Windows NT comes with NT Loader and is configurable to load multiple OSes as well. By default, NT Loader installs in the PBR, and I am not aware of any way to write this to the MBR. The DOS/Win Loader is pretty lame as it give no flexibility and loads in the PBR. Please email me with info on these or any other boot loaders as I don't know everything.

It is the bootloader's responsibility to load the OS. For our purposes, we will assume we are booting a Linux OS using LILO or GRUB. The bootloader is programmed with the location of either a Linux Kernel or a Chainloader. Chainloaders are used to boot other operating systems than Linux (and I believe they simply look for another bootloader in a specified partition). The bootloader then executes the Kernel.

The Kernel is compressed so its first step is to uncompress itself. There is a small program at the beginning of the Kernel image file to do this. The Kernel then configures a basic set of device drivers (Sorry, not your VooDoo3) and attempts to mount the root filesystem. You may have noticed in both lilo.conf and menu.lst that there is a place to specify the root partition. This information is passed to the Kernel. The filesystem type (ext2, vfat, etc.) is automatically detected and the filesystem mounted read-only. Note that this is only if the driver for that partition has been compiled into the kernel. If not, the Kernel halts the system (more aptly put, it pukes).

Once the Kernel has done all this successfully, it executes one single process: /sbin/init (note that if it can't find init in several common locations, the Kernel will attempt to execute /bin/sh)

init What?

The program named /sbin/init should also be known as "The Father of All Processes". The Kernel only starts one process and init is it. init uses the configuration file /etc/inittab to determine how your system is to run. init does a lot of startup tasks, which includes finishing configuring the hardware, setting up virtual consoles, and starting services. Much of the universal control which Linux gives us as administrators starts at init and /etc/inittab. /etc/inittab has a special structure which is beyond the scope of this article but can be found by typing "man inittab" at a shell prompt. For our purposes, we will assume a standard (Caldera) Linux installation.

init: Runlevels? Sounds like a Gym with too many floors!

init starts out by executing the following scripts:

/sbin/booterd Administrative tasks (eg. mount's proc fs, configs video, starts /sbin/booter)

/etc/rc.d/rc.modules Loads modules necessary for system operation

/etc/rc.d/rc.serial Initializes the serial ports on the system (unused by default)

/etc/rc.d/rc.boot Admin (check/mount FS's from fstab, config network, setup Timezone and other important system variables)

/etc/rc.d/unconfigured.sh Various admin tasks ("to do" list)

*Note that unconfigured.sh is called from rc.boot

After executing these scripts, init chooses which of several predefined system startup configurations (called Runlevels) to use. Runlevels are somewhat like a crossbreed between DOS Multiple-Configs and Win-Hardware Profiles, and yet not really. A Runlevel defines what software and services get loaded from this point on. Typically there are 7 Runlevels (0 is the Shutdown Sequence and 6 is the Reboot sequence). By default the rest can be described as follows:

1: Single User Mode - Administration

2: Single User - No Networking

3: Multi-user CLI (Text Mode)

4: Undefined - For definition by administrator (eg. Web Server-only mode)

5: Multi-user, GUI login

For each runlevel, there is a corresponding directory called /etc/rc.d/rcX.d where X is the runlevel in question. The only things typically found in these directories are symlinks (ln -s <whatever>) to scripts located elsewhere (typically in /etc/rc.d/init.d). The names of the symlinks are important, because if the name begins with a K, the script will be called with the parameter "stop". Likewise, if the name begins with an S, the script will be called with the parameter "start" (look at your /etc/rc.d/rc0.d). init assumes that the scripts involved are aware of this convention and will take the necessary steps in order to start and stop whatever service they are responsible to start and stop.

init: Extras

We've discussed how init sets up the different runlevels. init does much more than that, and the details can be found in the inittab manual. Briefly, init sets up the VC's which are found in runlevels 1-5 (only RL2-5 have multiple VCs, accessed using CTRL-ALT-F?), configures the system to handle special events (like CTRL-ALT-DEL and UPS signals, etc.), and starts the GUI login for runlevel 5. Check out /etc/inittab. Open another Xterm and type "man inittab" to find out how it works.

In the end, init executes (using the respawn directive) whichever login is defined by the runlevel (/sbin/getty or a shell that runs /etc/rc.d/rc.gui).

Conclusion

We have reached the end of our tour today. Please leave safety-belts fastened until the ride has come to a complete stop. There are many details still left out of this account. I hope that you will investigate further if something interests you. Since the OS is open source, any of this can be changed to suit your needs. However, since there is strength in standards, don't expect this to change much in the mainstream in the near future.

searchSearch Index