How Linux Starts on a Computer

The process of starting a computer is often called "booting" the computer, regardless of the operating system. This term came from the analogy of "pulling a boot up by its bootstraps." Understanding the boot process has incalculable value on understanding the entire system. Surprisingly, knowing the boot process leads to knowing why something may not work properly, especially for the newcomer to Linux.

There are generally six major software-defined phases that a computer will run through, in the course of starting Linux. These phases, in order:

• the device search,
• the boot loader,
• the kernel,
• the init process,
• any daemons for the chosen run level, and
• any user environments.

These are summarized briefly here, but a world of information about each phase is available to the interested reader through google.

Device Search

Any computer must have some way of knowing what to do when it is first powered with electricity. This is generally designed into the hardware itself, with the microprocessors looking at small pre-wired software chips installed at the factory. This software may be in permanent ROM, or it may be in an updatable FLASH kind of memory to allow for minor adjustments later. While some people may call this the CMOS, this is not technically accurate. The CMOS is only used to remember some data, not the software, used in the boot process.

These pre-wired software chips have a very special and brief purpose. The programs listed in them have two basic goals. One goal is that of providing rudimentary access methods to use a bare minimum of memory, disc drives, keyboards, video screens and other absolutely necessary hardware; this is often summarized as the BIOS, which stands for Basic Input/Output System. The other goal is that of finding other boot software to run, to continue the boot process.

The search for new boot software varies from computer to computer, and varies with the installed devices as well. Floppy drives, CD-ROM drives, networking cards, and hard drives may all contain software that helps the computer start up. Usually, each such device is checked in turn, though the user may configure their hardware to try the devices in a different order, or to avoid checking some devices for a faster startup. Once a valid boot program is found, it is loaded and executed immediately.

Some helpful google searches may be "what is bios", bios device boot sequence, boot computer cdrom floppy network, and bios cmos battery clock settings.

The Boot Loader

There are many different operating systems, and many versions of each. A boot loader's job, just like the pre-wired power-on chips' job, is to find and load yet more software to continue the boot process. Each phase is loading larger and more complex software.

The boot loader is typically found by the pre-wired hardware search, found in the first sectors of the first hard drive, also called the "master boot record." It may also be on a floppy drive or in the first sectors of a specially flagged CD-ROM drive. Some machines can work with network cards that are able to use a special protocol to request a boot loader from another machine on the network.

However, the boot loader often gives the user their first real choices, since there may be more than one operating system installed on the same computer. Using the rudimentary hardware access provided by the pre-wired chips, the boot loader can show a menu of operating system kernels, and can ask the user which kernel should be loaded. Once the user has chosen, and the boot loader has finished loading an operating system's kernel, the boot loader is no longer needed by the computer until the next time it is started up.

The boot loader generally has a special configuration file on one of the computer's devices which lists the possible kernels to be loaded. It may also be configured to choose one of those kernels automatically if nobody responds at the keyboard within a few seconds. Some boot loaders may offer fancy options to draw a graphic or a text message on the screen while waiting for the user's response. And finally, once the user does respond, the boot loader will load the chosen operating system kernel, and execute it.

A computer may have more than one operating system, but generally will only use one boot loader to load any of them. Two popular alternatives for boot loaders are called LILO and GRUB. The LILO (or linux loader) program is still in popular use today, but it is being phased out in favor of the more capable and portable GRUB program. Both are able to boot the basic Linux and Windows kernels, though each has its own capabilities and limitations beyond that.

Some helpful manual pages on your Linux system may be (man lilo), (man lilo.conf), (man grub), (info grub), (man grub.conf), and (info grub.conf).

Some helpful google searches may be lilo linux loader, grub gnu linux loader, mbr master boot record, and diskless network boot.

The Kernel

The computer has already used its pre-wired hardware programs to find a boot loader, and the boot loader has already found and loaded a specific operating system kernel. These are the methods used by most industry-standard hardware computer types, regardless of the operating systems installed on the computer.

From this point on, however, this document will only discuss the Linux architecture. The Linux architecture starts with its kernel.

While the hardware built into the computer may include some crude access to a minimum suite of devices, the kernel is responsible for organizing all accesses to any of the devices which could be installed on the machine. Also, the kernel manages the allocations of any memory installed, ensures that only authorized programs are able to perform certain tasks, orchestrates the use of multiple processors if available, implements the concept of a hierarchical resource naming system, implements input and output concepts of streams and blocks, and schedules the time-sharing between all of the software processes in the computer.

This is a very broad set of responsibilities for one computer program to perform, and it has to be done in such a way that new software can take advantage of these capabilities. For this reason, the kernel is becoming more and more modular, with different tasks and responsibilities written and installed separately. However, for the most part, the kernel is considered to be a single entity, and is not even seen as a "process" but rather the arbitrator for all other processes running in the computer.

Also like the hardware built into the computer, the kernel itself has very little to do with the choices made by users themselves. It receives a mandated set of options from the boot loader, and performs any necessary calls to implement those choices; these can be desired video modes, initial processes to spawn, additional modules to be inserted into the kernel's list of modules, and so on. The kernel itself is completely unseen by the user, and the Linux kernel by itself does nothing of its own volition.

Except one task. Of its own volition, if not told otherwise, the kernel does one thing, which should sound familiar by now: it immediately loads another piece of software to continue the boot process. This is called the "init process." Unlike the previous boot phases, however, the Linux kernel will remain in the machine's memory for the entire time the computer is running Linux. Indeed, that's the definition of running Linux; the kernel is Linux.

Some helpful google searches may be linux kernel introduction, linux kernel arguments, inserting linux kernel modules, and linux kernel init process.

The Init Process

In Linux, software processes are kept distinct, and each process may operate in parallel. Each process essentially thinks that it has the full control of the computer, but in actuality, they all get interrupted and are forced to take turns. Generally speaking, most computer microprocessor chips can really only think about one task at a time. The kernel schedules which process should be executed by which microprocessor at all times, and switches between processes in small slices of time to achieve the illusion of multi-tasking.

All processes in Linux act as their own autonomous program. They all have a 'parent' process which spawned them, they all have a set of permissions according to the 'user' which invoked it, and they all have the ability to call upon the kernel's many features to access hardware or file resources in the hierarchical namespace, or to spawn new children processes. What the process is actually allowed to do depends on its permissions; the kernel will refuse any requests to do unauthorized tasks.

The first process that is constructed is known as the init process. This is really no different from any other process in a Linux system, except that it is the first to be run and thus has no other process as a 'parent.' In fact, since there is no real difference, this makes the kernel very adaptable; if something were wrong with the usual init process, a different one could be tried instead to help work around, or repair, the problem.

The typical process used here is aptly named init. It acts as the ultimate parent of all other processes on the machine. The init program looks for a file called /etc/inittab, which is essentially a list of things to do at any given run level. While this is not mandatory for the first process to do, the init program remains in memory, sleeping, throughout the entire time Linux is loaded.

However, simple hardware architectures may not need running processes full time. A self-contained network router may set up the proper network settings and firewall rules, then completely end all non-kernel work, leaving no processes running at all. Some appliances may need a script process to perform this initialization while other appliances do all their startup inside the kernel and may never even launch a single process. Since the kernel's modules take care of hardware events as they occur, this leaves a tightly sealed and secure environment. In such a case, this is the end of the startup sequence. The machine is as "started" as it will ever be.

Some helpful manual pages on your Linux system may be (man init), and (man inittab).

Some helpful google searches may be linux kernel init process, linux sbin init, and linux etc inittab.

The Run Level Daemons

The /sbin/init program introduces a new concept called the "run level." This is typically a number between zero and six. There is only one run level at any given time in the whole machine, and this indicates the way that the machine expects users to interact with it.

The run level numbers are somewhat arbitrary, though the values have become standard and customary. Some distributions differ, but the typically useful run levels on most distributions are 1, 3, and 5. These are the values specified by the LSB, or Linux Standard Base, a project to unify the various distributions on technical aspects like this.

• 1 is for single-user mode; no logins
• 3 is for normal text login mode
• 5 is for graphical login mode

The default run level is specified in the first uncommented line in the /etc/inittab line, such as id:3:initdefault:. If not told otherwise, the init process will set that run level when it is first run.

When any run level is chosen, the init process will automatically run through its inittab list of tasks. Each line in the /etc/inittab describes another task, and to which run levels that task applies. Those spawned processes which should be shut down are stopped, and any new processes which should be started are spawned in turn.

The machine can also be switched from one run level to another at any time. To do this, either use the separate telinit command to signal the first init process, or merely run the init process another time which does the same thing. Running a second init does not start a new permanent copy, but rather it will signal the original copy and then stop itself automatically. All the tasks are then started or stopped from the original init process.

The inittab may specify a few special processes to start and stop, but the average Linux installation may have hundreds of new programs that should be managed by the system's run level. It is entirely possible to specify all such programs in the inittab, but this is not very convenient nor organized.

There are several meanings for the term "daemon" (pronounced day mon or dee mon), but the general idea in Unix-like operating systems is any program or process that hangs around in the background, ready to offer its services immediately to whatever other processes need it. Thus, most of the programs run by the init process are called daemons.

Rather than maintaining a huge /etc/inittab file, one custom has developed to create a series of scripts that should be executed at each run level change. This may vary from one distro to another.

On Red Hat Linux systems, these are kept in subdirectories according to the run level. For example, the /etc/rc.d/rc3.d directory contains a group of S scripts for daemons to start when entering run level 3, and a bunch of K scripts which shut down daemons when leaving run level 3. Adding new scripts, removing scripts, and adjusting these scripts can be done with the sysconfig command.

Other distributions may have different tools for managing these tasks, such as with tools named ntsysv or linuxconf. The mechanisms may be different, but the concept is essentially the same for most distributions based on Linux.

Some helpful manual pages on your Linux system may be (man init), (man inittab), (man chkconfig), (man ntsysv), and (man linuxconf).

Some helpful google searches may be linux kernel init process, linux init inittab, lsb linux standard base, linux daemons services, and linux managing run level scripts.

User Environments

The final stage in most people's experience in the Linux startup sequence is the login prompt. There are quite a few different alternative user environments, and even login managers, depending on the distribution and/or additional optional packages installed by the users on a given system.

Most Linux systems offer multiple "virtual consoles," which are essentially multiple independent login environments. In a text oriented run level, such as run level 3, the typical Linux setup will start about six separate virtual consoles (or VCs). Press Ctrl+Alt+F1 to select the first console, and note the text-mode login. Press Ctrl+Alt+F2 to select the second console, and so on. This is a good way to keep your own tasks separate; the virtual consoles act like you're running up to six different computers with the same files, or they can hold your place as you do several different tasks. Each time you hit one of the hot keys to switch virtual consoles, the screen remembers what was visible last time you were there (unless a program you ran is still outputting more text).

When in run level 5 (or 4 on some non-LSB distros), the typical Linux setup will offer one additional virtual console. This can be chosen with the Ctrl+Alt+F7 keystroke at any time, but the system will select this console for you automatically. In this last console, the XFree86 process is executed, and a graphical login program is run instead of the usual text login. Logging into that graphical login will also keep that copy of XFree86 running, allowing you to use a graphical user interface (or GUI) throughout the login session.

Even while in a graphical login session, you can still choose the other six text mode consoles. The system doesn't even need to be in run level 5 to run XFree86, either. If you're in a text console, you can use the startx command to begin a new XFree86 session and its subsidiary daemons. However, running two separate copies of XFree86 on the same computer is not always supported; check your documentation about that.

There are several text command environments (or shells) in the traditional Linux setup. The default is usually called bash, or the Bourne Again SHell. This shell, like most shells, is very straightforward yet powerful; it runs whatever new processes you specify, and allows for variables, loops, conditional statements, and piping the outputs from one program to other programs. Other shells differ in their syntax and other features somewhat, but the idea is the same.

Likewise, in XFree86, there are several graphical environments which offer similar scopes of abilities but somewhat different arrangements for users. Two popular environments are KDE and GNOME, but there are a few others. Examining these in detail are outside the scope of this document.

Some helpful manual pages on your Linux system may be (help), (man bash), (man getty), and (man XFree86).

Some helpful google searches may be linux shell commands scripts, linux graphical login, linux compare kde gnome, linux x11 xfree86, and linux getty bash consoles.

Contact Ed Halley by email at ed@halley.cc. Text, code, layout and artwork are Copyright © 1996-2005 Ed Halley. Copying in whole or in part, with author attribution, is expressly allowed. Any references to trademarks are illustrative and are controlled by their respective owners.