Table of Contents
Overview
The Linux boot process is the sequence of steps that turn powered off hardware into a running, multi user operating system. In this chapter you will see the complete flow at a conceptual level, without going deep into BIOS vs UEFI, GRUB2 details, kernel loading internals, initramfs specifics, or troubleshooting techniques, because each of those has its own chapter.
The goal here is to understand the big picture. After reading this chapter you should be able to describe what happens from the moment you press the power button until you see a login prompt or desktop, and you should be able to place individual components such as the bootloader, kernel, and init system into that overall sequence.
From Power On to Login
When you press the power button, your system firmware starts running. On older machines this firmware is usually BIOS, on newer machines it is usually UEFI. The firmware initializes the bare minimum of hardware so that the system can execute code from a storage device. Exactly how that works will be covered later, so here you only need to remember that the firmware chooses a boot device such as a hard disk, SSD, or USB stick and then transfers control to a program stored there, the bootloader.
The bootloader is the first part of Linux that you directly control. On most modern distributions this bootloader is GRUB2, though there are others such as systemd boot or LILO in some older setups. The bootloader knows where your Linux kernel resides and which options it should use, often based on a configuration file that is generated by your distribution. It can also offer a menu with multiple entries, for example different kernel versions, a recovery mode, or other operating systems.
Once the firmware has done its job and the bootloader has started, Linux specific work begins. The bootloader loads the kernel file from disk into memory, optionally loads an initial filesystem image called initramfs, and then gives control to the kernel. From that point on, Linux itself is responsible for bringing the system the rest of the way to a usable state.
The Linux kernel initializes CPU, memory, device drivers, and the basic process management and memory management that every program depends on. In parallel with hardware initialization, the kernel mounts a minimal root filesystem, which is often provided by the initramfs. This temporary filesystem contains just enough tools and drivers to discover and mount the real root filesystem on your disks. After the kernel has switched from the temporary root to the real root filesystem, it starts the first user space process, which is the init system.
On most modern distributions the init system is systemd. In others it might be alternatives such as SysV init or OpenRC. The init system is responsible for starting all the background services, daemons, and other processes that make the system usable. It reads its configuration, determines which services correspond to the current boot configuration, and starts them in the correct order. This includes networking, logging, graphical display management, and many others.
Eventually, the init system starts a login program. On a server that typically means a text based login prompt on one or more virtual consoles. On a desktop system it usually means a graphical display manager that shows a graphical login screen. When you log in, either the shell or the graphical session starts, and from your point of view the system has fully booted.
Main Stages of the Boot Process
Conceptually, the Linux boot process can be divided into a series of stages. The detailed behavior of each stage will be discussed later under the dedicated topics, so here the goal is simply to define the stages and how they connect.
The first stage is firmware initialization. The system firmware powers up the CPU, memory, and some peripheral buses. It performs basic tests and applies configuration chosen in its setup interface. At the end of this stage the firmware selects a bootable device according to its configuration and locates executable bootloader code on that device.
The second stage is bootloader execution. The bootloader lives on the boot device, reads its own configuration, and locates the kernel image and optional initramfs image. Some bootloaders present a menu at this stage so that you can choose which kernel entry to use, or edit boot parameters before continuing.
The third stage is kernel startup. The bootloader passes the CPU to the kernel entry point and also passes any boot parameters that were specified. The kernel unpacks itself in memory, sets up internal data structures, initializes low level drivers, and if an initramfs has been provided, unpacks and mounts that as a temporary root filesystem. During this stage, the kernel also discovers storage devices so that it can mount the real root filesystem from disk.
The fourth stage is the transition to user space. Once the real root filesystem is mounted, the kernel replaces the temporary root with the real one and then executes the first user space program. Traditionally this program had the path /sbin/init, but with modern systems, the kernel can be configured to run other programs at this point. On most distributions the first user space process is now the systemd binary.
The fifth stage is system initialization. The init system treats boot as a set of units or scripts that must be started in an order that respects their dependencies. Networking should start only after certain hardware is ready. A graphical environment should start only after basic system logging is available, and so on. The init system starts system services, mounts additional filesystems, and configures targets or runlevels that define the operating mode of the machine.
The final stage is user login and session startup. A login program such as agetty on text consoles or a graphical display manager such as GDM, SDDM, or LightDM on desktops asks for user credentials. After successful authentication, the user shell or the graphical desktop session is started, and the system moves from booting into normal operation.
You should be able to summarize the sequence as:
Firmware → Bootloader → Kernel → Initramfs (optional) → Real root filesystem → Init system → Services and targets → Login
This linear sequence is the key picture to hold in your mind when you later study firmware types, GRUB2, kernel loading behavior, the details of initramfs, or boot troubleshooting.
Boot Parameters and Control
While much of the boot process is automatic, Linux provides several points where you can influence what happens. Each detailed mechanism belongs to a later chapter, so here the focus is only on the idea that boot parameters exist and where they are applied.
The firmware setup interface lets you choose which devices are allowed to boot and in which order. Changing these settings controls which bootloader will run first if multiple operating systems or disks are present. Secure boot options, legacy compatibility modes, and similar features are all configured at this very early stage, and they affect which bootloader executable is accepted and how it is started.
The bootloader configuration controls which kernel file and which initramfs to use, as well as which command line parameters to pass to the kernel. Bootloaders such as GRUB2 keep this configuration in files on disk that your distribution tools can regenerate. Those configuration files can define multiple menu entries, each with different kernels or different kernel parameters. At boot time you may be able to press a key to select among these entries or to temporarily edit parameters.
Kernel command line parameters are a central way to adjust the behavior of the kernel very early in boot. They are provided by the bootloader and read by the kernel before most subsystems are initialized. Parameters can enable or disable hardware features, select debugging modes, choose the root filesystem device, or modify security related behavior. Many problems that happen before the system reaches a login prompt can be investigated by temporarily changing these parameters.
Later stages of boot are controlled by the init system. On a system that uses systemd, boot behavior is described in units and targets that define which services start by default. Changing which target is the default can, for example, make your system boot directly into a multi user text console environment or into a graphical desktop environment. You can also choose rescue targets or single user style modes for maintenance work. While the configuration formats and commands for systemd itself are covered elsewhere, it is important to understand that they are part of the boot process from the moment the kernel hands control to the first user space process.
Observing the Boot Process
Understanding boot in theory is useful, but you will learn more by observing your system as it starts and by reading what happened afterward. There are several places where Linux records or displays information about the steps that occur during boot.
During early firmware and bootloader stages, messages are usually displayed directly on the screen. Many systems show a logo or a simplified view instead, but often there is a key that you can press to see full diagnostic messages. These messages are not handled by Linux yet, since the kernel has not started, so they are mainly useful when diagnosing firmware or bootloader issues.
Once the kernel starts, it prints messages about hardware discovery, driver loading, and mounting of filesystems. These are the familiar scrolling lines that you may see if your system is not hiding them behind a splash screen. After the system has booted, kernel messages can be viewed from within Linux through logging tools. On systems that use systemd you can ask the journal for messages from the current boot or from previous boots, which makes it easier to see what happened without needing to watch the text scroll past at high speed.
As the init system starts services, each service logs whether it started successfully and may record its own more detailed messages. These logs are crucial when you want to understand why a system does not reach a particular run level or target, or why a specific service is failing to start during boot.
From the user point of view, one of the most important indicators of boot progress is the availability of a login prompt. On text consoles, getty processes are responsible for presenting login prompts. On graphical desktops, the display manager provides a GUI login screen. Their presence tells you that the kernel and init system have completed enough of the boot process that ordinary user sessions can start.
When diagnosing boot problems, always think in terms of which stage failed: firmware, bootloader, kernel, initramfs, or init system and services.
Being able to associate a symptom, such as "nothing appears on screen" or "kernel panic message is shown" or "reaches text login but not graphical desktop", with a stage of boot is a core skill that this chapter prepares you for. The following chapters on firmware boot types, GRUB2, kernel loading, initramfs, and troubleshooting will each refine one part of this overall picture.