Background: How Linux Starts Up

For background, let's review the complete process of 'how Linux starts up.' From the moment you turn-on your computer, right to the point where you can use it. And, let's look at what can go wrong along the way! (Note that this description is intended to be high-level, glossing over some details in the pursuit of clarity.)

(1) Power-on: The BIOS (a built-in program embedded in your computer's hardware), is the first thing to start when you power-on or reset your computer. It does self-tests, checks the memory size, offers to let you change its configuration (say, by pressing DELETE during startup), and then... it tries to start, or boot, an operating system. Most computers look at a series of devices in a prescribed, and user-adjustable, sequence, and select the first device that's usable. (They might, say, look first at the floppy drive, then the CD/DVD drive, then the first hard disk, and so on...)

(2) The Master Boot Record (MBR): What the BIOS is actually looking for is a "master boot record," which is a special 512-byte record containing a very small program. This program locates and starts the "boot loader," which will be responsible for loading and starting some operating-system.

(3) The Boot Loader: There are two boot loaders available for Linux... LILO and its successor GRUB. Both of these programs do the same thing: they let you select an operating-system to run, and then they load and run that operating-system. Boot loaders are fairly generic programs that can successfully start not only Linux but Windows. In the Linux world, boot loaders can also load initial ramdisks, or INITRDs, which we shall talk about in just a moment.

(4) The Linux Kernel is loaded, and starts: The boot loader loads a compressed version of the Linux kernel, which promptly un-compresses and installs itself at the top of the system's memory, where it will remain.

(5) The scripts in INITRD (if there is one) run now: In step (3) I mentioned initial ram disks but didn't explain what that meant. Let's do so now. The problem faced by the writers of any "generic Linux distro" is that it's impossible to predict in advance exactly what any particular user's computer might actually look like... what devices it may or may not have, and what support is needed within the kernel to make those devices run. INITRDs provide a solution: a small set of programs that will be run when the kernel is "only barely initialized," with the opportunity to do such things as to scan the system's hardware and decide exactly what kernel support is needed. The INITRD program can load kernel modules, to add to the kernel (on the fly!) whatever additional features may be required. When the INITRD program ends, Linux initialization proceeds.

(6) The init program is started: When the kernel is completely initialized, it starts and runs only one program: init. This is "process #1," the granddaddy of all other processes that this Linux system will ever run during its lifetime; the one process that will never die; that is not allowed to die. This process will refer to /etc/inittab to tell it what to do, and what it does initially is to execute a series of other programs... the so-called initscripts, found in /etc/rc.d.

Incidentally, one of the common problems that arises with a new, or newly updated, Linux system is that the kernel can't find init. A cryptic message is presented, with the words kernel panic - not syncing. The usual cause is the omission of the root= parameter when you set-up the boot-loader. The kernel may also complain that someone tried to kill init, when it would be more accurate to say that init simply couldn't get started in the first place. (Remember how I said that "init is not allowed to die?")

(7) The initscripts are run, according to the chosen runlevel. If you examine /etc/inittab, you'll see that it consists mostly of specifications to run certain programs, both at system-startup and at specified runlevels. Each of the scripts whose name begins with the letter "S" will be executed, in ascending order by name, and in so doing, init will start all of the subsystems, or daemons, which make up what we think of as "a complete running Linux system."

At this point, "Linux is up and running." init's role is now complete: it will go to sleep until some program dies and, perhaps, must be restarted. All of the operations of the system will now be performed by the various daemons that init has started.

(8) For graphical logins, the last subsystem that is started by init is X Window or X.Org (often referred to as "XOrg" or simply "X") which is the graphical subsystem of Linux. A component of this system called XDM is what actually presents the graphic login prompt to you (however, because of its lack of user-friendliness, users of GNOME, KDE or Enlightenment tend to use GDM, KDM or Entrance instead of XDM).

(9) When you, or anyone else, "logs in" to the system: what actually happens is that a shell process of some kind is started, and all of the programs that you run and everything else that you do during that session is carried out either by that shell or by some other program that it launches. When you log off, that shell and all of its descendants are terminated. init (or XDM/GDM/KDM/Entrance as the case may be), then "wakes up" and starts a new login prompt.