Haiku's Boot Process: From Boot Loader to Desktop

Booting Haiku moves through a small number of distinct stages, each with its own specific failure modes — understanding the sequence makes it much easier to tell which stage a boot problem is actually happening in.

Stage 1: firmware hands off to Haiku’s boot loader

Whether the underlying firmware is legacy BIOS or UEFI, it locates and executes Haiku’s own boot loader from the boot device, which is responsible for locating the kernel and the boot packages/modules it needs, loading them into memory, and setting up the environment the kernel expects on handoff.

Haiku’s boot loader presents a menu (reachable by holding Shift or Space during boot, depending on version) offering options directly relevant to troubleshooting — most importantly a safe mode submenu:

Haiku Boot Loader
 ├── Continue booting
 ├── Select boot volume
 └── Safe Mode Options
      ├── Disable user add-ons
      ├── Disable IDE/SATA DMA
      ├── Safe video mode (fall back to VESA)
      └── ...

This menu exists specifically because a system that fails to boot normally still needs some way to reach a usable, if degraded, environment to fix the underlying problem — the same motivation behind most other operating systems’ equivalent safe/recovery boot modes.

Stage 3: kernel initialization

The kernel itself initializes core subsystems in a defined sequence — memory management first, since almost everything else depends on it, followed by the modular driver and file-system subsystems described in the Haiku kernel deep-dive. Because these are loaded as modules rather than compiled monolithically into the kernel image, a failure at this stage often points at a specific problematic module (a graphics driver, for instance) rather than the kernel core itself.

Stage 4: mounting the boot volume via packagefs

Once the kernel can access storage, it mounts the boot volume, and packagefs assembles the visible /boot/system tree from whichever packages are currently activated. A packagefs-related boot problem — a corrupted or incompatible package — is a distinct failure category from a kernel or driver problem, and is specifically what the boot loader’s “disable user add-ons” safe-mode option is aimed at working around.

Stage 5: starting user-space services and the desktop

With the boot volume mounted, Haiku starts its user-space startup sequence, eventually launching the Deskbar (Haiku’s taskbar/menu equivalent) and Tracker (the desktop/file-manager shell) — the point at which the system is visibly “booted” from a user’s perspective, even though kernel and early user-space initialization already completed several steps earlier.

Why safe mode targets specific, named subsystems rather than being one blunt switch

Notice that Haiku’s safe mode isn’t a single “boot minimally” toggle — it’s a set of specific, independently-toggleable options (disable add-ons, disable DMA, force VESA video). This granularity exists because different boot failures have genuinely different root causes, and forcing every one of them through the same blunt “minimal boot” hammer would make it harder to isolate which specific subsystem is actually at fault. Being able to disable just third-party add-ons, or just hardware-accelerated video, while leaving everything else at its normal setting, is what actually makes safe mode useful for diagnosis rather than just a fallback that happens to work.

Why understanding this sequence matters practically

A boot problem that manifests differently depending on which safe-mode option resolves it is telling you something concrete about where in this sequence the failure actually lives — a display problem fixed by forcing VESA points at the video driver stage, while a problem fixed by disabling add-ons points at something loaded after packagefs mounts the boot volume. Treating “the system won’t boot” as one undifferentiated problem, rather than tracing it to a specific stage in this sequence, is the main reason boot troubleshooting sometimes takes far longer than it needs to.