Familiarity with the boot process can be hugely important for properly managing your systems - and particularly for troubleshooting when something doesn't work the way you expect. It just makes sense: a user complains that his PC isn't booting. But that can mean all kinds of things. If you're not getting any display on your monitor, it's likely a hardware problem and you should consider replacing failed components - or maybe just properly plugging in a cable. If you're stuck at a later stage, the kinds of intervention you'll require to correct a bootloader configuration issue will be quite different from what you might do to fix a corrupted filesystem. But if you have no idea how the system is supposed to work, how will you ever know the difference?

This video is meant to cover the basic process of booting a computer running Linux, introducing you to your firmware (BIOS) bootloader (GRUB), and filesystem. We'll go into greater detail for each of these in future videos, both in this course, and in future courses in this series.

Understanding the Linux boot process

For our purposes, the very first thing that happens when you push your computer's power button is that your motherboard's build-in firmware BIOS (Basic Input/Output System) takes an inventory of all the hardware that's currently running on the computer, identifies which drive contains the boot software, and loads the Master Boot Record (MBR) of that drive. The MBR makes up only the first 512 bytes of its drive and uses that space to describe the disk partitions and how to start loading the operating system.

When you originally installed Linux on your computer, the installation process automatically created all necessary partition tables, along with the MBR.

BIOS (or UEFI) will execute GRUB (the GRand Unified Bootloader) Stage 1 from the MBR, which reads the details of the boot drive filesystem and launches either GRUB stage 1.5 (which would itself load GRUB stage 2) or GRUB stage 2 directly. GRUB stage 2 loads into memory, presents the user with menu choices if so configured, and executes the kernel and loads either the initrd or initramfs images.
The kernel will mount the root filesystem specified by GRUB and execute the /sbin/init program (giving init the process ID (PID) of 1). The kernel will use initramfs (or initrd) until the real filesystem is fully booted.

I should mention that SysVinit manager's /sbin/init file continues to exist even on distributions using the newer Upstart or systemd process managers although, at least in the case of systemd, only as a symlink to systemd itself.

Once the operating system has been mounted and loaded into memory, the environment run level specified by boot parameter is executed. Linux allows you to choose between seven - well, actually six - running modes: run level 0 - which instructs the machine to shutdown - could hardly be called a "running" mode.

Each run level is defined by files found within appropriately named directories, like /etc/rc0.d - which obviously controls run level 0, or /etc/rc1.d - which controls run level 1. We're going to discuss run levels and how to manage them in a coming video. As far as we're concerned right now, it's your startup configuration that determines the run level you'll eventually be given once the boot process is complete.

You probably noticed that I mentioned UEFI - Intel's Unified Extended Firmware Interface - just before. While you don't have to know anything about this for the LPIC exam, at some point, you'll probably run into machines built with UEFI - a replacement for BIOS. Because of incompatibilities between UEFI and BIOS, many PCs shipped with more recent Windows releases will not make it easy for you to load Linux without first destroying the Windows install. While that has caused many serious headaches, I can say that the developers for a growing number of Linux distributions have adapted nicely, and configuring a dual-boot, Linux-Windows computer is becoming easier all the time.