Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Phase 201 — assemble the first ONIX root tree

At a glance

FieldValue
Phase familyPhase 2 — bootable image
Run commandmake phase 201
Underlying make target/scriptvm/phase2/build-root-tree.sh
Runs onhost plus guest over SSH
Main proof/artifactAssembles artifacts/onix-root-tree/ through the older forge bridge path.

Phase 201 is the first big conceptual jump in Phase 2.

Before this point, we proved packages in disposable Moss test targets. Phase 201 starts acting like an image builder:

exported repo artifact -> package install -> root filesystem tree

It still does not create a disk image. It does not partition anything. It does not mount anything. It does not boot. The output is just a directory tree on the host:

artifacts/onix-root-tree/

That directory is gitignored because it is generated build output.

Why Phase 201 uses the forge

When Phase 201 was introduced, the host did not yet have moss.

Also, .stone files are not tarballs. They are Moss stone containers. That means Phase 201 should not pretend the host can unpack them with tar.

So the Phase 201 flow is:

host artifacts/onix-publish/
   │
   │  stream to forge
   ▼
forge moss install --to root-tree
   │
   │  materialize image-owned /etc glue
   ▼
forge root-tree/
   │
   │  tar stream back to host
   ▼
host artifacts/onix-root-tree/

This is temporary bootstrap architecture, but it is honest. Phase 201 remains a useful bridge/proof, even after Phase 202 adds host-side Moss, because it shows the exact point where the forge used to be required.

What the packages provide

The root tree receives package-owned files from:

onix-branding
onix-filesystem

Important package-owned files include:

/usr/lib/os-info.json
/usr/lib/os-release
/usr/share/onix/branding/logo.txt
/usr/share/onix/branding/logo.ansi
/usr/share/onix/filesystem-layout.md
/usr/share/defaults/etc/fstab
/usr/share/defaults/etc/issue
/usr/share/defaults/etc/motd
/usr/share/defaults/etc/profile.d/onix-path.sh

The important design rule stays the same:

packages own /usr
image assembly owns root-level machine glue

That is why onix-branding and onix-filesystem ship defaults under /usr/share/defaults/etc/ instead of directly owning live /etc.

What image assembly materializes

Phase 201 creates the first root-level machine view:

/etc/os-release -> ../usr/lib/os-release
/etc/issue
/etc/motd
/etc/fstab
/etc/profile.d/onix-path.sh
/etc/hostname

/boot
/dev
/efi
/home
/persist
/proc
/run
/sys
/tmp
/var

This is not random copying. It is the first image-assembly policy:

  • /etc/os-release is a compatibility symlink to the Moss-generated identity file under /usr/lib.
  • /etc/issue, /etc/motd, /etc/fstab, and /etc/profile.d/onix-path.sh are materialized from packaged defaults.
  • runtime/kernel directories such as /dev, /proc, /sys, and /run are created as empty mount points/placeholders. They are not package payload.
  • /tmp gets sticky permissions because users/processes share it.

What Phase 201 proves

Phase 201 proves:

  • the host-exported repo artifact is usable as an image input
  • the forge can install from that copied artifact by repo index
  • onix-branding and onix-filesystem compose into one root tree
  • image-owned /etc materialization is separated from package payload
  • the result can be exported back to the host as a clean artifact

It also verifies:

  • /usr/lib/os-release says NAME="ONIX" and ID="onix"
  • ANSI_COLOR matches the real ONIX blue
  • the ONIX terminal logo exists
  • /etc/os-release is the correct relative symlink
  • fstab contains onix-root and ONIX-PERSIST
  • no forbidden mixed-case brand spelling appears
  • Moss assembly state does not leak into the exported root tree

What Phase 201 does not prove

Phase 201 does not prove bootability.

The root tree still has no real ONIX kernel package, no init system package, no bootloader installation, no partition table, and no mounted filesystems. Those are later Phase 2 steps.

The point of this phase is to make the next step smaller. After 201, disk image work can consume a known-good root tree instead of solving packaging, repository, filesystem policy, and disk layout all at once.