How it boots

This page is about what happens between power-on and a desktop. For getting a live image onto a machine, see Booting the live image; for putting it on a disk, see Installing.

One ELF, more than one way in

The kernel is a single higher-half ELF image carrying more than one boot header, so the same file boots from more than one loader without a separate build for each.

On 64-bit the kernel is loaded by a multiboot2-capable bootloader and then runs its own 32-to-64-bit trampoline rather than using the loader's native protocol. That is a deliberate choice: it means the descriptor tables, paging and no-execute policy are the kernel's own from the first instruction, and that the same protocol is used everywhere rather than one per loader.

What is live once the kernel is up

• A descriptor table in Linux's ordering, with 64-bit kernel and user segments plus a 32-bit user segment — which is what makes the Win32 subsystem possible without a second address space.
• An interrupt table whose trap frames are designed so that a 32-bit compatibility frame is a variant of the same frame rather than a second entry path.
• Four-level paging with a direct map of physical memory, no-execute enabled, and the identity map dropped once it is no longer needed.
• A periodic timer, and symmetric multiprocessing with the other cores brought online.

There is a hard build-time assertion that the early kernel stays within the memory the earliest boot code has mapped. Growth past that point is a build failure, not a mysterious early hang — which is the difference between an afternoon and a week.

Roots

The kernel can start from several kinds of root filesystem, and all of them are in routine use:

• An initial ramdisk, unpacked into memory.
• A SquashFS image, read on demand and unioned with a writable overlay. This is what the live image uses: the system is read-only and everything you change lives in RAM.
• A real disk, after installation.
• A SquashFS image over the network, which is how the lab machines run.

A live boot and an installed boot are the same system. The difference is where the root comes from and whether your changes survive a reboot.

Mounting disks

/etc/fstab works as you would expect, and the installer writes one. A disk mounted there appears in the file manager's sidebar because that list is the real mount table rather than a separate registry of places.

Filesystem layout

The system presents itself as a volume rather than as a raw Unix tree. At the root of the system disk the file manager shows Applications, Users and System; the familiar Unix directories are all there and are one keystroke away, but they are not what you meet first.

Applications live in a versioned layout with a system-wide index of links to the current version of each — see Ports and packaging.

Two architectures, one tree

The kernel builds for both 32-bit and 64-bit x86 from one source tree, into artefacts that are fully disjoint, so the two can never clobber each other.

Where the two genuinely differ — the shape of an address space, the layout of a signal mask — the difference is named once in a shared header and accessed through a question rather than aliased into a single expression that parses on both and is wrong on one. That is not a stylistic preference: aliasing two subtly different signal masks produced the same class of bug repeatedly, and asking the question instead is what stopped it.