Ubuntu Boot Process Explained

Ubuntu Boot Process Explained

Every time an Ubuntu server boots, it goes through a predictable sequence of stages: firmware, bootloader, kernel, init system, and finally your login prompt. Understanding this sequence is essential for diagnosing boot failures, customising GRUB, modifying kernel parameters, and understanding why systemd-analyze blame shows what it shows.

Why the boot process matters

Boot problems are among the most stressful server issues because the system is unreachable over SSH. If you understand what runs at each stage, you can identify exactly where the boot failed and recover the system using rescue mode or a live USB. Even on healthy systems, knowing the boot sequence helps you tune startup time and understand service dependencies.

Stage 1: Firmware (BIOS or UEFI)

When you power on a server, the CPU starts executing code from the firmware chip on the motherboard. This firmware is either:

• BIOS (Basic Input/Output System): older, 16-bit firmware; uses MBR partition table; limited to 2 TB boot disks
• UEFI (Unified Extensible Firmware Interface): modern replacement; uses GPT partition table; supports Secure Boot; supports disks over 2 TB

The firmware runs a Power-On Self-Test (POST) to check RAM and hardware, then locates a bootable device (disk, network, USB) and hands control to the bootloader.

On modern Ubuntu servers, UEFI is standard. The EFI System Partition (ESP) is a small FAT32 partition at the start of the disk where GRUB is installed.

# Check if the system booted in UEFI or BIOS mode
[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "BIOS/Legacy mode"

# List EFI boot entries
efibootmgr -v

# Show the EFI System Partition
lsblk -o NAME,FSTYPE,MOUNTPOINT | grep -A1 -i vfat

Stage 2: GRUB bootloader

GRUB (GRand Unified Bootloader) is the bootloader Ubuntu uses. Its job is to load the Linux kernel into memory and pass it configuration parameters. GRUB presents a menu (visible for 5 seconds during normal boot unless configured otherwise) that lets you choose which kernel to boot or enter recovery mode.

# Show GRUB version
grub-install --version

# Regenerate grub.cfg after editing /etc/default/grub
sudo update-grub

# Add a kernel parameter persistently (example: quiet splash)
sudo nano /etc/default/grub
# Edit: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
sudo update-grub

# See which kernels are available to boot
ls /boot/vmlinuz-*

Common edits to /etc/default/grub:

• GRUB_TIMEOUT=0 — skip the menu on servers (boot immediately)
• GRUB_CMDLINE_LINUX="net.ifnames=0" — use old-style interface names (eth0)
• GRUB_CMDLINE_LINUX="systemd.unit=rescue.target" — force boot into rescue mode

Stage 3: Linux kernel and initramfs

GRUB decompresses the kernel image (vmlinuz) into RAM and loads the initramfs (initial RAM filesystem) alongside it. The initramfs is a compressed archive that contains a minimal filesystem with just enough tools to mount the real root filesystem.

The kernel needs the initramfs because at startup it does not yet have drivers for the storage controller, LVM, RAID, or encryption layers that the real root filesystem might be on. The initramfs includes those drivers and scripts.

After the initramfs mounts the real root filesystem (/), control passes to systemd.

# List kernel messages from the current boot
dmesg | less

# See kernel messages with timestamps
dmesg -T | tail -30

# Show the initramfs contents for the current kernel
lsinitramfs /boot/initrd.img-$(uname -r) | head -30

# Show kernel command line that was used to boot
cat /proc/cmdline

Example output

BOOT_IMAGE=/boot/vmlinuz-6.8.0-57-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash

Stage 4: systemd init

After the root filesystem is mounted, the kernel starts /sbin/init, which on Ubuntu is a symlink to systemd. systemd becomes PID 1 and takes over the boot process. It reads unit files from /lib/systemd/system/ and /etc/systemd/system/ and starts services in dependency order.

The boot target on a server is typically multi-user.target (equivalent to the old runlevel 3). On Desktop, it is graphical.target.

# Show total boot time
systemd-analyze

# Show the slowest services at boot
systemd-analyze blame | head -15

# Show a graphical timeline (SVG)
systemd-analyze plot > /tmp/boot.svg

# Show the active boot target
systemctl get-default

# Change the default target (e.g., to boot into multi-user without GUI)
sudo systemctl set-default multi-user.target

Example output

Startup finished in 1.243s (kernel) + 5.412s (userspace) = 6.656s
graphical.target reached after 5.389s in userspace

Stage 5: Login prompt or display manager

Once systemd has started all required services, it starts a login interface. On Ubuntu Server this is a virtual terminal login prompt (managed by getty). On Ubuntu Desktop it is a display manager (GDM3 on GNOME).

# Check if a display manager is running
systemctl status gdm3 2>/dev/null || systemctl status lightdm 2>/dev/null

# Check getty (terminal login) services
systemctl status getty@tty1

# See all running services after boot
systemctl list-units --type=service --state=running

How to read the boot log

The most useful tool for understanding what happened during boot is journalctl.

# Show all messages from the current boot
journalctl -b

# Show messages from the previous boot
journalctl -b -1

# Show only errors and above from the current boot
journalctl -b -p err

# Show boot messages from a specific service
journalctl -b -u ssh

# Show the last 50 boot messages in real time
journalctl -b -f -n 50

Common boot problems

Conclusion

The Ubuntu boot sequence is: firmware → GRUB → kernel + initramfs → systemd → login prompt. Understanding each stage lets you pinpoint boot failures quickly. Use systemd-analyze blame to investigate slow boot times, journalctl -b -p err to find service failures, and cat /proc/cmdline to confirm kernel parameters took effect. For boot problems you cannot fix over SSH, access the serial console or use a rescue USB.