Skip to content
Expert LinuxLesson 25 of 27 4 min read

The Linux Boot Process & Kernel

From power-on to a login prompt: firmware, bootloader, kernel, initramfs, and PID 1.

Skip to the challenge
On this page9 sections

Every command in this course runs after a machine has already finished an elaborate handoff of control - from firmware, to a tiny bootloader, to the kernel itself, to the first real process. Knowing that sequence is what turns "the server won't come back up" from a mystery into a checklist.

1. Firmware: BIOS or UEFI

The moment a machine powers on, firmware built into the motherboard runs first - either the older BIOS or the modern, more capable UEFI. Its only job is to initialize just enough hardware to find a storage device with a bootloader on it, then hand control over.

2. The bootloader: GRUB

On most Linux systems, that bootloader is GRUB (GRand Unified Bootloader). GRUB shows the menu you sometimes see for a few seconds at startup - pick a kernel version, or boot into recovery mode. Its configuration lives at /boot/grub/grub.cfg, generated from /etc/default/grub and the kernels actually installed in /boot. GRUB's job ends the moment it loads a kernel image into memory and jumps to it.

3. The kernel and initramfs

The kernel image (/boot/vmlinuz-<version>) is the Linux kernel itself. But it needs drivers to even read the real root filesystem - a chicken-and-egg problem solved by the initramfs (initial RAM filesystem): a small, temporary filesystem loaded into memory alongside the kernel, containing just enough drivers and tools to find and mount the real root disk. Once that's mounted, the kernel switches over to it and initramfs's job is done.

4. PID 1: systemd takes over

The kernel then starts exactly one process by hand - conventionally /sbin/init, which on virtually every modern distribution is a symlink to systemd. That process always gets process ID 1, and everything else on the system - every service, every shell, every one of the commands you've run in this course - is its descendant, directly or indirectly. This is exactly where the systemd lesson picked up the story; boot is the part that happens before systemctl has anything to manage yet.

Watching it happen: dmesg

The kernel logs everything it does during this process into an in-memory ring buffer, readable with dmesg:

bash
dmesg

[    0.000000] Linux version 5.15.0 (gcc 11.4.0)
[    0.012345] Command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro quiet
[    0.456789] EXT4-fs (sda1): mounted filesystem with ordered data mode
[    1.012345] systemd[1]: Starting Journal Service...

Those bracketed numbers are seconds since boot - dmesg is the single best place to find why a boot failed: a missing driver, a filesystem that wouldn't mount, a device that timed out.

Kernel modules

The kernel doesn't ship every driver built permanently in - most are modules, loaded on demand:

bash
lsmod                     # list currently loaded kernel modules
modprobe <name>           # load a module (and anything it depends on)
rmmod <name>              # unload a module

This is why plugging in a new USB device can "just work" without a reboot: the kernel detects it and modprobes the matching driver module on the spot.

/proc and /sys: the kernel as a filesystem

Once running, the kernel exposes live information about itself through two virtual filesystems that exist only in memory, never on disk:

  • /proc - one directory per running process (/proc/1284), plus system-wide info like /proc/cpuinfo and /proc/meminfo. uname, free, and ps all ultimately read from here.
  • /sys - a structured view of devices, drivers, and kernel parameters, organized by the hardware they represent.

Both are why so many "reading system state" commands are actually just formatted cats of a file under one of these two trees.

Try it

Run these in the practice terminal (opens in a new tab). It opens in a new tab, so you keep your place here.
bash
uname -a
dmesg
lsmod
modprobe nonexistent-driver

Further reading

  • "How Linux Works" by Brian Ward (No Starch Press) - its boot chapter walks through firmware, GRUB, initramfs, and systemd startup in exactly this order, with real config file locations.
  • "Linux Kernel Development" by Robert Love (Addison-Wesley) - goes further into what the kernel is actually doing once control reaches it, for anyone curious past the boot sequence itself.

Challenge

Print detailed kernel version information, then view the kernel's boot log. Do both in one line joined with &&.

Want to experiment first? Try things in the practice terminal (opens in a new tab), then enter the command that solves the task here.

Quiz

Lock in the concepts. Score at least 80% to mark the lesson complete.

0 of 3 answered

Done with this one?

Skipped the challenge? You can mark the lesson complete by hand.

Your notes

Kept on this browser only.