Linux Boot Process: Clearer Than Your BIOS Screen

What is Booting?

Booting means turning on your computer and getting it ready so you can use it — like logging in and opening apps.

Now, what happens when you press the power button?

Power On

You press the power button on your laptop or PC.

Electricity starts flowing into the computer.

The main chip on the motherboard, called the CPU, wakes up — but it doesn’t know what to do yet.

BIOS / UEFI (Firmware)

BIOS/UEFI is the hardware chip with a cmos battery installed on the motherboard containing a small program.

BIOS/UEFI stands for:

BIOS – Basic Input/Output System

UEFI – Unified Extensible Firmware Interface

BIOS/UEFI is the first program your computer runs when it turns on. It checks your hardware:

Is your RAM okay?

Is the CPU working?

Is your keyboard, disk, monitor connected?

This test is called POST (Power-On Self-Test).

Once everything looks fine, BIOS/UEFI says:

"Alright, now let’s find the Operating System (like Linux or Windows) and start it!"

But BIOS/UEFI doesn't know how to run Linux directly — it needs help.

So now, what helps BIOS start Linux?

This is where the "bootloader" comes in.

What is a Bootloader?

Easy Definition:

A bootloader is a small program that loads your main operating system (Linux) from the hard disk into memory, and starts it.

Think of it like:

BIOS: “I’ve checked everything, now I need someone to bring Linux in.”

Bootloader: “I’m here! I’ll go get Linux and start it.”

Where is the bootloader?

It is stored on a special part of your hard drive called the:

MBR (Master Boot Record) or EFI System Partition (for newer systems).

What bootloader does Linux use?

Linux usually uses a bootloader called:

GRUB = GRand Unified Bootloader

Recap of the flow so far:

You press the power button.

BIOS/UEFI runs first (in motherboard).

It checks hardware (POST).

Then it finds the bootloader on the hard disk.

The bootloader (GRUB) takes over.

What does the bootloader (GRUB) do?

The bootloader (GRUB):

Shows a menu if you have multiple OSes (e.g., Linux, Windows).

It also shows if you have multiple kernels, and which one to boot with. if you dont specify, it selects default kernel.

Loads the Linux Kernel (the brain of Linux).

Loads initramfs (a temporary filesystem).

Gives control to the Linux kernel to start the OS.

So GRUB’s job is simple:

Find the Linux system, load it, and hand over control to kernel.

Then what happens?

Once the Linux kernel starts, it:

Sets up the computer (memory, CPU, hardware).

Uses initramfs to find the real Linux files and sets up real file system.

Starts the first Linux program: init or systemd with PID1.

Then:

Services are started.

Login screen is shown.

You use the computer!

---

Now, lets understand what initramfs is:

initramfs = initial RAM file system

It is a temporary root file system used very early in the Linux boot process, before the real system is ready.

Why do we need initramfs?

Because when the Linux kernel starts, it doesn’t yet know how to access your real root filesystem (like / on your hard drive).

Why not?

Your real root filesystem may need:

Drivers to load

Kernel modules

Disk decryption passwords

Mount instructions

So we use initramfs as a temporary root environment to load the necessary tools, drivers, and modules that will help the kernel mount your actual root filesystem.

What’s inside initramfs?

It is basically a compressed cpio archive containing:

A minimal Linux environment

An init script (or /init binary)

Kernel modules (like filesystem, storage drivers)

Tools like udev, lvm, cryptsetup if needed

It lives in /boot/initramfs-<version>.img

Example: /boot/initramfs-5.14.0-362.el9.x86\_64.img

How does initramfs work in the boot process?

Let’s plug it into the boot flow:

Power on → BIOS/UEFI runs

BIOS loads GRUB

GRUB loads:

vmlinuz → the Linux kernel

initramfs.img → the initramfs file

GRUB gives control to the kernel

Kernel extracts initramfs into RAM

Kernel runs /init inside initramfs

Loads modules (filesystem, disk)

Detects and mounts real root filesystem (/)

Once real / is mounted → it switches from initramfs to real system

Kernel runs systemd (PID 1) from the real root

---

Now, lets understand init:

What is init?

• init is the first userspace process started by the Linux kernel.

• It is always assigned PID 1 — this is not just tradition, it’s a rule. The kernel hands over control to it after finishing low-level hardware initialization.

Why is init needed?

Because the kernel only handles hardware and basic scheduling. It doesn’t know what services or programs to run. That’s what init does:

Responsibilities of init:

1. Mounts your file systems (like /, /home, /var, etc.).

2. Starts background services (daemons) like:

   • Network manager

   • Audio

   • Display manager

   • SSH server

3. Spawns login interfaces (terminal or GUI login screen).

4. Reads system config and decides what kind of mode (multi-user? GUI? recovery?) the system should enter.

Different types of init systems:

• SysVinit (older systems) — uses numbered runlevels

• Systemd (modern systems) — uses named targets

• Upstart (used in older Ubuntu) — event-based

We'll focus on SysVinit and Systemd here.

Runlevels (SysVinit) vs Targets (Systemd)

Let’s now answer your core confusion:

If init prepares the system for login, then what’s the point of runlevels?”

Good question.

Here's the answer:

init doesn’t decide everything by itself. It checks a configuration file that tells it:

“Hey, once you're up, take the system to runlevel X or target Y.”

This determines what services get started, what environment the user sees (GUI? terminal?), etc.

Let’s look at both:

SysVinit and Runlevels

• Init reads /etc/inittab file.

• That file tells init which runlevel to go to by default (e.g., runlevel 5 = GUI mode).

• Each runlevel has a list of services to start or stop.

Common Runlevels:

Example: If /etc/inittab says id:5:initdefault:, then init will go to runlevel 5 → start GUI login screen.

Systemd and Targets (modern Linux)

Systemd replaces init with a more powerful system manager.

• The first process is still systemd with PID 1.

• Instead of runlevels, it uses targets like graphical.target, multi-user.target.

Think of targets as collections of services.

• graphical.target includes GUI + multi-user services.

• multi-user.target includes only CLI + networking.

Systemd is modular: targets can depend on each other, unlike fixed runlevels.

systemd reads from:

• /etc/systemd/system/default.target → this is a symlink to your default target.

So how does the boot flow go with systemd?

1. Kernel boots, executes /sbin/init → actually points to systemd

2. systemd (PID 1) starts

3. It looks at default.target (e.g., graphical.target)

4. It loads all units (services) defined by that target

5. Brings up the login screen (text or GUI)

If you found this helpful, feel free to share or bookmark it. Got a boot-related question? Drop a comment or reach out!