Understanding How Linux Boots Step by Step

While working with Linux systems, I often came across names like:

/dev/sda
/dev/sda1
/dev/nvme0n1

At first, they were just identifiers I used in commands. But eventually I started wondering:

• Why are disks represented like files?
• What exactly is /dev/sda?
• And how does the system go from a disk to actually starting the operating system?

Understanding these questions helped me see the Linux boot process much more clearly. Let’s walk through it from the beginning.

Why Disks Appear Inside /dev

One of the core ideas in Linux is that almost everything is represented as a file. This includes hardware devices like disks, keyboards, and network interfaces.

To make this possible, Linux creates special files called device files inside the directory:

/dev

When the Linux kernel detects a storage device, it creates an entry like:

/dev/sda

This file acts as an interface between software and the actual hardware.

When a program reads data from /dev/sda, the request goes through the kernel, which communicates with the disk hardware and retrieves the data.

So /dev/sda is not the disk itself — it is the kernel’s representation of the disk, allowing programs to interact with it in a consistent way.

Dividing the Disk into Partitions

A disk is usually not used as one large block of storage. Instead, it is divided into partitions.

Partitions allow a disk to be split into multiple logical sections. Each section can then serve a different purpose.

For example, a typical Linux system might have something like:

/dev/sda1   → boot partition
/dev/sda2   → root filesystem
/dev/sda3   → swap

Partitions help organize storage, separate system files from user data, and even allow multiple operating systems to exist on the same disk.

But this raises an important question: how does the system know where these partitions begin and end?

That information is stored in something called a partition table.

On traditional BIOS-based systems, this information lives in the Master Boot Record (MBR).

The Master Boot Record (MBR)

The Master Boot Record, or MBR, is located in the very first sector of the disk — the first 512 bytes.

Even though it is tiny, it plays an important role when a computer starts.

Inside the MBR are three key things:

• A small piece of bootloader code
• The partition table describing how the disk is divided
• A boot signature that marks the sector as valid

But how does the system actually reach this part of the disk? For that, we need to look at what happens when a computer first powers on.

How Linux boots

When a computer is powered on, the CPU does not immediately start Linux. Instead, it begins executing firmware stored on the motherboard.

On older systems, this firmware is called BIOS (Basic Input/Output System).

The BIOS performs a few initial tasks. It checks that hardware components like memory and disks are functioning correctly. This process is often called the Power-On Self Test (POST).

Once the hardware checks are complete, the BIOS determines which storage device should be used as the boot device.

After selecting the boot disk, the BIOS reads the first sector of that disk into memory. That sector is the MBR.

Since the MBR contains executable code, the BIOS then transfers control to that code, and the boot process continues from there.

However, the MBR is extremely small — only 512 bytes. That is far too little space to load an entire operating system. Instead, its job is simply to load a more capable bootloader.

Get Neelima Gundu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

On most Linux systems, that bootloader is GRUB.

GRUB: The Bootloader That Loads Linux

GRUB stands for Grand Unified Bootloader, and its job is to locate and load the Linux kernel.

Unlike the tiny boot code inside the MBR, GRUB is much more capable. It understands filesystems and can read files from disk.

This is why GRUB is typically stored in the system’s /boot directory or boot partition.

If you have ever seen a screen that allows you to choose between different kernels or operating systems during startup, you were looking at the GRUB menu.

From there, GRUB loads two important files into memory:

vmlinuz    → the Linux kernel
initramfs  → a temporary root filesystem used during early boot

Once these are loaded, GRUB transfers control to the Linux kernel.

When the Linux Kernel Takes Over

At this stage, the Linux kernel begins executing.

The kernel’s first responsibility is to initialize hardware and prepare the operating system environment. It detects devices, loads necessary drivers, and sets up memory management.

Next, the kernel mounts the root filesystem and starts the system’s init system, which on most modern Linux distributions is systemd.

From there, system services start running, background processes are launched, and eventually the system reaches the login prompt or graphical desktop.

The Boot Process in One Simple Flow

Once I understood the pieces, I found it helpful to think of the boot process as a sequence of small handoffs:

Power On
 → BIOS firmware
 → MBR
 → GRUB bootloader
 → Linux kernel
 → systemd
 → Login prompt

Each stage performs a small task and then hands control to the next stage.

Try Exploring This on Your Own System

If you’re curious to see these concepts on your own machine, a few Linux commands can help visualize them.

See All Disks and Partitions

You can list all disks and their partitions using:

lsblk

Example output:

sda      100G
├─sda1     1G
└─sda2    99G

This shows the disk (sda) and the partitions inside it.

See Detailed Disk Information

Another useful command is:

sudo fdisk -l

This prints detailed information about disks, partition sizes, and partition types.

It’s a good way to see how your disk is structured.

Check Which Kernel Is Running

You can also check which kernel version your system booted with:

uname -r

This is helpful when multiple kernels exist and GRUB allows you to choose between them.

A Small Thing That Changed My Perspective

Before learning this, a boot failure felt like a black box problem.

Now it’s easier to reason about where something might have gone wrong:

• If the system cannot find the disk, the issue might be hardware or firmware.
• If GRUB does not appear, the bootloader may be damaged.
• If the kernel loads but the system fails later, the issue might be with the filesystem or initramfs.

Understanding the layers makes troubleshooting much more structured.