Linux with Operating System Concepts

Type
Volatility
Typical Amount
Relative Expense
Usage
DRAM
Volatile
4–16 GByte
Very cheap
Main memory: stores running 
program code and data, graphics
SRAM
Volatile
1–2 MByte
Moderately 
expensive
Stores recently and currently used 
portions of program code and data
ROM
Nonvolatile
4K or less
Very expensive
Stores unchanging information: the 
boot program, basic I/O device 
drivers, microcode

---

448
◾
Linux with Operating System Concepts
the hard disk is second to last. In this way, a user can override booting from what might be 
stored on hard disk if they insert a bootable USB flash drive, optical disk, or floppy disk.
As BIOS is not alterable (because it is stored in ROM), computers come with another 
form of memory, CMOS. This stands for complementary metal-oxide semiconductor, 
which runs off of a battery placed on the motherboard. This memory retains the prioritized 
boot ordering, which can be altered by the user if desired. The CMOS may also store other 
alterable boot information and include a clock of the current date and time.
11.3 BOOT LOADING IN LINUX
11.3.1 Boot Loaders
The typical situation in Linux is to boot the operating system from the internal hard disk. 
We will assume this is the case here. The very first sector of the Linux disk space is set aside 
for the 
master boot record
(MBR). The MBR contains the 
boot loader
program (or a por-
tion of it) as well as a partition table and a magic number. The magic number is used for a 
validation check only. The partition table contains the location on disk of active partitions 
where bootable operating systems can be found. The MBR is 512 bytes in length. The first 
part of the MBR consists of 446 bytes that contain part of the boot loader program.
For the Linux operating system, there are two commonly used boot loaders: GRUB 
(grand unified bootloader), which can be used to load multiple types of operating systems 
(e.g., Windows and Linux or two versions of Linux) and LILO, which can only be used to 
load multiple types of Linux operating systems (e.g., CentOS and Ubuntu). These two boot 
loader programs are too large to fit in the 446 bytes available, so the boot loaders are divided 
into two parts, generally thought of as the installer and the kernel loader, also referred to as 
stage 1 and stage 2 of the boot loading process. Stage 1 merely finds and loads stage 2 into 
memory. Stage 2 is responsible for finding and loading the operating system kernel.
LILO (Linux Loader) is the older of the two boot loaders. It can boot an operating system 
from either floppy or hard disk and it can select any of up to 16 different boot images. LILO 
is file system independent, which is both a weakness and a strength (in that LILO is simpler 
and does not have a reliance on accessing the file system). It can also be parameterized based 
on the boot image selected. You can alter LILO’s behavior (once Linux has booted) by edit-
ing the file /
etc/lilo.conf
. This will change how LILO works in future boots. This con-
figuration file stores global options, such as the boot location, the type of installation (e.g., 
menu- or text-based) and the location of file system mapping information. The remainder of 
the file contains specific configuration information for each of the boot images.
GRUB can operate in two or three stages (in which case, there is a middle stage called 
stage 1.5). Stage 1.5 contains device drivers so that GRUB can access different types of file 
systems. Because of this, GRUB can actually interact with the Linux file system prior to the 
kernel being run. LILO on the other hand must perform the kernel loading operation with-
out any access to information that might be stored in the file system. With this capability, 
GRUB is able to load stage 2 directly from the file system rather than a reserved location 
on the hard disk. This also permits access to GRUB stage 2 by system administrators to 
edit its functionality.

---

System Initialization and Services
◾
449
GRUB stage 2 loads a default configuration file in order to present to the user a selec-
tion of kernels to select between. Through this GUI interface, the user can also drop into a 
GRUB command line to perform boot loader operations such as changing kernel param-
eters, enabling or disabling kernel modules, and editing or replacing boot configuration 
files. Once a kernel is selected, GRUB uses a mapper to locate the kernel and load it into 
memory.
A third boot loader is called loadlin. This boot loader runs under either DOS or 
Windows. This means that you are able to boot to Linux from DOS/Windows as opposed 
to the more traditional boot loader, which runs during the boot process. What loadlin does 
is replace the images in memory of DOS/Windows with the Linux kernel and configura-
tion parameters while it executes. As such, loadlin is more useful if you desire booting to 
Linux occasionally from a fully booted Windows machine.
With access to the MBR and boot loader program, the boot process has shifted from 
running program code from ROM to running code from hard disk. ROM chips are expen-
sive and so an economic strategy is to store as much of the boot process on disk (or other 
storage device) as possible. From this point forward, we will see that the boot process 
involves accessing storage and using volatile memory.
11.3.2 Loading the Linux Kernel
The Linux kernel is stored as a partially compressed image. What is loaded into memory 
is not entirely executable. The Linux kernel is stored on hard disk as the file 
vmlinuz
(the full file name includes the version number and architecture type, for instance, 
vmlinuz-2.6.32-279.el6.x86_64). The first portion of the kernel image is executable and it 
contains two parts, a 512-byte boot sector and a kernel setup program. As the kernel setup 
portion runs, it performs some basic initial hardware setup. It then uncompresses the latter 
portion of the vmlinuz file into 
vmlinux
, the rest of the kernel (See Figure 11.1). It should 
be noted that the Linux kernel can be stored on a USB drive or optical disk and inserted 
prior to (or during) the boot process as vmlinuz is bootable from these sources.
With the kernel, vmlinux, uncompressed, kernel initialization begins. Its first step is 
to continue initialization of hardware. Among other things, the power system tests the 
various components, searches for and loads ramdisks
*
, accesses the buses and through 
the buses the various components connected to the computer (e.g., monitor, keyboard, 
memory, disk controller(s), timer, plug-and-play devices) as well as setting up interrupt 
handling mechanisms (IRQs).
One of the ramdisks is loaded with 
initramfs
, which is the initial Linux root file 
system. This file system is transferred into RAM for use during kernel initialization for 
*
Refer to Section 10.5 for a discussion on ramdisks.
Boot
sector
Setup
sector
Compressed kernel image
(vmlinux)
FIGURE 11.1 
vmlinuz file.

---

450
◾
Linux with Operating System Concepts
efficient access. The initramfs file system allows the kernel to access a file system without 
having to mount any part of the normal Linux file system, thus permitting the kernel to 
operate using file operations. This file system is only stored temporarily and removed from 
RAMdisk midway through kernel initialization.
The initramfs contains directories that mirror the real (or permanent) Linux file system: 
bin, dev, etc, lib, loopfs, proc, sbin, sys, and sysroot. Prior to Linux 2.6.13, this initial file 
system was called initrd. One difference between initramfs and initrd is the initrd had to 
be stored via a block storage device whereas initramfs is more flexible.
Unlike the matching directories in the permanent Linux file system, the initramfs 
directories are minimal, containing only those executables and configuration files needed 
to finalize the kernel initialization process. The /dev directory for instance permits the 
kernel to communicate with hardware devices during hardware initialization while /bin 
and /sbin contain the executable programs necessary for the kernel to start virtual memory 
and mount the root partition.
At this point in time, the kernel executes a command called 
pivot_root
, which alters 
the root partition from initrd to /. This dismisses initramfs (removes it from memory) and 
establishes the permanent file system. At this point, only the root file system is mounted. 
Recall that the root partition will contain /bin, /sbin, and /etc. These directories will all be 
needed during the remainder of operating system initialization. Later, the other file sys-
tems in /etc/fstab (e.g., /var, /home) will be mounted.
To complete kernel execution, the kernel will find and execute the init process (usually 
located at /sbin/init). It is the init process that is responsible for initializing and establishing 
the user space. In essence, init is responsible for bringing the system up to a usable state, 
doing everything that the kernel initialization did not. Now, the kernel moves to the back-
ground, waiting to be called by other processes.
11.4 INITIALIZATION OF THE LINUX OPERATING SYSTEM*
The init program is the first process to execute in any Linux session. This is a permanent 
process in that it will run during the entire session that Linux is running, but it will largely 
sit in the background. It is only stopped when Linux is shut down. The init process is also 
stopped if the telinit command is used (which causes Linux to switch to a different run-
level, and a new init process is started). Staying in the background allows Linux to retain 
init as an active process without it requiring resources. It is moved into the foreground as 
needed. For instance, init moves to the foreground to adopt an orphaned process, and then 
it moves back into the background. You will always find init to be process 1 (PID of 1).
11.4.1 inittab File and Runlevels
The init process handles the remainder of the operating system’s initialization through 
startup scripts. In older versions of Linux, the init process had been synchronous in that 
each step would happen in order. This unfortunately could lead to a situation where, if 
*
See www.nku.edu/~foxr/linux/ for a discussion of changes made to the initialization process in Red Hat version 7 and 
CentOS version 2.7.

---

System Initialization and Services
◾
451
one step of the process were to stall, the entire process would hang. This could happen, 
for instance, if init attempted to communicate with a device that was not responding. In 
order to improve the startup process, the init process has been replaced with 
Upstart
, 
an event-based version of init. Thus, the init process is now asynchronous. This allows init 
to invoke the various startup scripts, tasks, and services in a scheduled order but without 
having to wait for a previous step to respond before moving on.
Additionally, Upstart can handle plug-and-play devices by discovering new devices con-
nected at any time. Upstart has been made available for Fedora, Ubuntu, CentOS, Google’s 
Chrome and Chromium OS, and openSUSE. It is available as an option for Debian.
The first visible step in init is to invoke the script 
inittab
. This script has at least one 
statement to establish the