Knowing and understanding how does the Linux boot process work is a critical part of you becoming a Linux professional. All of that whirring, beeping and heat isn’t just for your entertainment. Starting up a Linux system sets a series of complicated process into action and a lot goes on behind the scenes in the Linux boot process. As we advance through this article, we’ll look at:
- Firmware and the role it plays in getting the boot process started,
- Linux bootloaders and their configuration options.
- The Linux initialization process and how Linux figures out which applications to start at bootup.
- System recovery options to help start a system that won’t boot.
Understanding How Does The Linux Boot Process Works
- The workstation’s firmware starts, performs a Power-On Self-Test, or POST) then looks for a bootloader program to run from a bootable device.
- The bootloader runs and determines which Linux kernel program to load. (Technically, the bootloader program doesn’t need to point directly to an operating system kernel file and can point to any type of program, including another bootloader program. This process is called chainloading and provides options to load multiple operating systems.).
- The kernel program gets loaded into memory and starts the necessary background programs required for the system to operate.
Viewing The Linux Boot Process
If you are short on entertainment options, you can monitor the Linux boot process by watching the system console screen during the boot up process. You’ll see seizure inducing flashes of informative messages scroll by as the system detects hardware and loads kernel software. If you are using a graphical desktop, please note that some Linux distributions hide the boot messages on a separate console window during start up; Pressing either the Esc key or the Ctrl+Alt+F1 key combination to view those messages.
As boot messages scroll by quickly, it’s hard to see what’s happening, so you can review the boot time messages using the “dmesg” command in the image below; The “dmesg” command displays the most recent boot messages stored in the “kernel ring buffer” (as well as the /var/log/boot.log file on Debian systems), which is where most Linux distributions copy the boot kernel messages . The buffer is circular and set to a predetermined size and a new messages are logged in the buffer, older messages are rotated out.
The Firmware Startup Process on a Linux Machine
Computers and servers utilize built-in firmware to control how the installed operating system starts. This firmware takes one of two forms:
- Basic Input/Output System (BIOS) is the firmware found on older workstations and servers
- Unified Extensible Firmware Interface (UEFI) maintains the system hardware status and launches the installed operating system newer workstations and servers
The Bios Startup
BIOS firmware has a simple menu interface allowing you to control how the system find hardware and define which device the BIOS uses to start the operating system.
A limitation of BIOS firmware was its inability to read more than one sector’s worth of data from a hard drive into memory to run as it is not enough space to load an entire operating system. This limitation was circumvented by most operating systems splitting the boot process into two parts.
First, the BIOS runs a bootloader program, a small program initializing the necessary hardware to find and run the full operating system program. The bootloader is found either:
- At another location on the same hard drive,
- On a separate internal or external storage device.
The bootloader’s configuration file allows administrator’s to tell it where to find the operating system file to run or even to produce a small menu allowing the user to boot between multiple operating systems. Most BIOS setups allow you to load the bootloader program from several locations:
- An internal hard drive
- An external hard drive
- A CD or DVD drive
- A USB memory stick
- An ISO file
- A network server using either NFS, HTTP, or FTP
The BIOS looks for the Master Boot Record ( the first sector on the first hard drive partition on the system. There is only one MBR for the computer system) and reads the program stored in it into memory. The bootloader program is small as it must fit in one sector, and mainly points to the location of the actual operating system kernel file, stored in a boot sector of a separate partition installed on the system. There are no size limitations on the kernel boot file.
The UEFI Startup
Just like everything else in life, simple things tend to get complicated and such is the case with operating systems. It eventually became clear that a new boot method needed to be developed, so in 1998 Intel created the Extensible Firmware Interface (EFI) and by 2005 the Universal EFI (UEFI) specification was adopted as a standard. Most desktop and server systems utilize the UEFI firmware standard.
As opposed to relying on a single boot sector on a hard drive to hold the bootloader program, UEFI specifies a special disk partition, the EFI System Partition (ESP), for storing bootloader programs. This design allows the storage of multiple bootloader programs of any size and for multiple operating systems.
The ESP makes use of tthe Microsoft File Allocation Table (FAT) filesystem in order to store bootloader programs. On Linux systems, the ESP is typically mounted in the /boot/efi folder, and the bootloader files have the .efi filename extension, such as linux.efi.
UEFI firmware utilizes a built-in mini bootloader/boot manager that allows configuration of which bootloader program file to launch. When running UEFI, you register individual bootloader files you want to appear in the boot manager interface menu at boot time when you then select the bootloader to run. Once the firmware finds and runs the bootloader, its job is done. The bootloader step in the boot process can be somewhat complicated.
Linux Bootloaders
As already demonstrated, bootloader programs bridge the gap between Linux system firmware and the full Linux operating system kernel. Because Linux user are democratically minded, there are several bootloaders for users to select, however, much like everything else in life, only a few are worth your time:
- Linux Loader (LILO)
- Grand Unified Bootloader (GRUB) Legacy
- GRUB2
- Extremely limited in functionality, it accomplished the intended purpose of loading the Linux kernel from the BIOS startup.
- LILO configuration is handled by a single file, /etc/lilo.conf and defines the systems to boot. As LILO doesn’t work with UEFI systems, you won’t run into it on modern Linux systems.
GRUB Legacy
Created in 1999, to provide a configurable bootloader to replace LILO, the first version of the GRUB bootloader (now called GRUB Legacy) quickly became the default bootloader for all Linux distributions, regardless of if they are BIOS or UEFI systems.
GRUB2
Created in 2005 as a rewrite of the GRUB Legacy system, it has supports advanced features, such as:
- The ability to load hardware driver modules.
- Using logic statements to dynamically alter the boot menu options based on detected conditions
As UEFI loads any size bootloader program, you can load a Linux operating system kernel directly without a special bootloader program. Incorporated into the Linux kernel starting with version 3.3.0, this method isn’t common, as bootloaders provide booting versatility , especially when working with multiple operating systems.
GRUB Legacy
Designed to simplify the process of creating boot menus and passing options to kernels, the GRUB Legacy allows the selection of multiple kernels and/or operating systems using either a menu interface or interactive shell. You configure the menu interface to provide options for each kernel or operating system you want to boot with while the interactive shell provides a way for you to customize boot commands on the fly.
Both the menu and the interactive shell utilize a set of commands that control features of the bootloader. Now, as part of learning how does the Linux boot process work, we are going to show you how to configure, install and interact with the GRUB legacy bootloader.
How to Configure the GRUB Legacy
Using the GRUB Legacy interactive menu requires telling it which options to display by using special GRUB menu commands.
GRUB Legacy systems store menu commands in menu.lst, a standard text configuration file, found in the /boot/grub folder. If you are a Red Hat fan boy/girl, Linux distributions, such as CentOS and Fedora, use grub.conf rather than menu.lst as the name of the configuration file.
The GRUB Legacy config file has two parts:
- Global definitions: Defines commands which control the operation of the GRUB Legacy boot menu and must appear first in the configuration file.
- Operating system boot definitions.
GRUB Legacy Global Commands
The table below defines the commands used in the definition section. In order to define a value for a command, you list the value as a command-line parameter:
default 0
timeout 10
| Setting | Description |
|---|---|
| color | Specifies the foreground and background colors that the boot menu uses. color white/blue yellow/blue The first pair defines the foreground/background pair for normal menu entries, while the second pair defines the foreground/background pair for the selected menu entry. |
| default | Defines the default menu option to select |
| fallback | A secondary menu selection to use if the default menu fails |
| hiddenmenu | Doesn’t display the menu selection. |
| splashimage | Points to an image file to use as the background for the boot menu. |
| timeout | Specifies the amount of time to wait for a menu selection before using the default. |
Operating System Boot Definitions
| Command | Description |
|---|---|
| title | The first line for each boot definition section; this is the text that appears in the boot menu. |
| root | Defines the disk and the partition where the GRUB /boot folder partition is on the system. GRUB Legacy referencing those values: (hddrive, partition) |
| kernel | Defines the kernel image file stored in the /boot folder to load. |
| initrd | Defines the initial RAM disk file, which contains drivers necessary for the kernel to interact with the system hardware. The initrd command solve a problem that arises when using specialized hardware or filesystems as the root drive. It defines a file that’s mounted by the kernel at boot time as a RAM disk, also called the initrd. The kernel can then load modules from the initrd RAM disk, which then allows it to access hardware or filesystems not compiled into the kernel itself. |
| rootnoverify | Defines non-Linux boot partitions, such as Windows. |
Installing GRUB Legacy
After the GRUB Legacy configuration file is built, the GRUB Legacy program must be installed in the Master Boot Record with the “grub-install” command, which uses a single parameter, in either Linux or GRUB Legacy format, indicating the partition on which to install GRUB.
For example, to use Linux format to install GRUB on the MBR of the first hard drive, enter:
grub-install /dev/sda
When using GRUB Legacy format, enclose the hard drive format in quotes:
grub-install ‘(hd0)’
If chainloading and prefer installing GRUB Legacy on the boot sector of a partition instead of the MBR of a hard drive, specify the partition using either format:
# grub-install /dev/sda1
# grub-install ‘hd(0,0)’
GRUB Legacy reads the configuration file each time it runs.
Interacting with GRUB Legacy
When booting the GRUB Legacy bootloader, you see a menu showing the boot options defined by the configuration file. Waiting for the time-out to expire allows the default boot option to process while using the arrow keys to select one of the boot options and pressing “Enter” selects it. Boot options are also editable on the fly from the GRUB menu using the following sequence of actions:
- Arrow to the boot option you want to modify.
- Press the “E” key.
- Use the “arrow” key to move the cursor to the line to modify.
- Press the “E “key to edit it.
- Boot the system using the new rules by pressing the “B” key.
- At any time, you can press the “C” key to enter an interactive shell mode, allowing command submission on the fly.
GRUB2
Intended as an improvement over GRUB Legacy, GRUB2 shares many features with its older sibling.
Configuring GRUB2
The GRUB2 system stores the configuration file as “grub.cfg“, storing it in the /boot/grub/ folder, allowing you to have both GRUB Legacy and GRUB2 installed simultaneously. Linux distributions usually generate the new grub.cfg configuration file automatically after certain events, such as upgrading the kernel and keep a boot option pointing to the old kernel file just in case the new one fails. You may see some Red Hat–based Linux distributions make a symbolic link to this file in the /etc/grub2.cfg file for easy reference. There are a few changes from the commands used in GRUB Legacy.
As seen in the screenshot below, instead of the “title” command, GRUB2 uses “menuentry“, and you must enclose each individual boot section with braces (highlighted with red boxes) immediately following the “menuentry” command.
Additional differences from GRUB Legacy include:
- Also seen in the screen shot above is that GRUB2 uses the “set” command in assigning values to the root keyword as well an equal sign to assign the device.
- GRUB2 utilizes environment variables to configure settings instead of commands.
- GRUB2 modified the numbering system for partitions compared to its predecessor; it still uses 0 for the first hard drive but the first partition is set to 1. Defining the /boot folder on the first partition of the first hard drive looks like:
set root=hd(0,1)
- The rootnoverify and kernel commands are not used in GRUB2.
- Non-Linux boot options are defined the same as Linux boot options using the root environment variable, and you define the kernel location using the linux command.
- While GRUB2 uses the /boot/grub/grub.cfg file as the configuration file, you should never modify that file (It says that right in the file).
- Use the separate configuration files stored in the /etc/grub.d folder, allowing the creation of specific configuration files for each boot option on the system.
- Use the /etc/default/grub configuration file for global command.
The Installation Process for GRUB2
A bit of a misnomer as you don’t install GRUB2, you just rebuild the installation file by running the “grub-mkconfig” program, which reads configuration files stored in the /etc/grub.d folder and then assembles the commands into the grub.cfg configuration file. Running the “grub-mkconfig” program again updates the configuration file manually:
grub-mkconfig > /boot/grub/grub.cfg
For the update to work, redirect the output of the “grub-mkconfig” program to the “grub.cfg” file as otherwise grub-mkconfig outputs the new configuration commands to standard output.
Using GRUB2
As seen above, the GRUB2 bootloader boot menu shares similarities to the GRUB Legacy method, use:
- The “arrow” keys to switch between boot options,
- The “E” key to edit a boot entry, or
- The “C” key to bring up the GRUB2 command line to submit interactive boot commands.
Other Bootloaders
As a hacker or administrator, you will run into other bootloaders in the wild which may include:
- The Syslinux project includes five separate bootloader programs that have special uses in Linux:
- SYSLINUX: A bootloader for systems that use the Microsoft FAT filesystem (popular for booting from USB memory sticks)
- EXTLINUX: A mini bootloader for booting from an ext2, ext3, ext4, or btrfs filesystem
- ISOLINUX: A bootloader for booting from a LiveCD or LiveDVD. The bootloader requires two files: isolinux.bin, which contains the bootloader program image, and isolinux.cfg, which contains the configuration settings.
- PXELINUX: A bootloader for booting from a network server. Uses the Pre-boot eXecution Environment (PXE) standard, which defines how a network workstation can boot and load an operating system from a central network server. PXE uses DHCP to assign a network address to the workstation and BOOTP to load the bootloader image from the server. The network server must sup- port the TFTP protocol to transfer the boot image file to the workstation.
- To utilize PXELINUX, the TFTP server needs to have the PXELINUX bootloader pro- gram, stored as /tftpboot/pxelinux.0, available for the workstations to download. Each workstation must also have a configuration file available in the /tftpboot/pxelinux.cfg directory. The files are named based on the MAC address of the workstation and contain specific configuration settings required for that workstation.
- has been modified to also load the bootloader image stored on a network server using NFS, HTTP, or even FTP.
- MEMDISK: A utility to boot older DOS operating systems from the other SYSLINUX bootloaders.
System Recovery
There’s nothing worse than starting up your Linux system and not getting a login prompt. Well, actually there is, like your dog dying, your spouse cheating on you or an STD test coming back positive, but in the context of system administration, system crash’s are a pain in the ass. Plenty of things can go wrong in the Linux startup process, but most issues come down to two categories:
- Kernel failures
- Drive failures
Let’s look at some standard troubleshooting practices you can follow to attempt to recover a Linux system that fails to boot. Its both easier and cheaper than trying to fix other problems in your life.
Kernel Failure
When the Linux kernel stops running in memory, you have Kernel failure which cause the Linux system to crash. Often referred to as kernel panic and usually result from software change, such as installing a new kernel without the appropriate module or library changes or starting (or stopping) a program at a new runlevel. More often than not, these types of boot errors can be fixed the old fashion way, by restarting the system using an alternative method and modifying the necessary files to change the system.
Selecting Previous Kernels at Boot
Upgrading your Linux kernel is one of the most common causes of a failed boot, so a word to the wise, much like having a back up boyfriend/girlfriend, when installing a new kernel file, leave the old kernel file in place and create an additional entry in the GRUB boot menu to point to the new kernel. This allows you to select which kernel version to boot. If the new kernel fails to boot properly, you can reboot and select the older kernel version. Like a reliable old friend, most Linux distributions automatically do this when a when new kernel gets added.
Single User Mode
Use single user mode when you need to perform system maintenance (add a new hardware module or library file ) without allowing multiple users to connect. Be aware that this is a security risk should you should use it sparingly. Read Secur’s article on single user mode when you get the chance (follow that link).
The GRUB menu allows starting the system in single-user mode by adding a single command to the Linux line in the boot menu commands. This modification boots the system into runlevel 1, creating a single login for the root user account. An administrator can log as the root user account in order to modify the appropriate modules/init scripts/GRUB boot menu items necessary for the system to start correctly.
Passing Kernel Parameters
Additionally, you can add additional kernel parameters to the linux command in the GRUB boot menu in order to alter hardware modules activated or the hardware settings it looks for with specific devices. You can specify different hardware settings as additional parameters to the kernel in the linux command and then boot from that GRUB menu entry.
Root Drive Failure
Making Use Of A Linux Rescue Disk
Typically boots from the CD drive or as a USB stick, a Linux rescue disk loads a small Linux system into memory, leaving the workstation hard drives free for examination and repair.
You can perform some diagnostic and repair tasks on your system hard drives from the system command-line prompt. The “fsck” command is the most popular tool for checking and fixing hard drive errors is ; it isn’t a program but rather an alias for a family of commands specific to types of filesystems.
Using “fsck” involves running the command against the device name with the partition holding the root directory of your Linux system. If the root directory is on the /dev/sda2 partition, run:
fsck /dev/sda2
The command examines the inode table and the file blocks stored on
the hard drive and attempts to reconcile them. you will be prompted on whether or not to repair any errors found, or add the “-y” parameter to automatically answer yes to all the repair questions.
After the repair, run “fsck” once more to ensure that all errors have been found and corrected; keep running “fsck” until you get a clean run with no errors.
Mounting a Root Drive
Once the “fsck” repair is complete, test the repaired partition by mounting it into the virtual directory using the mount command and mounting it to an available mount directory:
# mount /dev/sda1 /media
Examine the filesystem stored in the partition to ensure that it’s not corrupt and before rebooting, unmount the partition using the umount command:
# umount /dev/sda1
After unmounting, you can reboot your Linux system using the standard bootloader and the standard kernel and runlevels.
