Linux - Boot Architecture


IEN-001 - Understanding the Linux Boot Process: From Power-On to User Space

Introduction

Imagine arriving at the office on a Monday morning and discovering that one of your production Linux servers refuses to boot.

Instead of presenting a login prompt, the system stops with one of the following messages:

GRUB Loading...
Error 15: File not found


or

Kernel panic - not syncing:
VFS: Unable to mount root fs on unknown-block(0,0)


or

dracut-initqueue timeout


or perhaps it simply remains at a blinking cursor without displaying any error message.

Although these symptoms appear unrelated, they all originate from different stages of the Linux boot process.

This is one of the most common mistakes made by junior Linux administrators. They treat every boot problem as an isolated issue and immediately search for a command that promises to fix it. As a result, they often reinstall GRUB when the real problem is a missing initramfs, rebuild initramfs when the actual issue lies in an inactive LVM volume, or run filesystem repair tools against disks that are perfectly healthy.

Experienced infrastructure engineers take a different approach.

Rather than asking "How do I fix this error?", they ask "At which stage of the boot process did the system fail?"

Once that question is answered, the number of possible root causes becomes dramatically smaller.

Understanding the Linux boot process is therefore not just an academic exercise. It is one of the most valuable troubleshooting skills an engineer can develop. Whether the server is a physical machine, a virtual machine running on VMware, a cloud instance, or a container host, every Linux system follows the same fundamental startup sequence before it becomes operational.

Throughout this article, we will follow that sequence step by step—from the moment electrical power reaches the motherboard until the operating system launches its first user-space process. More importantly, we will explain not only what happens during each stage, but also why it happens, how to verify it, and what kinds of failures are commonly associated with it.

This article serves as the foundation for the Linux series in Infrastructure Engineering Notes. Future articles covering GRUB recovery, initramfs reconstruction, LVM activation, kernel panic analysis, and disaster recovery will all build upon the concepts introduced here.

Learning Objectives

After reading this article, you should be able to:

The Linux Boot Process at a Glance

Although the Linux boot process involves hundreds of individual operations, it can be simplified into eight major stages.

                 +----------------------+
                 |   Power Button       |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | Firmware (BIOS/UEFI) |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 |   Hardware POST      |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 |   Bootloader (GRUB)  |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 |   Linux Kernel       |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | initrd / initramfs   |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | Root Filesystem Mount|
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | PID 1 (init/systemd) |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | System Services      |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | Login Prompt / GUI   |
                 +----------------------+


Each stage depends entirely on the successful completion of the previous one.

If the firmware cannot detect the boot disk, the bootloader will never execute.

If the bootloader cannot load the Linux kernel, the operating system never starts.

If the kernel cannot access the initramfs, it may not have the drivers required to locate the root filesystem.

If the root filesystem cannot be mounted, userspace never begins.

If PID 1 cannot start, the system has no process responsible for launching services.

In other words, Linux does not "boot all at once." It progresses through a chain of dependent stages, where every stage assumes that the previous stage completed successfully.

This dependency chain is one of the most important concepts to remember throughout this article.

Why Understanding the Boot Process Matters

Many engineers become familiar with Linux through daily operational tasks such as managing services, configuring networks, or deploying applications. As long as the server reaches a login prompt, there is little need to think about what happened beforehand.

The situation changes immediately when the system fails to boot.

At that point, understanding the startup sequence becomes essential.

Consider the following examples:

Error Message Actual Problem Stage
No Boot Device Found Firmware
GRUB Rescue Prompt Bootloader
Kernel Panic Kernel
Unable to Mount Root Filesystem initramfs / Storage
Volume Group Not Found LVM Activation
/sbin/init not found Userspace Initialization

Notice that each error belongs to a different stage of the boot process.

Without understanding the startup sequence, every failure looks similar: "the server won't boot."

With a proper understanding of the boot sequence, the troubleshooting process changes completely.

Instead of guessing, you begin asking structured questions:

Each answer narrows the scope of the investigation.

This systematic approach is what separates experienced infrastructure engineers from administrators who rely solely on memorized commands.

The Boot Process Begins Before Linux Exists

One common misconception is that Linux starts executing as soon as the power button is pressed.

In reality, Linux is not involved during the earliest stages of the startup process.

When the power button is pressed, the operating system does not yet exist in memory.

Instead, the following events occur:

Power Button Pressed
        │
        ▼
Power Supply Stabilizes
        │
        ▼
CPU Reset
        │
        ▼
Firmware Starts (BIOS / UEFI)
        │
        ▼
Hardware Initialization


At this moment:

The only software executing is the firmware stored on the motherboard.

Its responsibility is to prepare the hardware so that an operating system can eventually be loaded.

This distinction is important because failures occurring before the bootloader appears are not Linux problems. They are firmware or hardware problems.

For example:

Trying to repair GRUB or rebuild an initramfs will never solve these issues because Linux has not yet started.

Engineering Insight

One of the most common troubleshooting mistakes is attempting to fix a problem in the wrong stage of the boot process.

For example, rebuilding the initramfs will not help if the firmware cannot detect the boot disk. Likewise, reinstalling GRUB will not resolve a missing LVM volume that prevents the root filesystem from being mounted.

Always identify where the boot sequence stops before deciding how to fix it. Correctly identifying the failed stage often eliminates the majority of possible root causes and leads to a much faster, evidence-based investigation.

IEN-002 - Stage 1 — Firmware Initialization (BIOS & UEFI)

Before Linux, before GRUB, and even before the operating system exists, the computer must first prepare itself to execute software.

This responsibility belongs to the system firmware.

For decades this firmware was known as the Basic Input/Output System (BIOS). Modern systems have largely replaced BIOS with the Unified Extensible Firmware Interface (UEFI), but regardless of the implementation, both serve the same fundamental purpose:

Initialize the hardware and locate a bootable operating system.

Without firmware, the processor has no knowledge of memory, storage devices, keyboards, displays, or even where the operating system is stored.

The firmware acts as the bridge between powered hardware and the operating system.

What Happens When You Press the Power Button?

Although pressing the power button appears to be a single action, it actually triggers a carefully coordinated sequence of hardware events.

Power Button
      │
      ▼
Power Supply Starts
      │
      ▼
Voltage Stabilizes
      │
      ▼
CPU Reset
      │
      ▼
Firmware Execution
      │
      ▼
Hardware Initialization
      │
      ▼
POST
      │
      ▼
Boot Device Selection


Let's examine each step.

Step 1 — Power Supply Initialization

When the power button is pressed, the motherboard sends a signal to the power supply unit (PSU).

The PSU does not immediately provide full power to the system.

Instead, it gradually stabilizes all required voltage rails, such as:

Only after these voltages become stable does the PSU assert a signal commonly called Power Good (PWR_OK).

This signal tells the motherboard:

"The electrical power is stable. The processor may begin execution."

If the PSU never asserts this signal, the CPU never starts.

Step 2 — CPU Reset

Once power is stable, the processor exits its reset state.

An important question arises:

How does the CPU know what instruction to execute first?

The answer is surprisingly simple.

The processor does not search the hard drive.

It does not search memory.

Instead, every CPU contains a predefined Reset Vector.

Immediately after reset, the CPU jumps to this fixed memory location.

Historically, on x86 processors, this address is:

FFFF:0000


or, in physical addressing,

0xFFFFFFF0


This location is mapped to firmware stored in non-volatile memory on the motherboard.

The CPU therefore begins executing firmware instructions—not Linux.

Engineering Insight

Many engineers imagine the CPU "looking for Linux."

It doesn't.

The CPU blindly executes the instruction located at the reset vector.

Everything else—including loading Linux—is performed later by firmware.

Step 3 — Firmware Execution

At this point the firmware begins running.

Depending on the system, this firmware may be:

Although their implementations differ significantly, both begin by initializing the computer's hardware.

Typical initialization includes:

Without this initialization, the operating system would have no usable hardware.

POST (Power-On Self-Test)

One of the firmware's first major responsibilities is performing the Power-On Self-Test, commonly called POST.

POST verifies that essential hardware components are functional before attempting to boot an operating system.

Typical checks include:

Component Purpose
CPU Verify processor responds correctly
RAM Detect installed memory
Video Adapter Initialize display output
Keyboard Verify input device
Storage Controllers Detect disks
Firmware Integrity Validate firmware operation

If a critical failure occurs, the boot process stops immediately.

Examples include:

Many servers report POST failures through:

Enterprise servers from vendors such as Dell, HPE, Lenovo, Inspur, and Supermicro often expose POST events through their management controllers.

Hardware Discovery

After POST completes successfully, firmware begins discovering available hardware.

Modern systems may contain dozens or even hundreds of devices.

Examples include:

CPU

Memory

PCIe Devices

NICs

RAID Controllers

HBAs

NVMe Drives

USB Controllers

Graphics Adapters


Each discovered device receives system resources such as:

Only after this discovery phase can the operating system communicate with the hardware.

BIOS vs UEFI

Both BIOS and UEFI prepare the system for booting, but they are fundamentally different architectures.

BIOS UEFI
Introduced in the 1980s Modern firmware architecture
16-bit environment 32-bit or 64-bit environment
MBR partition table GPT partition table
Maximum disk size ≈ 2 TB Supports very large disks
Limited firmware functionality Extensible firmware services
Loads boot code from the MBR Loads EFI executables from the EFI System Partition

Legacy BIOS executes the first sector of the selected boot disk, known as the Master Boot Record (MBR).

UEFI works differently.

Instead of executing raw boot code from the first sector, it loads an EFI application stored inside a dedicated EFI System Partition (ESP).

For Linux systems, this EFI application is often GRUB or another EFI-compatible bootloader.

Engineering Insight

One common misconception is that UEFI is simply a "new BIOS."

In reality, UEFI is a complete firmware platform with its own filesystem support, boot manager, runtime services, and application loader. Unlike BIOS, which merely executes the first sector of a disk, UEFI can directly read files from the EFI System Partition and launch EFI executables.

Selecting the Boot Device

Once hardware initialization is complete, the firmware must decide which device to boot from.

Typical boot devices include:

The firmware follows its configured boot order.

For example:

1. NVMe SSD
2. SATA SSD
3. PXE Network
4. USB


It attempts each device until a valid boot target is found.

If no bootable device is available, booting stops before Linux is ever loaded.

Typical messages include:

No Boot Device Found


or

Operating System Not Found


or

Insert Boot Media


These errors are frequently mistaken for Linux problems, but they actually indicate that the firmware could not locate a bootable operating system.

Where Can Things Go Wrong?

Understanding common failures at this stage helps narrow down troubleshooting quickly.

Symptom Likely Cause Linux Running?
System does not power on PSU or motherboard issue ❌ No
Continuous beep codes Hardware failure detected during POST ❌ No
Memory training failure Defective or incompatible RAM ❌ No
"No Boot Device Found" Disk not detected or incorrect boot order ❌ No
"Operating System Not Found" Missing or damaged bootloader ❌ Not yet

Notice that Linux has not started in any of these scenarios. Rebuilding initramfs, reinstalling GRUB, or repairing filesystems would not resolve problems that occur before the firmware successfully hands control to the bootloader.

Summary

The firmware stage is responsible for preparing the system to run an operating system. It initializes hardware, performs POST, discovers available devices, and selects a bootable storage device. Only after these tasks are completed does it transfer control to the bootloader.

This stage forms the foundation of the entire boot process. If firmware initialization fails, Linux never has the opportunity to start.

IEN-003 - Stage 2 — The Bootloader (GRUB)

At the end of the firmware stage, the computer has completed its hardware initialization and identified a bootable storage device.

However, the firmware still faces one fundamental problem:

It knows where the operating system is stored, but it does not know how to load it.

This is where the bootloader comes into play.

The bootloader acts as the bridge between the firmware and the operating system. Its primary responsibility is to locate the Linux kernel, load it into memory, provide the necessary boot parameters, load the initial RAM disk (initrd or initramfs), and finally transfer execution to the kernel.

Without a bootloader, the firmware has no knowledge of Linux-specific file formats, filesystem layouts, or kernel images.

The bootloader is therefore the first piece of software that understands how to start Linux.

Why Do We Need a Bootloader?

A common misconception is that the firmware could simply load the Linux kernel directly.

While this is technically possible in certain specialized systems, it is not how general-purpose computers are designed.

The firmware is intentionally kept generic. It can initialize hardware and locate a bootable device, but it does not understand:

Instead, the firmware loads a small program whose sole purpose is boot management.

That program is the bootloader.

Its responsibilities include:

The Boot Sequence So Far

At this point, the startup sequence looks like this:

Power On
    │
    ▼
Firmware (BIOS / UEFI)
    │
    ▼
POST
    │
    ▼
Boot Device Selected
    │
    ▼
Bootloader (GRUB)
    │
    ▼
Linux Kernel


Notice that Linux itself is still not running.

GRUB is responsible for preparing everything the kernel needs before handing over control.

A Brief History of Linux Bootloaders

Before GRUB became the de facto standard, Linux systems used several different bootloaders.

Some of the most well-known include:

Bootloader Status Notes
LILO Legacy One of the earliest Linux bootloaders. Required reinstallation after kernel changes.
GRUB Legacy Legacy Widely used by RHEL 5, CentOS 5, and many older distributions.
GRUB2 Current Successor to GRUB Legacy. More modular and feature-rich.
systemd-boot Current Lightweight bootloader primarily used on UEFI systems.

Because much of the Infrastructure Engineering Notes series focuses on enterprise environments—including legacy systems such as RHEL 5—we will encounter both GRUB Legacy and GRUB2.

Understanding their differences is essential when performing recovery operations.

GRUB Legacy vs GRUB2

Although both bootloaders share the same goal, their internal design differs considerably.

Feature GRUB Legacy GRUB2
Typical distributions RHEL 5, CentOS 5 RHEL 7+, Ubuntu, Debian, Rocky Linux
Configuration file /boot/grub/grub.conf /boot/grub2/grub.cfg or /boot/efi/EFI/...
Configuration generation Manual editing Automatically generated
Module support Limited Modular architecture
Filesystem support Basic Extensive
UEFI support No Yes

One important point is that GRUB2 is not simply a newer version of GRUB Legacy. It is a complete redesign.

For example, on RHEL 5 you typically edit grub.conf directly. On modern systems, editing grub.cfg manually is discouraged because it is generated automatically from configuration templates.

This distinction becomes important during recovery scenarios.

Inside GRUB Legacy

Under legacy BIOS systems, GRUB is traditionally divided into multiple stages.

+----------------------+
| Stage 1              |
| (MBR)                |
+----------+-----------+
           │
           ▼
+----------------------+
| Stage 1.5            |
| Filesystem Support   |
+----------+-----------+
           │
           ▼
+----------------------+
| Stage 2              |
| Full GRUB            |
+----------+-----------+
           │
           ▼
Read grub.conf
           │
           ▼
Load Kernel
           │
           ▼
Load initrd


Let's examine each stage.

Stage 1

Stage 1 occupies the first 446 bytes of the Master Boot Record (MBR).

Its size is extremely limited, so it cannot understand filesystems or locate the Linux kernel directly.

Its only responsibility is to load the next stage.

Stage 1.5

Stage 1.5 resides immediately after the MBR in the so-called embedding area.

Unlike Stage 1, it contains basic filesystem drivers.

This allows GRUB to read files from partitions such as ext2 or ext3.

Without Stage 1.5, Stage 1 would have no way to locate the full GRUB program stored within the filesystem.

Stage 2

Stage 2 is the full bootloader.

It provides:

When users refer to "GRUB," they are usually interacting with Stage 2.

The GRUB Configuration File

Once Stage 2 starts, GRUB searches for its configuration file.

On GRUB Legacy systems, this file is usually:

/boot/grub/grub.conf


or

/boot/grub/menu.lst


The configuration file defines:

A simplified example looks like this:

title Red Hat Enterprise Linux

root (hd0,0)

kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/VolGroup00/LogVol00

initrd /initrd-2.6.18-128.el5.img


Each line has a specific purpose:

If any of these paths are incorrect, GRUB may fail before the Linux kernel even begins execution.

Engineering Insight

One of the most common production issues after restoring or cloning a server is that the kernel and initrd files no longer match the entries in grub.conf. GRUB itself is functioning correctly, but it is instructed to load files that no longer exist or belong to a different kernel version. The result can range from a simple "File not found" message to a kernel panic later in the boot process.

This is exactly the type of issue we encountered during our RHEL 5.2 recovery project, and we will revisit it in detail later in this series.

Loading the Linux Kernel

Once a boot entry is selected, GRUB performs one of its most important tasks: loading the Linux kernel into memory.

At this stage, the kernel is still just a compressed binary file stored on disk.

GRUB reads this file from the /boot filesystem, copies it into RAM, and prepares the execution environment.

Immediately afterward, it loads the corresponding initrd (or initramfs) image into memory as well.

Only when both components are ready does GRUB transfer control to the Linux kernel.

From that moment onward, the bootloader's job is complete.

The Linux kernel takes over, and the boot process enters its next stage.

Common Bootloader Failures

Understanding common failures helps quickly identify whether a problem belongs to the bootloader stage.

Symptom Likely Cause
grub> prompt Missing or incorrect configuration
grub rescue> GRUB cannot locate its modules or filesystem
Error 15: File not found Kernel or initrd path is incorrect
Unknown filesystem Filesystem driver unavailable or partition damaged
Boot menu does not appear Corrupted GRUB installation or wrong boot target

A key observation is that none of these errors originate from the Linux kernel. They occur before the kernel starts executing.

Summary

The bootloader is responsible for bridging the gap between firmware and the Linux kernel. It locates the kernel image, loads the initial RAM disk, passes kernel parameters, and transfers control to the operating system.

A failure at this stage prevents Linux from starting entirely, making it essential to distinguish bootloader issues from kernel or userspace problems.

IEN-004 - Stage 3 — Linux Kernel Initialization

At the end of the previous stage, GRUB has successfully loaded two critical files into memory:

It has also prepared the kernel command line, which may include parameters such as:

root=/dev/mapper/vg_root-lv_root ro rhgb quiet

or

root=UUID=0d6d0b68-8d95-42d6-bf7c-8a88f6b82d5e

or, as we encountered during our RHEL 5.2 recovery project:

acpi=no

At this point, everything the kernel needs has been placed into memory.

GRUB's work is complete.

The CPU now performs one of the most significant transitions during the entire startup sequence:

Execution is transferred from the bootloader to the Linux kernel.

From this moment onward, Linux—not the firmware or GRUB—is responsible for bringing the system to life.

The Kernel Is Not Yet an Operating System

Many people think Linux "starts" the moment GRUB loads the kernel.

Technically, that is not true.

The kernel is only a binary image stored in memory.

It has not yet:

Think of the kernel as the blueprint of a city before any roads, electricity, or buildings have been constructed.

The blueprint exists—but the city is not operational.

The first responsibility of the kernel is therefore to build its own operating environment.

From Compressed Image to Running Kernel

The kernel image stored in /boot is typically compressed.

On most systems, the file looks something like:

vmlinuz-5.14.0-503.el9.x86_64

Notice the name:

vmlinuz

The "z" indicates that the kernel image is compressed.

Why?

Because compressed kernels:

Immediately after execution begins, the kernel performs its own decompression.

A simplified sequence looks like this:

GRUB
    │
    ▼
Load compressed kernel
    │
    ▼
Jump to kernel entry point
    │
    ▼
Kernel decompression
    │
    ▼
Kernel relocates itself
    │
    ▼
Kernel begins initialization

Only after decompression does the actual kernel begin executing.

Setting Up the CPU

The very first task of the kernel is preparing the processor.

Although the firmware has already initialized the CPU enough to execute code, Linux requires far more control.

The kernel configures features such as:

Modern systems may contain dozens or even hundreds of CPU cores.

The kernel must detect every available processor and prepare them for scheduling.

Typical kernel messages include:

SMP: Total of 32 processors activated.

or

Detected 16 logical CPUs.

At this stage, only a very small portion of the kernel is active.

Memory Initialization

Once the processor is ready, the kernel turns its attention to memory.

RAM is the foundation upon which every process, filesystem cache, driver, and application depends.

The kernel must determine:

A simplified memory map might look like this:

+------------------------------+
| Kernel Image                 |
+------------------------------+
| Reserved Firmware Memory     |
+------------------------------+
| DMA Region                   |
+------------------------------+
| Available RAM                |
+------------------------------+
| High Memory                  |
+------------------------------+

From this point onward, Linux begins managing memory instead of relying on firmware.

This transition is fundamental because all future allocations—processes, drivers, caches, page tables—depend on the kernel's memory manager.

Engineering Insight

One of Linux's greatest strengths is that the firmware is only needed during the earliest stages of boot.

Once initialization is complete, the kernel takes full ownership of system resources.

From this point forward, Linux manages memory, processors, interrupts, and devices independently of the firmware.

Initializing Core Kernel Subsystems

With the CPU and memory prepared, the kernel begins activating its internal subsystems.

These subsystems provide the fundamental services required by every part of the operating system.

Examples include:

You can think of these as the "operating system inside the operating system."

Without them, Linux cannot execute processes or communicate with hardware.

Device Driver Initialization

Once the kernel infrastructure is operational, Linux begins initializing device drivers.

Drivers are responsible for communicating with hardware such as:

A simplified sequence is shown below:

Kernel
    │
    ▼
PCI Bus Scan
    │
    ▼
Device Discovery
    │
    ▼
Match Driver
    │
    ▼
Initialize Device

This process is essential.

If the kernel lacks the driver required for the storage controller containing the root filesystem, the boot process cannot continue.

The Kernel Still Cannot Access the Root Filesystem

This surprises many engineers.

At this point the kernel has:

yet it still cannot mount the root filesystem.

Why?

Because the storage stack may not yet be complete.

Enterprise Linux systems commonly use technologies such as:

The kernel alone often does not have enough information or modules to activate these storage layers.

It therefore requires assistance from another component:

The Initial RAM Disk (initrd/initramfs).

This is precisely why the bootloader loaded the initrd alongside the kernel.

The kernel's next step is to unpack that temporary root filesystem and execute its /init program.

Common Kernel Initialization Failures

Many boot failures occur during kernel initialization.

Some of the most common include:

Symptom Likely Cause
Kernel panic - not syncing Fatal kernel error
Unable to mount root fs Root filesystem cannot be located
No working init found /init or /sbin/init missing
Unknown-block(0,0) Storage device unavailable
System freezes after "Loading kernel..." Early kernel initialization failure

A crucial point to remember is that a kernel panic does not always mean the kernel itself is defective.

In many cases, the kernel is functioning correctly but cannot proceed because it lacks access to the storage or userspace required for the next stage.

Understanding exactly where the panic occurs is therefore far more valuable than the panic message alone.

Engineering Insight

One of the most misunderstood boot errors is:

Kernel panic - not syncing:
VFS: Unable to mount root fs

Although the message contains the words Kernel panic, the underlying problem is frequently not the kernel binary itself. More commonly, the kernel cannot locate or access the root filesystem because the required storage driver, LVM activation, RAID assembly, or filesystem module is unavailable. Treating every kernel panic as a "kernel problem" often leads engineers in the wrong direction.

Summary

By the end of this stage, the Linux kernel has transformed from a compressed image on disk into a running operating system core. It has initialized the CPU, taken control of memory management, activated its internal subsystems, and begun communicating with hardware through device drivers.

However, the system is still incomplete. The kernel knows how to manage hardware, but it may not yet know where the real root filesystem resides.

To bridge that gap, the kernel hands control to the initial RAM disk (initrd/initramfs), which will load any remaining drivers, activate storage technologies such as LVM or RAID, and prepare the real root filesystem for mounting.

IEN-005 - Stage 4 — initrd / initramfs: Preparing the System to Mount the Root Filesystem

By the end of the previous stage, the Linux kernel is fully operational.

It has:

Despite all of this progress, the system still cannot boot completely.

One critical problem remains.

The kernel still does not know how to access the real root filesystem.

This may sound surprising.

After all, the kernel was loaded from the disk.

Shouldn't it already know where the operating system is?

The answer is:

Not necessarily.

Modern Linux systems often place the root filesystem behind one or more abstraction layers.

For example:

Disk
 │
 ▼
RAID
 │
 ▼
LVM
 │
 ▼
Filesystem
 │
 ▼
Root (/)


or

Disk
 │
 ▼
Multipath
 │
 ▼
LVM
 │
 ▼
Filesystem
 │
 ▼
Root (/)


or even

SAN Storage
 │
 ▼
Fibre Channel
 │
 ▼
Multipath
 │
 ▼
LVM
 │
 ▼
XFS
 │
 ▼
Root (/)


At this moment, the kernel has not yet assembled these storage layers.

It cannot simply mount /.

Something else must prepare the environment first.

That "something" is the Initial RAM Disk, commonly known as initrd or initramfs.

Why Does initrd Exist?

To understand why initrd exists, let's look at the history of Linux.

In the early days, Linux systems were much simpler.

A typical machine looked like this:

IDE Disk
    │
    ▼
ext2 Filesystem
    │
    ▼
Root Filesystem


The kernel already contained all required drivers.

Booting was straightforward.

Kernel

↓

Mount Root

↓

Start init

No temporary filesystem was necessary.

As Linux evolved, systems became significantly more complex.

Modern enterprise servers may use:

Bundling every possible driver into the kernel would make it unnecessarily large and difficult to maintain.

Instead, Linux adopted a modular design.

Only essential components remain built into the kernel.

Additional modules are loaded during early boot from a temporary filesystem.

That temporary filesystem is initrd (or, on modern systems, initramfs).

initrd vs initramfs

Although the terms are often used interchangeably, they are not identical.

initrd initramfs
Older implementation Modern implementation
Block device backed RAM filesystem
Used heavily by RHEL 5 and older distributions Used by modern Linux distributions
Typically created with mkinitrd Typically created with dracut
Less flexible More flexible and efficient

Because this series includes both legacy and modern Linux systems, we will use the term initrd when discussing older environments such as RHEL 5, and initramfs when referring to newer systems.

What Is Inside initrd?

Many administrators think of initrd as a mysterious binary blob.

In reality, it is simply a compressed filesystem image containing everything needed to prepare the system for mounting the real root filesystem.

Typical contents include:

/init
/bin
/sbin
/lib
/lib/modules
/dev
/proc
/sys


More importantly, it contains:

Think of initrd as a miniature Linux system whose only purpose is to prepare the real Linux system.

Boot Flow with initrd

Once the kernel has completed its initialization, it unpacks the initrd into memory.

The process now looks like this:

GRUB
 │
 ▼
Kernel
 │
 ▼
Unpack initrd
 │
 ▼
Temporary Root Filesystem
 │
 ▼
Execute /init


Notice something important.

The kernel has not mounted the real root filesystem yet.

Instead, it mounts the temporary root filesystem provided by initrd.

From this point onward, the /init program inside initrd becomes responsible for preparing the real storage environment.

What Happens Inside initrd?

This is where most enterprise boot logic takes place.

The /init program performs tasks such as:

  1. Loading additional kernel modules.
  2. Starting udev.
  3. Detecting storage devices.
  4. Loading storage controller drivers.
  5. Detecting RAID arrays.
  6. Activating LVM volume groups.
  7. Starting multipath services.
  8. Locating the root filesystem.
  9. Mounting the real root filesystem.
  10. Switching execution to the real system.

A simplified workflow looks like this:

Kernel
    │
    ▼
Execute /init
    │
    ▼
Load Modules
    │
    ▼
Detect Storage
    │
    ▼
Activate LVM
    │
    ▼
Locate Root Filesystem
    │
    ▼
Mount Root
    │
    ▼
switch_root


LVM Activation

Let's focus on one of the most important steps.

Many enterprise Linux installations store the root filesystem inside LVM.

For example:

Disk
 │
 ▼
Physical Volume (PV)
 │
 ▼
Volume Group (VG)
 │
 ▼
Logical Volume (LV)
 │
 ▼
XFS / ext4
 │
 ▼
Root Filesystem


The kernel cannot mount:

/dev/mapper/vg_root-lv_root


unless the Volume Group has already been activated.

That activation happens inside initrd.

Internally, tools equivalent to:

vgscan
vgchange -ay


(or their initramfs equivalents) make the logical volumes available before the root filesystem is mounted.

Without this step, the kernel has no device to mount as /.

Engineering Insight

This explains why LVM-related boot failures almost always appear before the system reaches systemd or the login prompt. If the Volume Group cannot be activated during the initrd stage—because a Physical Volume is missing, metadata is corrupted, or the necessary LVM tools are absent—the root filesystem never becomes available. The kernel is left waiting for a device that does not exist, and the boot process cannot continue.

This is exactly the class of problem we encountered during the RHEL 5.2 recovery after the Acronis restore. The issue was not with the kernel itself, but with the early userspace environment failing to expose the expected storage layout.

Device Discovery

While LVM is being activated, initrd also waits for storage devices to appear.

This includes:

Enterprise storage may require several seconds before all devices become available.

The initrd environment is responsible for waiting, probing, and assembling these devices before attempting to mount the root filesystem.

switch_root

Once the real root filesystem has been successfully mounted, the temporary initrd environment is no longer needed.

Instead of rebooting or restarting, Linux performs a handoff.

This operation is called switch_root (historically, some systems used pivot_root).

The transition looks like this:

Temporary Root (initrd)
        │
        ▼
Real Root Filesystem
        │
        ▼
switch_root
        │
        ▼
Execute /sbin/init


After this point, the initrd environment is discarded, and the real operating system takes over.

This is the first moment during the boot process where the system begins executing programs from the permanent root filesystem.

Common initrd / initramfs Failures

Because initrd is responsible for preparing the storage stack, failures here are often related to storage, drivers, or root filesystem discovery.

Symptom Likely Cause
dracut-initqueue timeout Storage device never appeared
Volume Group not found LVM activation failed
No root device found Incorrect root= parameter or missing driver
Kernel panic - unable to mount root fs Root filesystem could not be mounted
Waiting for root device Storage initialization incomplete

One important observation is that these errors occur after the kernel has started, but before the real operating system begins. Understanding that distinction helps avoid troubleshooting the wrong component.

Summary

The initrd/initramfs stage bridges the gap between a running kernel and a usable operating system. It provides a temporary userspace where additional drivers can be loaded, storage technologies such as LVM and RAID can be activated, and the real root filesystem can be located and mounted.

Without this stage, many modern Linux systems would be unable to boot because the kernel alone lacks the information required to discover complex storage configurations.

IEN-006 - Stage 5 — Mounting the Root Filesystem

After the initrd (or initramfs) has completed its work, the system finally reaches one of the most important milestones in the entire boot process:

The real root filesystem can now be mounted.

Everything that happened before this point—from firmware initialization to loading storage drivers—had one ultimate goal:

Make the root filesystem accessible.

Only after the root filesystem is mounted can Linux begin executing the programs that make up the operating system itself.

What Is the Root Filesystem?

Every Linux system has a directory called:

/

This directory is known as the root filesystem.

It is the highest level of the Linux directory hierarchy.

Everything else exists beneath it.

For example:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── proc
├── root
├── run
├── sbin
├── sys
├── tmp
├── usr
└── var

Every application, configuration file, shared library, and executable ultimately resides somewhere under this hierarchy.

Without the root filesystem, Linux has nowhere to find:

At this stage, these files still do not exist in the running environment.

The system is still operating from the temporary initrd.

Temporary Root vs Real Root

One concept that often confuses Linux administrators is the existence of two different root filesystems during boot.

The first is the temporary root filesystem provided by initrd.

The second is the permanent root filesystem stored on disk.

Temporary Root (initrd)
        │
        ▼
Prepare Storage
        │
        ▼
Mount Real Root
        │
        ▼
switch_root
        │
        ▼
Permanent Root Filesystem

The temporary root exists only to make the permanent root accessible.

Once the permanent root is ready, the temporary one is discarded.

Engineering Insight

Many engineers assume that the / directory they see after logging in has existed since the kernel started.

In reality, the first / belongs to the initrd environment. The root filesystem you interact with after the system boots is a completely different filesystem that replaces the temporary one through the switch_root process.

Understanding this transition makes it much easier to troubleshoot early boot failures.

The Virtual Filesystem (VFS)

Before mounting any filesystem, Linux uses an abstraction layer called the Virtual Filesystem (VFS).

The VFS allows the kernel to interact with different filesystem types through a common interface.

Whether the underlying filesystem is:

the kernel uses the same internal API.

A simplified architecture looks like this:

Applications
      │
      ▼
Virtual Filesystem (VFS)
      │
      ├───────────────┬───────────────┬───────────────┐
      ▼               ▼               ▼
    ext4             XFS            Btrfs
      │               │               │
      ▼               ▼               ▼
   Storage Device   Storage Device  Storage Device

This abstraction allows Linux to support many filesystem types without requiring applications to know which one is in use.

Finding the Root Filesystem

At this point, the initrd environment has already activated storage devices such as:

The kernel now attempts to locate the root filesystem specified by the kernel command line.

For example:

root=/dev/sda2

or

root=/dev/mapper/vg_root-lv_root

or

root=UUID=31fd66b5-dfd6-4d96-9c65-aab7c6d79e5d

The kernel resolves this parameter to an actual block device.

If the device exists and the required filesystem driver is available, the filesystem can be mounted.

Why UUID Is Preferred

Modern Linux systems usually avoid using device names such as:

/dev/sda1

Instead they use:

UUID=31fd66b5-dfd6-4d96-9c65-aab7c6d79e5d

or

LABEL=rootfs

Why?

Because device names are not guaranteed to remain consistent.

Adding another disk may change:

/dev/sda

into

/dev/sdb

which could prevent the system from booting.

UUIDs remain stable regardless of device ordering.

Mounting the Filesystem

Once the root device has been located, Linux mounts it.

Initially, many distributions mount the filesystem as:

read-only

This allows the kernel to perform consistency checks before permitting write operations.

Later during the boot process, it is remounted as:

read-write

This transition often occurs before system services begin starting.

The switch_root Operation

After the root filesystem has been mounted successfully, Linux reaches another critical milestone.

The temporary initrd environment has fulfilled its purpose.

Execution must now continue from the real operating system.

This transition is performed by:

switch_root

The sequence looks like this:

Kernel
      │
      ▼
Temporary Root
      │
      ▼
Mount Real Root
      │
      ▼
switch_root
      │
      ▼
Execute /sbin/init

The switch_root operation replaces the temporary root filesystem with the permanent one.

From this point onward:

all come from the real operating system installed on disk.

The initrd environment disappears completely.

What Happens If Mounting Fails?

Failure at this stage is one of the most common causes of boot problems.

Typical reasons include:

Depending on the failure, the system may display messages such as:

VFS: Cannot open root device

or

Kernel panic - not syncing:
VFS: Unable to mount root fs

or

Waiting for root device...

Although these messages mention the kernel, the underlying issue is frequently related to storage discovery rather than a defect in the kernel itself.

Engineering Insight

One of the easiest mistakes to make during recovery is focusing only on the final error message.

For example, if the system reports "Unable to mount root filesystem", it is tempting to assume the filesystem is corrupted.

However, the filesystem may never have been reached.

The real issue could be:

Always verify that the expected block device actually exists before attempting filesystem repair.

Verifying the Root Device

During recovery or rescue mode, several commands can help confirm that the expected root device is available.

lsblk

Displays the hierarchy of block devices and mounted filesystems.

blkid

Shows UUIDs and filesystem types.

cat /proc/cmdline

Displays the kernel command line, including the root= parameter used during boot.

mount

Shows which filesystems are currently mounted.

cat /proc/mounts

Lists active mount points from the kernel's perspective.

These commands are often the first step when investigating boot issues involving storage or root filesystem discovery.

Summary

The goal of the previous stages was never simply to start the kernel—it was to make the real root filesystem available.

Once the root filesystem has been mounted, Linux leaves the temporary initrd environment behind and transitions to the permanent operating system through switch_root.

From this moment onward, the kernel can begin executing programs stored on the real filesystem, starting with the very first userspace process.

This process, known as PID 1, is responsible for initializing the rest of the operating system and will be the focus of the next stage.

IEN-007 - Stage 6 — PID 1: The Beginning of User Space

At the end of the previous stage, the Linux kernel has successfully mounted the real root filesystem.

The temporary initrd environment has completed its job and has been discarded through the switch_root operation.

For the first time since the system was powered on, the kernel has access to the complete operating system installed on disk.

Yet one question remains:

Who starts everything else?

The kernel is responsible for managing hardware, memory, scheduling, and system calls, but it does not start services, launch user sessions, or manage applications directly.

Instead, it hands control to the first userspace process.

That process is known as PID 1.

Everything that happens after this point ultimately begins with PID 1.

What Is PID 1?

In Linux, every running program is represented as a process.

Each process receives a unique Process ID (PID) assigned by the kernel.

For example:

PID Process
1 init or systemd
247 sshd
831 nginx
1524 mysqld
2765 bash

The very first process created by the kernel is always assigned:

PID = 1

No exceptions.

This process becomes the ancestor of almost every other userspace process running on the system.

The Transition from Kernel Space to User Space

Until now, everything has been executed in kernel space.

This includes:

Applications do not run here.

Instead, once the kernel has finished its initialization, it starts the first userspace program.

The transition looks like this:

Kernel Space
      │
      ▼
Execute PID 1
      │
      ▼
User Space Begins

This is one of the most important transitions during the entire boot sequence.

How Does the Kernel Find PID 1?

The kernel looks for a userspace initialization program in a predefined order.

Traditionally, it searches for:

/sbin/init

If that does not exist, it may try:

/etc/init

or

/bin/init

or

/bin/sh

If none of these programs can be executed, the kernel has nowhere to transfer control.

The result is typically a panic similar to:

Kernel panic - not syncing:
No working init found.

This is one of the few kernel panic messages where the kernel itself is functioning correctly, but it cannot continue because the first userspace program is missing or unusable.

Engineering Insight

Many administrators immediately suspect a damaged kernel when they see a kernel panic.

However, in the case of "No working init found", the kernel has already completed most of its initialization successfully.

The actual problem is that it cannot execute the first userspace process.

Replacing the kernel would not solve the issue if /sbin/init is missing or the root filesystem is corrupted.

The Evolution of Linux Initialization Systems

The role of PID 1 has remained the same throughout Linux history, but the software implementing it has evolved significantly.

SysV init

For many years, Linux systems used System V init.

This implementation was simple and relied on shell scripts.

The boot process followed a sequence similar to:

Kernel
    │
    ▼
/sbin/init
    │
    ▼
Runlevel Scripts
    │
    ▼
System Services

Service startup was largely sequential, meaning each service waited for the previous one to complete.

Upstart

As Linux systems became more dynamic, Upstart introduced an event-driven model.

Instead of relying solely on predefined runlevels, services could start in response to events such as:

Although innovative, Upstart was eventually replaced by systemd in most major distributions.

systemd

Today, the majority of Linux distributions use systemd as PID 1.

Unlike earlier initialization systems, systemd introduces:

A simplified flow looks like this:

Kernel
    │
    ▼
systemd (PID 1)
    │
    ├────────────┬─────────────┬─────────────┐
    ▼            ▼             ▼
Networking    Logging      Device Manager
    │            │             │
    └────────────┴─────────────┘
                 │
                 ▼
         Remaining Services

This architecture enables modern Linux systems to boot faster and manage services more efficiently than traditional SysV init.

Runlevels vs Targets

Older Linux distributions, including RHEL 5, organize the boot process using runlevels.

Common runlevels include:

Runlevel Purpose
0 Halt
1 Single-user mode
3 Multi-user (text mode)
5 Multi-user with graphical interface
6 Reboot

Modern distributions using systemd replace runlevels with targets.

For example:

SysV Runlevel systemd Target
1 rescue.target
3 multi-user.target
5 graphical.target

Although the terminology differs, the underlying goal is the same: define the desired operating state of the system.

The Importance of PID 1

PID 1 has several unique responsibilities that no other process performs.

These include:

Because of these responsibilities, PID 1 is special.

If a normal process crashes, only that application is affected.

If PID 1 exits unexpectedly, the operating system can no longer manage its processes correctly.

Historically, this often resulted in a kernel panic or an unusable system.

Engineering Insight

PID 1 is more than "the first process."

It acts as the orchestrator of the entire userspace environment.

Every service you rely on—networking, SSH, databases, logging, web servers—ultimately exists because PID 1 started or supervised it.

Understanding this role helps explain why issues affecting init or systemd can have system-wide consequences.

Common PID 1 Failures

Although failures at this stage are less common than storage-related issues, they can still occur.

Symptom Likely Cause
No working init found Missing or corrupted /sbin/init
Immediate reboot after mounting root PID 1 crashed
Rescue shell instead of normal boot Essential services failed or rescue target entered
system hangs after switching root Initialization process could not continue

When troubleshooting, it is important to distinguish between:

The second scenario belongs to the next stage of the boot process.

Verifying PID 1

On a running system, confirming the identity of PID 1 is straightforward.

ps -p 1

Example output:

PID TTY          TIME CMD
1 ?        00:00:05 systemd

or on legacy systems:

PID TTY          TIME CMD
1 ?        00:00:01 init

You can also inspect the executable directly:

ls -l /proc/1/exe

Summary

The execution of PID 1 marks the beginning of userspace.

Until this point, Linux has been concerned primarily with preparing hardware and mounting the operating system.

Now the focus shifts to bringing the operating system to life.

Whether implemented as SysV init, Upstart, or systemd, PID 1 serves as the parent of nearly every userspace process and coordinates the initialization of the entire system.

Without it, Linux cannot progress beyond a mounted root filesystem into a fully operational environment.

IEN-008 - Stage 7 — System Service Initialization

At the end of the previous stage, the Linux kernel has successfully transferred control to PID 1.

Whether PID 1 is implemented as SysV init, Upstart, or systemd, the operating system has now entered the userspace initialization phase.

For the first time since the power button was pressed, Linux is no longer focused on preparing itself to boot.

Instead, it begins preparing itself to serve users and applications.

This stage is responsible for transforming a mounted filesystem into a fully operational operating system.

What Is a System Service?

A Linux system consists of much more than the kernel.

Even after the kernel has initialized hardware and mounted the root filesystem, the system still lacks many essential capabilities.

For example:

These capabilities are provided by system services, also known as daemons.

A daemon is simply a process that runs in the background and performs a specific function.

Examples include:

Service Purpose
sshd Remote SSH access
NetworkManager Network configuration
systemd-journald System logging
chronyd Time synchronization
crond Scheduled task execution
firewalld Firewall management
dbus Inter-process communication

Without these services, Linux would boot successfully but remain largely unusable in a production environment.

From PID 1 to Running Services

The initialization sequence now looks like this:

Kernel
    │
    ▼
PID 1 (systemd/init)
    │
    ▼
Load Unit Files / Init Scripts
    │
    ▼
Resolve Dependencies
    │
    ▼
Start Core Services
    │
    ▼
Start Optional Services
    │
    ▼
Reach Target State

Each step builds upon the previous one.

Unlike the firmware and kernel stages, this phase is highly configurable.

Administrators can decide:

Service Dependencies

Modern Linux systems rarely start services in a fixed order.

Instead, they rely on dependencies.

Consider an SSH server.

It cannot accept remote connections until:

The dependency graph looks something like this:

Hardware Ready
      │
      ▼
udev
      │
      ▼
Network Stack
      │
      ▼
IP Configuration
      │
      ▼
Firewall
      │
      ▼
SSH Server

If one dependency fails, downstream services may also fail or wait indefinitely.

Engineering Insight

A common misunderstanding is that Linux starts services one by one in a hard-coded sequence.

Modern systems using systemd actually construct a dependency graph and start many services in parallel whenever possible.

This approach significantly reduces boot time while ensuring that dependent services do not start before their prerequisites are satisfied.

systemd Units

Unlike SysV init, which relied primarily on shell scripts, systemd manages resources using unit files.

Common unit types include:

Unit Type Purpose
.service Background service
.socket Socket activation
.target Logical boot target
.mount Filesystem mount
.automount Automatic filesystem mounting
.timer Scheduled task
.device Hardware device
.path File or directory monitoring

This modular design allows systemd to manage far more than just services.

For example, mounting a filesystem or waiting for a hardware device can be handled through dedicated unit types rather than custom scripts.

Reaching the Target State

One of systemd's primary goals is to bring the system to a predefined target.

Common targets include:

Target Purpose
rescue.target Single-user recovery mode
multi-user.target Multi-user text environment
graphical.target Graphical desktop environment
emergency.target Minimal emergency shell

Most production servers aim to reach:

multi-user.target

while desktop systems typically boot into:

graphical.target

Once the target is reached, Linux is considered operational.

Parallel Startup

One of the most significant innovations introduced by systemd is parallel service startup.

Older SysV init systems generally followed a linear process:

Service A
    │
    ▼
Service B
    │
    ▼
Service C

If one service took ten seconds to start, every subsequent service had to wait.

Systemd instead starts independent services simultaneously:

               systemd
          ┌──────┼──────┐
          ▼      ▼      ▼
      Logging  Network  Cron
          │      │
          ▼      ▼
       SSH      NTP

As long as dependency requirements are met, multiple services can initialize concurrently, reducing overall boot time.

Service Failures During Boot

Not every service failure prevents Linux from booting.

For example, if a monitoring agent fails to start, the operating system can usually continue running.

However, failures involving critical services may leave the system in a degraded state.

Examples include:

Systemd records these failures and provides detailed diagnostic information for later analysis.

Investigating Boot Problems

One of systemd's greatest strengths is its diagnostic capabilities.

Several commands are particularly useful when troubleshooting service initialization issues.

systemctl --failed

Lists services that failed during startup.

systemctl status <service>

Displays the status, recent log entries, and dependency information for a specific service.

journalctl -b

Shows all log messages generated since the current boot.

journalctl -u sshd

Displays logs related to the SSH service.

systemd-analyze

Reports the total boot time.

Example:

Startup finished in 2.432s (kernel)
               + 8.917s (userspace)
               = 11.349s

For deeper analysis:

systemd-analyze blame

lists services sorted by startup duration, helping identify bottlenecks.

Engineering Insight

When a Linux system appears to "boot slowly," the kernel is often blamed.

In reality, the kernel typically completes its work within a few seconds. Delays are more commonly caused by userspace services waiting for storage devices, network configuration, DNS resolution, or external resources.

Tools such as systemd-analyze blame and journalctl -b are often far more useful than focusing solely on kernel messages.

Common Service Initialization Failures

The table below summarizes several common issues encountered during this stage.

Symptom Possible Cause
Network unavailable Network service failed
SSH connection refused sshd did not start
Boot stops waiting for a mount Filesystem dependency failed
System enters emergency mode Critical mount or service failure
Long boot time Slow or blocked service startup

Unlike earlier stages, these failures occur after the operating system has already mounted the root filesystem and started PID 1.

This distinction helps narrow the investigation to userspace rather than firmware, bootloader, or kernel components.

Summary

The service initialization stage transforms Linux from a mounted operating system into a fully functional platform capable of supporting users and applications.

PID 1 launches essential services, resolves dependencies, manages failures, and brings the system to its configured operational target.

While earlier boot stages focus on hardware and storage, this stage focuses on functionality—networking, logging, scheduling, security, and every background process required for normal operation.

By the time the target state is reached, Linux is ready to present a login interface and begin accepting user sessions.

IEN-009 - Stage 8 — User Login: Entering User Space

At this point, the Linux system has completed nearly all of its startup sequence.

The firmware initialized the hardware.

The bootloader loaded the Linux kernel.

The kernel initialized the operating system.

The initrd environment prepared storage.

The root filesystem was mounted.

PID 1 started.

System services were initialized.

Now Linux performs its final task before becoming fully operational:

Provide a way for users and applications to interact with the system.

Depending on the system configuration, this interaction may occur through:

Regardless of the access method, they all originate from the same initialization process that began with PID 1.

From Services to User Sessions

The simplified boot sequence now looks like this:

Firmware
      │
      ▼
Bootloader
      │
      ▼
Kernel
      │
      ▼
initrd
      │
      ▼
Root Filesystem
      │
      ▼
PID 1
      │
      ▼
System Services
      │
      ▼
Login Manager
      │
      ▼
User Authentication
      │
      ▼
Shell / Desktop

Notice that the operating system itself is already running before any user logs in.

Logging in does not start Linux.

It merely creates a new user session on an already running operating system.

Text-Based Login

Most Linux servers operate without a graphical interface.

Instead, they provide one or more virtual terminals (TTYs).

Each virtual terminal is managed by a program called getty.

Its responsibilities include:

The familiar prompt:

server login:

is typically provided by a getty process.

Once a valid username and password are entered, the authentication subsystem verifies the credentials.

If authentication succeeds, the user's default shell is started.

For example:

/bin/bash

or

/bin/zsh

From this point onward, the user is interacting directly with the operating system.

Graphical Login

Desktop Linux systems follow a similar process but use a Display Manager instead of a text console.

Common display managers include:

Display Manager Desktop Environment
GDM GNOME
SDDM KDE Plasma
LightDM XFCE, MATE, Cinnamon
LXDM LXDE

Instead of displaying:

login:

the display manager presents a graphical login screen.

After successful authentication, it starts:

Although the interface looks very different, the underlying boot sequence remains the same.

Remote Login (SSH)

In enterprise environments, users rarely log in through the physical console.

Instead, they connect remotely using SSH.

The sequence is:

Client
     │
     ▼
Network
     │
     ▼
sshd
     │
     ▼
Authentication
     │
     ▼
Shell

Notice something important.

SSH is not part of the boot process itself.

It depends on:

all of which must already be operational.

If the SSH daemon fails to start, Linux may have booted successfully even though remote administrators cannot access it.

Engineering Insight

One of the most common production incidents is:

"The server is down because SSH doesn't work."

In reality, the operating system may be fully operational.

The actual problem could be:

Always distinguish between:

"Linux failed to boot."

and

"Linux booted successfully, but one service failed."

These are fundamentally different classes of problems.

User Session Initialization

After authentication succeeds, Linux prepares the user's environment.

Typical initialization steps include:

For Bash users, configuration files often include:

/etc/profile
~/.bash_profile
~/.bash_login
~/.profile
~/.bashrc

These files customize the user's working environment before the shell prompt appears.

The Linux Boot Process Is Complete

Once the user receives a shell prompt or graphical desktop, the boot process is considered complete.

For a server, this often looks like:

login:

or after authentication:

[root@server ~]#

For desktop systems, it is the appearance of the desktop environment.

At this stage:

The operating system is now fully functional.

Complete Linux Boot Timeline

Now that we have explored each stage individually, let's review the entire process from beginning to end.

Power Button
      │
      ▼
Power Supply Initialization
      │
      ▼
CPU Reset
      │
      ▼
Firmware (BIOS / UEFI)
      │
      ▼
POST (Power-On Self-Test)
      │
      ▼
Boot Device Selection
      │
      ▼
Bootloader (GRUB)
      │
      ▼
Load Linux Kernel
      │
      ▼
Load initrd / initramfs
      │
      ▼
Kernel Initialization
      │
      ▼
Hardware Discovery
      │
      ▼
Load Drivers
      │
      ▼
Activate Storage (LVM / RAID / Multipath)
      │
      ▼
Mount Root Filesystem
      │
      ▼
switch_root
      │
      ▼
Execute PID 1
      │
      ▼
Initialize System Services
      │
      ▼
Login Manager
      │
      ▼
User Login
      │
      ▼
Shell / Desktop

One of the most important lessons from this timeline is that every stage depends on the successful completion of the previous one.

A failure early in the sequence prevents all later stages from occurring.

Boot Troubleshooting Matrix

The table below summarizes the most common failures according to the stage in which they occur.

Stage Component Typical Error Primary Investigation
Firmware BIOS / UEFI No Boot Device Firmware settings, disk detection
Bootloader GRUB grub rescue> GRUB configuration, MBR, EFI
Kernel Linux Kernel Kernel Panic Kernel image, parameters, drivers
Early Userspace initrd / initramfs Unable to mount root filesystem Storage drivers, LVM, RAID, Multipath
Root Filesystem VFS Cannot mount root Filesystem, UUID, root parameter
Userspace Initialization PID 1 No working init found /sbin/init, systemd
Service Initialization systemd Failed services journalctl, systemctl
Login Getty / SSH Login unavailable Authentication, SSH, networking

This matrix provides a practical way to map symptoms to the most likely stage of failure.

Key Takeaways

Understanding the Linux boot process is not about memorizing commands.

It is about understanding the sequence of events that transforms powered hardware into a fully operational operating system.

Every boot stage has a clear responsibility:

When viewed individually, these components may seem unrelated.

When viewed together, they form a single, continuous chain.

Every boot problem—whether it is a missing bootloader, an incorrect kernel parameter, a failed LVM activation, or an unavailable login prompt—is simply a failure occurring somewhere along that chain.

Once you understand where the sequence stopped, you have already solved half of the troubleshooting process.

Conclusion

Linux boot is often perceived as a mysterious sequence hidden behind a few lines of console output. In reality, it is a well-defined pipeline where each component has a specific responsibility and a clearly defined handoff to the next stage.

For infrastructure engineers, mastering this pipeline is invaluable. It enables faster troubleshooting, more confident disaster recovery, and a deeper understanding of how Linux systems behave under both normal and failure conditions.

The concepts introduced in this article serve as the foundation for the remainder of the Infrastructure Engineering Notes series. Future articles will revisit individual stages in greater depth, using real-world production incidents to illustrate how failures occur and how they can be resolved systematically.