Conteúdo do Tutorial / Guia Passo a Passo:
-------------------------------------------------------------------------
Open a terminal on any systemd machine and run this:

systemd-analyze

On the laptop I'm writing this on, it says:

Startup finished in 5.855s (firmware) + 8.469s (loader) + 3.106s (kernel)
+ 12.181s (userspace) = 29.613s
graphical.target reached after 12.175s in userspace

Add those four and you get 29.611, not the 29.613 printed on the last line. That gap is real and it isn't a mistake:
systemd-analyzetruncates each phase for display while summing the underlying microseconds, so a couple of milliseconds hide in the rounding. It's a small thing, and it will save you an evening of hunting for a bug that isn't there.

Four numbers, and most people's mental model accounts for one of them. The kernel took three seconds. The bootloader before it took eight and a half, and the firmware before that took nearly six. Fourteen seconds of this machine's boot happened before Linux was running at all, and I chose a good part of it without noticing.

This article follows the Linux boot process the whole way through one real boot, from the firmware handing control to a bootloader to a login prompt on your screen. Everything here you can run yourself, and almost none of it needs root.

Table of Contents

• What you need

• The Linux boot process is four handoffs, not one

• Firmware, and the part Linux never sees

• The bootloader, and the five seconds you chose

• The kernel phase: three seconds to a working machine

• What the initramfs is, and the chicken-and-egg problem it solves

• PID 1, and where the other twelve seconds go

• Why systemd-analyze blame misleads you about boot time

• Reading the critical chain

• Why your Linux boot time will be different

• The login screen, and the handoff to you

• Conclusion

• Epilogue

What You Need

Any Linux machine running systemd, which covers Ubuntu, Debian, Fedora, Arch, and most things people install in 2026. A terminal. That's it.

The machine I'm measuring is Ubuntu 22.04.5 LTS running kernel 5.15.0-190-generic, booting in UEFI mode from an NVMe disk with an ext4 root filesystem, with systemd 249 as PID 1. Yours will differ, sometimes by a lot, and I'll say where to expect that.

One command needs root and one file is restricted on many systems. I'll flag both when we get there.

The Linux Boot Process is Four Handoffs, Not One

The word "boot" suggests a single process. But it's four, and they barely know about each other.

Firmware runs first, from a chip on the motherboard, and its job is to find something bootable and start it.

It then hands control to a bootloader and stops. The bootloader's job is to find a kernel, load it into memory along with an initial filesystem, and jump to it. It then stops.

The kernel brings up hardware, mounts a root filesystem, and starts exactly one userspace process. Then it stops being in charge, though it keeps servicing that process forever afterward.

That first process, PID 1, starts everything else.

Each handoff is one way. The firmware isn't sitting underneath Linux waiting to help. The bootloader is gone from memory. Hold onto that, because it explains why the four numbers in
systemd-analyzeare measured by different things and mean different things.

Firmware, and the Part Linux Never Sees

The 5.855 seconds attributed to firmware is the only figure here that Linux didn't measure itself, and you ca

... [O tutorial continua no link abaixo] ...