The Linux Boot Process
Turning the machine on kicks off a chain: firmware hands off to a boot loader, the boot loader hands off to a kernel, and from there it’s still a few more steps before you’re looking at a login screen. The earlier post on partitioning a disk already covered how firmware finds that boot loader in the first place, BIOS and MBR versus UEFI and GPT, so this post picks up right after that handoff: what the kernel does when it starts, why PID 1 matters, how systemd decides what to run and in what order, and exactly where Arch stops making decisions for you and hands control over to whatever you choose next, the actual desktop environment, which is the subject of the next post.
The Kernel Takes Over #
Once the boot loader hands control to a kernel it found on disk, the kernel takes it from there. It runs its own low level initialization: detecting hardware, setting up memory management, mounting an initial root filesystem, all the plumbing that has to exist before anything else on the system can run. Once that’s done, once the hardware and the kernel’s internal data structures are actually ready to serve, the kernel starts a single, very particular process and hands off to it.
PID 1: From sysvinit to systemd #
That first process is called init, and by convention it always gets process ID 1. It isn’t part of the kernel itself, it’s an ordinary userspace program, the kernel just always starts it first and treats it specially: if PID 1 ever dies, the kernel panics. Its job is to start every other process on the system.
There have been a few implementations of init over the years. The traditional one was sysvinit, plain shell scripts run in a fixed order. Most modern distributions, Arch included, have since moved to systemd.
systemd doesn’t really follow the Unix philosophy of doing one thing and doing it well, it does a lot, and it gets criticized for that constantly. It clearly has problems, but it seems to solve more than it introduces, which is why almost every major distribution ships it today. Getting into how it actually works internally, or its famously complicated configuration, is a topic on its own. What matters here is just enough to see how it gets you to a login screen.
Units, Dependencies, and Getty #
systemd organizes everything into units, and units declare dependencies on each other, this unit needs that one to have already started. Somewhere in that dependency graph sits a unit called Getty, and by the time systemd reaches it, everything Getty depends on is already running: filesystems are mounted, the network is up, background services have started. Getty’s job is simple, it’s what presents a way to log in.
Exactly what that looks like usually comes down to whatever desktop environment or display manager is installed, since they typically override Getty’s default configuration. Left unconfigured, Getty gives you a bare text login prompt. Configured by a display manager, it’s a graphical login screen instead.
Where Arch Leaves You #
Here’s why any of this matters: install Arch, and by the end you already have a chain that works end to end. The boot loader is in place and knows how to find the kernel, the kernel is in place and knows to start systemd, systemd is in place and knows how to reach Getty. What Getty actually does once it gets there, though, a bare prompt, a graphical login manager, straight into a window manager with no login screen at all, is left entirely up to you. That’s the whole point, and it’s exactly where the next post picks up.