Understanding the Linux Boot Process: UEFI, GRUB, Kernel, initramfs, and systemd Explained

Introduction

From the moment a Linux server’s power button is pressed until the login screen appears, many components work together in coordination.

Although this process is usually invisible in daily operations, understanding the boot mechanism is extremely useful when investigating server startup failures or performance issues. It is also an important foundation for deeper knowledge of the Linux kernel and system administration.

In this article, we will trace the roles of components such as UEFI, GRUB, the Linux kernel, initramfs, and systemd, and explain in detail how Linux boots.

Overview of the Linux Boot Sequence

Linux booting proceeds in the following flow. First, try to understand the overall picture.

Detailed Linux Boot Sequence

Now let’s go into detail about what each component does during the boot process.

Power On

When the server is powered on, the power circuitry supplies electricity to all components. The CPU then exits reset state and begins executing instructions, starting with firmware code such as BIOS/UEFI.

BIOS / UEFI

When the server is powered on, the first component that runs is neither the Linux kernel nor the bootloader. Instead, the UEFI (Unified Extensible Firmware Interface) stored in flash memory on the motherboard is executed first.

The role of UEFI is to prepare the system to boot an operating system and eventually hand over control to a bootloader.

Hardware Initialization

First, UEFI initializes hardware components such as the CPU, storage controllers, and PCI devices. Immediately after power-on, hardware is not yet in a usable state, so UEFI configures each device to create a functional system environment.

RAM Initialization

UEFI initializes system RAM so it can be used. Bootloaders and the Linux kernel are not executed directly from disk; they are first loaded into RAM. Therefore, RAM initialization is a critical step in the boot sequence.

POST (Power-On Self Test)

Next, UEFI performs a self-diagnostic process called POST (Power-On Self Test). POST checks whether major components such as the CPU, memory, and storage are properly recognized. For example, beep sounds during memory failure are triggered when an error is detected at this stage.

Boot Device Detection

UEFI then searches for bootable devices according to the configured boot order. It scans devices such as NVMe SSDs, SATA SSDs, USB drives, and PXE boot targets to find a bootable medium.

Loading the Bootloader into Memory

Once a boot device is found, UEFI loads the bootloader stored in the EFI System Partition (ESP) into memory (RAM).

In Linux environments, GRUB2 is commonly used. UEFI loads the GRUB2 executable from disk into RAM.

At this point, UEFI completes its role and transfers control to GRUB2. GRUB2 then loads the Linux kernel and initramfs into memory, and the Linux boot process begins.

Bootloader (GRUB2)

GRUB2 (GRand Unified Bootloader Version 2) is commonly used in Linux environments. It acts as a bridge to start the Linux kernel.

Its main responsibilities are:

• Selecting the kernel to boot
• Configuring kernel parameters
• Loading initramfs
• Selecting the OS in multi-boot environments

GRUB configuration is mainly stored in grub.cfg. When a new kernel is installed via updates, the GRUB menu is updated accordingly.

Let’s look at an example configuration. In my environment, the settings are generated from /etc/default/grub.

[root@localhost ~]# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[root@localhost ~]#

The most important parameter is GRUB_CMDLINE_LINUX, which defines kernel parameters passed at boot time.

The Linux kernel requires various settings at startup, such as which device to use as the root filesystem, how much memory to reserve for kdump, and which features to enable.

For example, parameters such as rd.lvm.lv=almalinux/root and rd.lvm.lv=almalinux/swap specify that the system uses LVM volumes root and swap in the almalinux volume group.

You can temporarily modify kernel parameters by pressing the e key in the GRUB menu. This is frequently used during troubleshooting.

Linux Kernel

Once GRUB loads the Linux kernel into memory, the initialization of the operating system begins.

Here, “initialization” means preparing each subsystem so it can be used. For example, memory management prepares available memory regions, process management initializes internal data structures, and device management prepares hardware interfaces.

The Linux kernel manages hardware resources such as CPU, memory, and devices.

It initializes core subsystems such as CPU management, memory management, process management, interrupt handling, scheduler, and device management.

It also detects PCI devices such as SCSI disks, SATA disks, NVMe SSDs, network interfaces, and USB devices.

initramfs

After kernel initialization, initramfs is executed.

initramfs (Initial RAM Filesystem) is a temporary root filesystem loaded into memory.

At this stage, the kernel cannot yet access the real root filesystem, so initramfs prepares everything needed to access it.

It performs tasks such as loading storage drivers, detecting RAID configurations, initializing Device Mapper, detecting LVM, detecting Multipath storage, and searching for the root filesystem.

In enterprise environments, LVM and Multipath are commonly used. If initramfs is broken, a Kernel Panic may occur and the system will fail to boot.

Root Filesystem

Once the storage configuration is recognized, the actual root filesystem is mounted.

Control is transferred from initramfs to the real root filesystem using a mechanism called switch_root.

This marks the end of the temporary initramfs environment and the transition to the real Linux system.

systemd Startup

After the root filesystem is ready, the first user-space process starts.

Modern Linux distributions use systemd, which runs as PID 1. PID 1 is the parent process of the entire system.

systemd is responsible for service management, dependency management, logging, mount management, and system state management.

Almost all services after boot are managed by systemd.

In practice, the term “init” is often used. init refers to the general concept of the first PID 1 process, while systemd is one implementation of an init system.

Starting Services

systemd starts services according to predefined targets, similar to runlevels.

Common targets include rescue.target (single-user mode), multi-user.target (text-based environment), and graphical.target (GUI environment).

Services are started in parallel based on dependencies, including NetworkManager, sshd, chronyd, firewalld, monitoring agents, databases, and web servers.

At this point, SSH is available and users can log in remotely.

Checking Boot Logs for the Linux Startup Process

Let’s examine the actual boot process by reviewing logs from an AlmaLinux 9 system running on VirtualBox.

UEFI and GRUB Boot Process

UEFI and GRUB run before the Linux kernel, so they are not recorded in standard tools such as dmesg or journalctl. Therefore, the first logs available in Linux begin at the kernel boot stage.

However, you can still confirm traces of UEFI and GRUB activity by checking /proc/cmdline and efibootmgr -v.

The /proc/cmdline file shows the kernel parameters passed at boot time. Let’s check its contents using the cat command.

[root@localhost ~]# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[root@localhost ~]#

From the BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 entry, we can confirm which Linux kernel was loaded by GRUB.

Next, let’s run the efibootmgr -v command. This displays UEFI boot entries registered in the system, along with the EFI programs they reference.

[root@localhost ~]# efibootmgr -v
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376         PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI VBOX HARDDISK VBa8a86760-33611b8a        PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003  EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* AlmaLinux     HD(1,GPT,6e652488-b850-40f2-901e-9f78c15f4de4,0x800,0x12c000)/File(\EFI\almalinux\shimx64.efi)
[root@localhost ~]#

In this environment, the following boot entries are configured:

BootCurrent: 0004
BootOrder: 0004,0000,0001,0002,0003

Boot0004* AlmaLinux
HD(1,GPT,…)/File(\EFI\almalinux\shimx64.efi)

From this information, we can see that the system is currently booting using Boot0004.

The BootOrder defines the priority list used by UEFI during startup, with Boot0004 being attempted first.

Boot0004 points to the following EFI program stored in the EFI System Partition (ESP) on a GPT disk:

\EFI\almalinux\shimx64.efi

This shimx64.efi is a bootloader that supports Secure Boot and subsequently launches GRUB.

Linux Kernel Boot Process

Now let’s look at the Linux kernel boot process.

To inspect boot logs, we use the following command:

journalctl -b -o short-monotonic

The -b option shows logs from the current boot only, and -o short-monotonic displays timestamps relative to system startup. This allows us to trace when each stage occurred, including kernel initialization, device detection, and systemd service startup.

Let’s go through the key logs in order.

Handover from UEFI → GRUB → Linux Kernel

[root@localhost ~]# journalctl -b -o short-monotonic
[    0.000000] localhost kernel: Linux version 5.14.0-570.12.1.el9_6.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREE>

This is the first log entry, indicating that control has been passed from UEFI → GRUB → the Linux kernel, and the kernel has started execution.

[    0.000000] localhost kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper>

This shows the kernel parameters passed by GRUB. The same information is also available in /proc/cmdline.

Memory Initialization

[    0.000000] localhost kernel: BIOS-provided physical RAM map:
[    0.000000] localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000007e1b6fff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007e1b7000-0x000000007e1fffff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007e200000-0x000000007eceefff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ecef000-0x000000007ef6efff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ef6f000-0x000000007ef7efff] ACPI data
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ef7f000-0x000000007effefff] ACPI NVS
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007efff000-0x000000007f36afff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007f36b000-0x000000007ffeffff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved

This is the memory map provided by UEFI/BIOS.
The Linux kernel uses this information to identify usable RAM and reserved regions, and initializes its memory management subsystem.

UEFI Initialization Confirmation

[    0.000000] localhost kernel: efi: EFI v2.7 by EDK II
[    0.000000] localhost kernel: efi: ACPI=0x7ef7e000 ACPI 2.0=0x7ef7e014 SMBIOS=0x7effd000 MOKvar=0x7ecfa000
[    0.000000] localhost kernel: efi: Remove mem115: MMIO range=[0xffc00000-0xffffffff] (4MB) from e820 map

This confirms that the system is booting in a UEFI environment.

Device Detection

[    2.562044] localhost kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[    2.562758] localhost kernel: device-mapper: uevent: version 1.0.3
[    2.563275] localhost kernel: device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev

Device Mapper is being initialized.

[    2.604511] localhost systemd[1]: Starting Rule-based Manager for Device Events and Files...
[    2.621782] localhost systemd-udevd[341]: Using default interface naming scheme 'rhel-9.0'.
[    2.630242] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.
[    2.630318] localhost systemd[1]: dracut pre-trigger hook was skipped because no trigger condition checks were met.

The udev service is starting, indicating active device management.

[    2.630334] localhost systemd[1]: Starting Coldplug All udev Devices...
[    2.754276] localhost systemd[1]: Finished Coldplug All udev Devices.
[    2.754339] localhost systemd[1]: nm-initrd.service was skipped because of an unmet condition check (ConditionPathExists=/run/NetworkManager/initrd/neednet).
[    2.754357] localhost systemd[1]: Reached target Network.
[    2.754372] localhost systemd[1]: nm-wait-online-initrd.service was skipped because of an unmet condition check (ConditionPathExists=/run/NetworkManager/initrd/neednet).
[    2.777130] localhost systemd[1]: Starting dracut initqueue hook...

This indicates that dracut (inside initramfs) has started searching for the root filesystem. It waits for storage devices such as LVM to become available. Once the root filesystem is found, control is transferred via switch_root.

Virtual Disk Detection

[    3.282970] localhost kernel: libata version 3.00 loaded.
[    3.285354] localhost kernel: ata_piix 0000:00:01.1: version 2.13
[    3.311944] localhost kernel: ahci 0000:00:0d.0: version 3.0

Storage drivers are being loaded.

[    3.538289] localhost kernel: ata2.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
[    3.542586] localhost kernel: scsi 1:0:0:0: CD-ROM            VBOX     CD-ROM           1.0  PQ: 0 ANSI: 5

VirtualBox’s virtual CD-ROM drive is being detected. If an installation media or ISO image is attached, it will appear here.

    3.721747] localhost kernel: ata3.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133

The virtual hard disk is detected by the kernel.

[    3.859265] localhost kernel: sd 2:0:0:0: [sda] 41943040 512-byte logical blocks: (21.5 GB/20.0 GiB)
[    3.859701] localhost kernel: sd 2:0:0:0: [sda] Write Protect is off
[    3.860028] localhost kernel: sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    3.860039] localhost kernel: sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.860353] localhost kernel: sd 2:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    3.922419] localhost kernel:  sda: sda1 sda2 sda3
[    3.923033] localhost kernel: sd 2:0:0:0: [sda] Attached SCSI disk

This indicates that the Linux kernel has recognized the hard disk as /dev/sda. It also shows that the partitions /dev/sda1, /dev/sda2, and /dev/sda3 have been detected.

Root Filesystem Mounting

[    5.280958] localhost dracut-initqueue[438]: Scanning devices sda3  for LVM logical volumes almalinux/root
[    5.281254] localhost dracut-initqueue[438]: almalinux/swap
[    5.314490] localhost dracut-initqueue[438]:   almalinux/root linear
[    5.314573] localhost dracut-initqueue[438]:   almalinux/swap linear
[    5.376705] localhost systemd[1]: Found device /dev/mapper/aStarting Switch Rootlmalinux-root.
[    5.378792] localhost systemd[1]: Reached target Initrd Root Device.
[    5.453402] localhost systemd[1]: Found device /dev/mapper/almalinux-swap.
[    5.470491] localhost systemd[1]: Starting Resume from hibernation using device /dev/mapper/almalinux-swap...
~~Truncated~~
[    5.505293] localhost systemd[1]: Finished dracut initqueue hook.

In this log, dracut running inside initramfs detects LVM and finds the root filesystem at /dev/mapper/almalinux-root. Since the system cannot continue booting until the root filesystem is found, this is a critical stage in the boot sequence. It also detects the swap area and checks whether a resume from hibernation is required.

[    5.511307] localhost systemd[1]: Starting File System Check on /dev/mapper/almalinux-root...
[    5.555762] localhost systemd-fsck[484]: /usr/sbin/fsck.xfs: XFS file system.
[    5.559914] localhost systemd[1]: Finished File System Check on /dev/mapper/almalinux-root.

This indicates that the integrity of the root filesystem is being checked.

[    5.562343] localhost systemd[1]: Mounting /sysroot...
[    6.003953] localhost kernel: SGI XFS with ACLs, security attributes, scrub, quota, no debug enabled
[    6.016107] localhost kernel: XFS (dm-0): Mounting V5 Filesystem b3755490-b910-4bcd-8e47-a0037f2f09ab
[    6.074677] localhost kernel: XFS (dm-0): Ending clean mount
[    6.088476] localhost systemd[1]: Mounted /sysroot.

This shows the process where initramfs mounts the root filesystem. In this environment, the XFS filesystem stored on the LVM logical volume /dev/mapper/almalinux-root is mounted to /sysroot.

switch_root (Transition to the Real OS)

[    6.377428] localhost systemd[1]: Starting Switch Root...
[    6.401897] localhost systemd[1]: Switching root.

This process indicates the transition from initramfs to the actual root filesystem. Immediately after boot, Linux runs on a minimal environment provided by initramfs, which is expanded in memory. Once the root filesystem has been identified and mounted, control is transferred to the real root filesystem containing the operating system via switch_root. At this point, Linux moves into the full OS startup phase.

systemd starup

[    6.857481] localhost systemd[1]: systemd 252-51.el9.alma.1 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)

This log indicates that the switch to the root filesystem (switch_root) has completed, and the production instance of systemd has started as PID 1. systemd is the initial process (init) in Linux and is responsible for managing system services after boot. When this log appears, it indicates that Linux has finished the initialization phase performed by the kernel and initramfs and has transitioned into the full operating system startup phase.

[    8.053196] localhost systemd[1]: Starting Remount Root and Kernel File Systems
[    8.403525] localhost systemd[1]: Finished Remount Root and Kernel File Systems.

The root filesystem is being remounted.

[ 9.000367] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.

Starting management services.

[ 9.000367] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.

Device management services are started.

[ 13.401255] localhost systemd[1]: Starting Network Manager...

NetworkManager starts.

SSH Service Startup

[ 15.186258] localhost.localdomain systemd[1]: Starting OpenSSH server daemon...

The SSH service starts, enabling remote login.

Completion of Multi-User Mode (Boot Complete)

[ 17.002933] localhost.localdomain systemd[1]: Reached target Multi-User System.

This indicates that the system has reached multi-user mode (multi-user.target).

At this stage, core services such as networking and SSH are fully operational, and the system is ready for normal use.

In non-GUI server environments, this message typically indicates that the Linux boot process has completed.

Boot Troubleshooting Cases

Understanding the Linux boot sequence makes it much easier to isolate issues when a boot failure occurs. As described earlier, the boot process follows this flow:
“UEFI → GRUB2 → Linux kernel → initramfs → root filesystem → systemd”.
Therefore, it is important to identify at which stage the boot process is stopping.

GRUB2 does not start

If the GRUB menu does not appear after powering on the system, it may indicate corruption of the EFI System Partition (ESP) or loss of GRUB-related files.

For example, if files in the EFI partition are accidentally deleted or boot entries become corrupted, the operating system will no longer be able to boot. In such cases, you need to boot from installation media in rescue mode and reinstall GRUB2 or regenerate its configuration.

Linux kernel does not start

If the GRUB menu appears but the system stops after loading the kernel, the cause may be a corrupted kernel image or incorrect kernel parameters.

By pressing the “e” key in the GRUB menu, you can temporarily edit kernel parameters. During troubleshooting, removing “rhgb quiet” is often helpful to display boot logs and identify the root cause.

In environments with multiple installed kernels, it may also be possible to boot using an older kernel version.

Stuck at initramfs

This is a relatively common issue.

For example, if LVM or Multipath configurations are changed but initramfs is not regenerated, the system may fail to locate the root filesystem during boot and drop into a dracut shell (dracut is a tool used to generate initramfs in Linux).

Typical error messages include:

Warning: /dev/mapper/root does not exist
Warning: /dev/almalinux/root does not exist
Entering emergency mode

In this case, you should verify GRUB kernel parameters and LVM configuration, and regenerate initramfs using the dracut command if necessary.

Cannot mount the filesystem

This issue is often caused by storage failures or misconfiguration in /etc/fstab.

For example, if a non-existent UUID or device name is specified in /etc/fstab, the mount process may fail during boot and the system may enter Emergency Mode. This is a relatively common post-change issue, so it is important to carefully verify /etc/fstab after making system modifications.

systemd boot failure

This occurs when the system successfully reaches the point where the root filesystem is mounted, but problems occur during service startup.

Possible causes include:

• Misconfiguration of NetworkManager
• Failure to connect to NFS mount targets
• Failure of dependent services
• Incorrect placement of systemd unit files

In such cases, you should boot into rescue mode or check logs from Emergency Mode to investigate the issue.

Understanding the boot sequence helps isolate issues by stage: UEFI → GRUB → Kernel → initramfs → root filesystem → systemd.

For reference

BIOS vs UEFI

The biggest difference between BIOS and UEFI lies in how they boot the operating system and the disk configurations they support.

BIOS is a legacy method that boots the system using the Master Boot Record (MBR). It has limitations in terms of disk capacity and the number of partitions. In contrast, UEFI supports a newer partitioning scheme called the GUID Partition Table (GPT), which enables support for larger disks and provides enhanced security features and other improvements.

Today, almost all servers and PCs use UEFI, and UEFI-based environments are now the standard for Linux server deployments as well.

Summary

The Linux boot sequence may look complex at first glance, but it can be broadly summarized as the following flow:
“UEFI → GRUB → Linux kernel → initramfs → root filesystem → systemd”.

Immediately after power-on, UEFI initializes the hardware, and GRUB loads the Linux kernel and initramfs into memory. The Linux kernel then initializes the CPU, memory, and devices, and hands control over to initramfs. initramfs searches for and mounts the root filesystem, then switches to the actual operating system environment using switch_root. Finally, systemd starts and launches various services, bringing the system into a fully operational state.

In this article, we also examined actual boot logs to understand what happens at each phase. When a boot failure occurs, it is crucial to identify at which stage the process has stopped. For example, if GRUB does not appear, the issue is likely related to UEFI or the bootloader. If the root filesystem cannot be recognized, the problem may lie in initramfs or the storage configuration.

For Linux administrators and infrastructure engineers, understanding the boot sequence is a fundamental skill for troubleshooting. I hope this article helps you better understand the Linux boot process and improves your ability to isolate issues when failures occur.