Ubuntu Server Boot Process Explained Step by Step

The boot process on Ubuntu Server (24.04 LTS Noble Numbat and later, as of 2026) follows a modern Linux sequence centered around UEFI firmware, GRUB2 bootloader, Linux kernel, initramfs, and systemd as PID 1. Unlike the desktop edition, Ubuntu Server omits graphical splash screens (Plymouth) and desktop session targets by default — it targets a clean, text-based multi-user environment optimized for headless operation.

This explanation focuses on a typical bare-metal or virtualized Ubuntu Server installation using GRUB (default) and systemd as the init system.

1. Firmware Initialization (UEFI / BIOS)

• Power is applied → Power-On Self-Test (POST) executes.
• Modern servers use UEFI firmware (legacy BIOS is rare and unsupported in new installs).
• UEFI reads the EFI System Partition (ESP) (FAT32, usually /boot/efi or mounted at /efi).
• It locates the EFI boot loader executable (GRUB’s EFI binary: grubx64.efi) from the ESP’s \EFI\ubuntu\ path.
• UEFI hands control to the bootloader.

Key point: Secure Boot (if enabled) verifies signatures on the bootloader, kernel, and initramfs using certificates from Microsoft (for shim) and Canonical.

2. Bootloader Stage — GRUB2

• GRUB2 loads its configuration from /boot/grub/grub.cfg (generated by update-grub).
• Displays a menu (hidden by default on servers via GRUB_TIMEOUT_STYLE=hidden and short timeout).
• User can press Shift/Esc during boot to force the menu for kernel selection or editing.
• GRUB loads the selected kernel (vmlinuz-) and corresponding initramfs (initrd.img-) into memory.
• Passes kernel command-line parameters (from grub.cfg or edited on-the-fly), including:
  • root=UUID=… or root=/dev/…
  • ro (initial read-only mount)
  • quiet splash (splash is ignored on server)
  • Hardware-specific options (e.g., nomodeset, intel_iommu=on)

GRUB then executes the kernel with the initramfs as the initial root filesystem.

3. Kernel Initialization

• Kernel decompresses itself and starts executing.
• Early boot: initializes CPU, memory management, interrupt controllers.
• Detects and initializes core hardware via built-in drivers.
• Mounts the initramfs (compressed cpio archive in RAM) as temporary root (/).
• Kernel executes /init (usually a symlink to /sbin/init or systemd) from the initramfs — this is still not PID 1 on the final system.

4. Initramfs Phase (Early User-Space)

The initramfs contains minimal tools and scripts (busybox, udev, systemd in recent Ubuntu) needed to reach the real root filesystem.

Typical actions in Ubuntu Server initramfs:

• Loads additional modules (for LVM, RAID, dm-crypt, NFS root, etc.) based on /etc/initramfs-tools/modules and hardware detection.
• If root is encrypted (LUKS): prompts for passphrase or uses keyfile/dropbear for remote unlock.
• If LVM: activates volume groups (vgchange -ay).
• Mounts the real root filesystem to /root or /sysroot.
• Switches root: switch_root or systemd’s equivalent moves to the real root filesystem.
• Executes /sbin/init (systemd) from the real root — this becomes PID 1.

On failure (e.g., wrong UUID, missing disk): drops to initramfs emergency shell (busybox).

5. Systemd Initialization (PID 1 — True Init)

Systemd is now running as PID 1 on the real root filesystem.

It follows dependency-based activation rather than sequential runlevels:

• Mounts essential API filesystems: /sys, /proc, /dev, /run.
• Parses kernel command line and unit dependencies.
• Reaches initrd.target (if coming from initramfs) → then switches to full system boot.
• Activates basic.target (core system setup: udev, logging, tmpfiles, modules loading).
• Proceeds toward multi-user.target (default non-graphical goal for servers).

Key early targets/units:

• sysinit.target — swap, fsck, local filesystems, clock, random seed.
• basic.target — sockets, timers, paths, most static mounts.
• network.target — network-online.target waits for configured connectivity.
• multi-user.target — final server state: all enabled services running, login prompt ready.

Systemd starts services in parallel based on After=, Requires=, Wants= directives.

6. Final Boot Targets & User Environment

• multi-user.target reached → server is operational.
• Getty instances start on TTY1–TTY6 (text login prompts).
• On cloud images: cloud-init runs (network config, user-data scripts, SSH keys).
• System is ready for SSH connections or console login.

No getty on graphical.target (reserved for desktops).

Diagnostic Tools for Boot Issues

• systemd-analyze time — overall boot duration.
• systemd-analyze blame — slowest units.
• systemd-analyze critical-chain — dependency path to multi-user.target.
• journalctl -b -1 — previous boot logs.
• journalctl -b -u initramfs-* — initramfs phase.
• Boot with systemd.log_level=debug or rd.systemd.show_status=true for verbose output.

Summary Flow (Ubuntu Server 24.04+)

1. UEFI → hardware init → loads grubx64.efi
2. GRUB2 → menu → loads kernel + initramfs
3. Kernel → early init → mounts initramfs → runs /init
4. Initramfs → activates root device (LUKS/LVM) → switch_root → starts real systemd
5. systemd (PID 1) → mounts filesystems → activates basic.target → multi-user.target
6. Login prompt (TTY) or SSH ready

This parallel, declarative model makes modern Ubuntu Server boots faster and more robust than legacy SysV sequences, while providing excellent dependency handling and logging via journald.

If you’re troubleshooting a specific boot hang, slow phase, encrypted root, cloud instance, or custom kernel, share symptoms or logs (e.g., systemd-analyze blame output) for more targeted advice.