The Linux Boot Process

In this section we will talk about the boot process as well as how to boot the machine to runlevel 1 to recover the root password. We will also consider how to install a virtual machine via the command line or the GUI. Both methods will use a pre-configured software repository and a kickstart file.

Many of these fundamental concepts will be expanded upon later in the course. Initially we need to get a few things going to have a good base to work from. Booting the machine to runlevel 1 to recover the root password is a critical skill. We'll need to install a virtual machine via the command line (or the GUI) for use during the class. Many of these initial concepts will be used throughout the course.

Boot, Reboot, Shutdown

This section will cover several concepts related to booting the machine, including boot, reboot, and shutdown. There are subtle twists and turns in this process that can and/or will make big difference. The following list gives an overview of the process:

  • Power On/Off
  • POST (BIOS) Process
  • GRUB Menu
  • Display Manager Screen
  • Gnome or KDE Desktop
  • Terminal commands: `shutdown`, `halt`, `poweroff`, `reboot`, `init 'x'`

Figure 1.1. Boot 0

Boot 0

Figure 1.2. Boot 1

Boot 1

Figure 1.3. Boot 2

Boot 2

Figure 1.4. Boot 3

Boot 3

Figure 1.5. Boot 4

Boot 4

Figure 1.6. Boot 5

Boot 5

Figure 1.7. Boot 6

Boot 6

Figure 1.8. Boot 7

Boot 7

Figure 1.9. Boot 8

Boot 8

Runlevels

The Linux operating system functions in what are called 'runlevels'. By definition, there are seven runlevels, numbered 0-6. Each runlevel has specific qualities that make the system behave differently for that runlevel. There is a default runlevel that is established at boot time, and it can be overridden by editing the GRUB menu as the system boots. This default can be permanently altered by editing the file '/etc/inittab'. The table below gives an outline of each of these runlevels.

Table 1.2. Runlevel Definitions

Runlevel Definition
Runlevel '0' Power off the system.
Runlevel '1' Single user mode without networking.
Runlevel '2' Not used by default in Red Hat type systems.
Runlevel '3' Multi-user mode with networking, no GUI desktop.
Runlevel '4' Not used by default in Red Hat type systems.
Runlevel '5' Multi-user mode with networking and GUI desktop.
Runlevel '6' Reboot the system.

Runlevel 1 is called 'single user mode', in that the only user that can log in is 'root'. Networking is disabled by default in runlevel 1. Also, minimal services and mounts are established for this runlevel. The purpose of runlevel 1 is for password or system recovery and other troubleshooting.

[Warning] SELinux Glitch

In some (unpatched) versions of Linux, there is an SELinux bug that prevents password changes while SELinux is set to "Enforcing". The workaround is to set SELinux to "Permissive", change the password, then set it back to "Enforcing".

Figure 1.10. Run Level

Run Level

BIOS

As the system boots, it processes through the sequence of events as shown above. The System BIOS is the first and most basic element of the boot process. This is before any part of the operating system is accessed, and various hardware elements and their fundamental configuration are accessed and initiated. If it's necessary to access the system BIOS, there are certain key combinations that can be used for this action. Usually, there is a short window of accessibiligy during the first part of the boot process when the key combination must be pressed. Such keys as DEL, F2, F12, etc. are the typical ways to access the system BIOS. The key combination can and will be different based upon the system you're using. YMMV.[1]

It's possible to alter the default sequence of events for a single boot, or permanently - which will apply to every boot of the system.

The GRUB Bootloader

Once the BIOS part of the boot sequence is finished, the process hands off to the default boot target. This can be a hard drive, CD or DVD ROM device, USB drive, or network boot agent. The operating system has/needs a dedicated facility for getting the system up and running. There are several of these available, such as LILO (Linux Loader), GRUB (Grand Unified Boot), Syslinux, etc. The default in Red Hat (type systems) at this point is GRUB, so we'll contain our discussion to that entity.

GRUB has two (or three) stages, depending on the installation (and how you look at it). There is always a 'stage 1' and 'stage 2'. There may also be a 'stage 1.5'. Also, depending on how the system is configured, the location of these may be different. Stage 1.5 will contain file system information, etc. For our purposes, we'll consider 'stage 1' to be located in the MBR (Master Boot Record) of the hard drive, and 'stage 2' to be located on the 'boot partition' where the actual boot files reside. This stage reads the '/etc/grub.conf' file and displays the grub menu. It also tells GRUB where and which kernel and initial ramdisk to load. Attitionally, it passes extra boot optons to the kernel.

We are concerned with the boot process as it's configured in 'stage 2', on the boot partition. There are three ways to edit this part of the process:

  1. Edit '/boot/grub/grub.conf' directly.
  2. Interactively edit the GRUB menu system.
  3. Directly manipulate GRUB through its shell.

The ultimate objective of GRUB is to point the boot process to the kernel of choice. When GRUB is finished, it hands the system to the default (or chosen) kernel, but in actuality that kernel can not boot by itself. There is an intermediate step called the initrd - initial ram disk. This file is a compressed image of the necessary hardware drivers that are necessary to boot the system. Once the boot process loads the initrd into memory, there is enough information accessible such that the hardware can begin to function. At this point, the system begins to load and the default kernel.

In this section we consider what it takes to edit the GRUB config file:

# vi /boot/grub/grub.conf

New in RHEL 7: GRUB 2

One of the new features that will be available in RHEL 7 is GRUB 2, which is a complete rewrite of the familiar and long-standing GRand Unified Boot loader. For details about this feature, check out GRUB2 at gnu.org . There's more information at GRUB2 at Fedora Project and a GRUB2 Tutorial available.[2]

The init Process

All Linux services, programs, and facilities run as separate and interrelated processes. The parent process is called init. It has pid (process id) '0'. All other processes are spawned as a result of this process.

The inittab File

The '/etc/inittab' is inits configuration file. It calls rc.sysinit, which loads appropriate services for each runlevel. This is a very important and very easy file to corrupt. If you get an error message such as 'Process spawning too rapidly' during boot, check this file or check to see if the commands it calls are present and configured correctly. The rc.sysinit utility sets the hostname, runs filesystem checks if needed, and mounts file systems in '/etc/fstab'.

Reference Material for this Chapter

For this chapter's supporting material, please reference Chapters 1, 2, 3, & 5 in the RHCSA/RHCE Linux Certification Study Guide text book.



[1] Your Mileage May Vary.

[2] This new and improved version of GRUB is a complete rewrite. The command-line interface is still available, but simply editing text files is now enhanced by a system that compiles the config files.