Phase 212 — first QEMU boot probe

At a glance

Phase 212 is the QEMU boot probe for the generated ONIX image.

It is still a probe.

It is not a promise that the OS reaches login.

The exact meaning of the probe depends on which image layers have already been staged.

After Phase 211, the image has:

disk partitions
root filesystem skeleton
systemd-boot
BLS boot entry
kernel
initramfs

At that point, Phase 212 is expected to find the next missing userspace layer.

After Phase 213, the image also has:

/usr/lib/systemd/systemd

After Phase 214, the image also has:

/usr/bin/kmod
/usr/sbin/modprobe
/usr/lib/modules/<kernel-release>

So Phase 212 is reusable. It asks:

what exact boot milestone does the current image reach?

The expected learning value is still not “a finished OS”.

The expected learning value is evidence:

does OVMF find systemd-boot?
does systemd-boot load /boot/ONIX/vmlinuz?
does the kernel receive the right command line?
does the initramfs get far enough to try the real root?
does the kernel hand off to systemd?
does systemd reach multi-user.target?
do /boot and /efi mount cleanly?
what is the next missing layer or warning?

Why a boot probe is useful even before login

Boot is a chain.

Each link hands control to the next link:

QEMU
  -> OVMF firmware
  -> systemd-boot
  -> Linux kernel
  -> initramfs
  -> ONIX root filesystem
  -> /usr/lib/systemd/systemd

If the chain breaks, the serial log tells us which link broke.

That is better than guessing.

Why Phase 212 uses a serial log

Graphical boot output is easy to miss and hard to copy.

Serial output is plain text.

Phase 212 writes it here:

vm/state/phase212.serial.log

The probe also prints the serial log while QEMU is running so you can watch the boot happen.

How to watch Phase 212 attached

Normal Phase 212 is headless and automatic:

make phase 212

If you want to see the serial console directly in your terminal, run one of these:

ATTACHED=1 make phase 212
make phase 212 ATTACHED=1

Those are equivalent.

Attached mode runs QEMU in the foreground. It does not stop QEMU automatically. The default attached display is the terminal serial console:

ONIX_BOOT_PROBE_DISPLAY=serial

To exit terminal serial mode, press:

Ctrl-a then x

or press Ctrl-C.

If you explicitly want a GTK window:

ONIX_BOOT_PROBE_DISPLAY=gtk ATTACHED=1 make phase 212

If you explicitly want VNC:

ONIX_BOOT_PROBE_DISPLAY=vnc ATTACHED=1 make phase 212

Then connect a VNC viewer to:

127.0.0.1:5900

There is also a QEMU -nographic mode:

ONIX_BOOT_PROBE_DISPLAY=none ATTACHED=1 make phase 212

Why normal Phase 212 stops QEMU itself

Normal Phase 212 is not meant to leave you trapped in a VM.

It runs QEMU in the background, waits for a short probe window, captures the serial log, then stops only the Phase 212 QEMU process:

process name: onix-phase212

It does not kill unrelated QEMU VMs.

Why Phase 212 uses a snapshot disk

The QEMU disk is opened with snapshot writes.

That means the boot probe can read the generated image, but runtime writes do not permanently change artifacts/onix-image/onix.raw.

This keeps the image artifact reproducible while we are still learning.

What Phase 212 verifies

make phase 212 verifies:

• artifacts/onix-image/onix.raw exists
• OVMF firmware exists
• QEMU can launch the image
• serial output is captured
• the Linux kernel starts
• the kernel command line contains root=LABEL=onix-root
• the kernel command line contains init=/usr/lib/systemd/systemd
• the log contains useful boot evidence
• if present, systemd userspace can be observed in the serial log
• if reached, multi-user.target is reported as the strongest milestone

What Phase 212 does not prove

Phase 212 does not prove:

networking works
login works
the final package ownership model is complete
all mounts are strict and clean

Those need later phases.

What comes after 212?

Once Phase 212 proves the image reaches systemd, the next safe progression is to remove bootstrap shortcuts one by one.

Examples:

214 = add the first module/kmod payload
future = make /boot and /efi strict once they mount cleanly
future = add real login/user/networking policy
future = replace imported bootstrap payloads with ONIX-owned stones

The key learning point: Phase 2 is where we stop proving packages only in disposable targets and start assembling the actual ONIX machine layout one layer at a time.