Phase 210 — init path decision contract

At a glance

Field	Value
Phase family	Phase 2 — bootable image
Run command	`make phase 210`
Underlying make target/script	`vm/phase2/verify-init-decision.sh`
Runs on	host
Main proof/artifact	Records the current init decision: systemd-on-musl plus systemd-boot.

Phase 210 turns the Phase 209 probe into an explicit project decision.

Phase 210 does not build the init system. It does not install systemd. It does not mount the image. It does not boot QEMU.

It only records how ONIX will proceed.

The decision

The Phase 210 decision is:

init path: systemd-on-musl
bootloader: systemd-boot

Project rule:

keep systemd if we can

In plain words: ONIX uses systemd as PID 1.

That means we continue with the systemd path for now because Phase 209 showed:

pkgsMusl.systemd exists
pkgsMusl.systemd targets musl
pkgsMusl.systemd is not marked broken
pkgsMusl.systemd uses -Dlibc=musl
Nix can plan the build graph

But we do not pretend that systemd is proven boot-ready. The systemd path still has to prove itself in real ONIX builds and boots.

Why bootloader and init are separate

The bootloader chooses and launches the kernel.

The init system is the first userspace process after the kernel mounts the real root filesystem.

Those are different jobs:

systemd-boot  -> bootloader
systemd       -> init system / PID 1

That is why the decision names both parts explicitly:

systemd-boot loads the kernel
systemd runs as PID 1

What this means for the boot entry

The BLS entry keeps this kernel command line intent:

init=/usr/lib/systemd/systemd systemd.unit=multi-user.target

That path is the userspace handoff point:

kernel -> root filesystem -> /usr/lib/systemd/systemd

So Phase 211 and later must place a real systemd userspace at that path.

What Phase 210 verifies

make phase 210 verifies:

this Phase 210 section exists
the init path is systemd-on-musl
the bootloader is systemd-boot
the project rule says keep systemd if we can
the plan says ONIX uses systemd as PID 1
the boot entry points at /usr/lib/systemd/systemd
the plan mentions systemd starts as PID 1
the plan mentions udev/device setup works
the plan mentions basic services work
the Phase 206 boot skeleton still follows the systemd path

What Phase 210 does not prove

Phase 210 does not prove:

systemd builds
systemd boots
services work
QEMU reaches login

It only makes the next engineering decision explicit.

Keyboard shortcuts