Phase 201 — assemble the first ONIX root tree
At a glance
| Field | Value |
|---|---|
| Phase family | Phase 2 — bootable image |
| Run command | make phase 201 |
| Underlying make target/script | vm/phase2/build-root-tree.sh |
| Runs on | host plus guest over SSH |
| Main proof/artifact | Assembles 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-releaseis a compatibility symlink to the Moss-generated identity file under/usr/lib./etc/issue,/etc/motd,/etc/fstab, and/etc/profile.d/onix-path.share materialized from packaged defaults.- runtime/kernel directories such as
/dev,/proc,/sys, and/runare created as empty mount points/placeholders. They are not package payload. /tmpgets 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-brandingandonix-filesystemcompose into one root tree- image-owned
/etcmaterialization is separated from package payload - the result can be exported back to the host as a clean artifact
It also verifies:
/usr/lib/os-releasesaysNAME="ONIX"andID="onix"ANSI_COLORmatches the real ONIX blue- the ONIX terminal logo exists
/etc/os-releaseis the correct relative symlink- fstab contains
onix-rootandONIX-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.