What Actually Happens When Linux Boots

Ever watched a Linux box freeze on boot and thought:
“Okay… but what exactly is stuck?”

That feeling goes away once you can point to the stage:
firmware, bootloader, kernel, init, or user space.

Here’s the boot process the way your brain actually debugs it.

When you hit the power button, the CPU knows nothing about Linux.

First, the firmware wakes up: either BIOS (old) or UEFI (new).
It runs POST: quick checks on RAM, CPU, and attached devices.
Then it scans for disks, NVMe, USB, maybe even network boot.

From there it picks a boot device based on the configured boot order.
With BIOS, it reads the MBR from the first 512 bytes of the disk.
With UEFI, it looks for an EFI System Partition (ESP) and .efi files.

If that fails, you get the classic:

Notice: Linux isn’t running yet.
You’re still in firmware + disk layout territory.

To see where GRUB lives, you have to understand the disk layout.

On MBR systems:

On GPT + UEFI systems:

Firmware either jumps into MBR boot code (legacy)
or loads an .efi binary from the ESP (UEFI).
That small piece then hands off to GRUB.

GRUB is the bridge between firmware and the Linux kernel.

It’s usually the menu you see with:

What GRUB actually does:

If GRUB is broken, you’ll see things like:

At this point, the kernel is still just a file on disk.
GRUB’s only job is to get it into memory and hand over control.

Once GRUB jumps, the Linux kernel takes over.

The kernel starts as a compressed binary (vmlinuz) in memory.
It decompresses itself, sets up low-level CPU and memory state,
initializes page tables, and wires up built‑in device drivers.

Then it mounts a temporary root filesystem from initrd/initramfs.

What is that?

Think of initrd/initramfs as a tiny Linux environment packed into a file.
Its job is to:

Once it finds and mounts the real root, it does a switch_root
and your “real” system becomes visible.

When this part fails, you’ll see:

That’s your signal: kernel is running, but it can’t reach your real /.

After switching to the real root filesystem, the kernel needs one thing:
a first user‑space process - PID 1.

Historically that was /sbin/init.
On most modern distros, it’s /lib/systemd/systemd
(often symlinked from /sbin/init).

The kernel looks for init roughly in this order:

If none of these can be started, you’ll hit:

When systemd does start as PID 1, it becomes the conductor:

This is where you see lines like:

Once that scroll settles, you’re in “normal” Linux user space.

From there, it’s the usual story.

systemd starts getty on tty1, tty2, and friends for console logins.
Or it launches a display manager like GDM, SDDM, or LightDM for GUI logins.

On a pure console system, you’ll see:

On a desktop, you get a graphical login prompt.
You authenticate, a shell or desktop session starts,
and now you’re in the world we spend most of our time in - processes, services, and userland tooling.

Here’s the mental model that makes this stick.

Treat the Linux boot process as a pipeline:

Each stage failing gives a different symptom.
Once you can name the stage, you stop guessing and start inspecting the right layer.

In practice, that looks like this:

Once you see boot as a pipeline instead of a black box,
“Linux just hangs” turns into “it’s failing right here, let’s fix this stage.”