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 202 — build host-side Moss

At a glance

FieldValue
Phase familyPhase 2 — bootable image
Run commandmake phase 202
Underlying make target/scriptvm/phase2/build-host-moss.sh
Runs onhost
Main proof/artifactBuilds artifacts/host-tools/bin/moss from pinned os-tools.

Phase 202 is the next bootstrap cleanup.

Phase 201 proved that the exported repo can become a root tree, but it still used Moss inside the forge:

host repo artifact -> forge moss -> host root tree

That is useful, but it is not where we want to stay. The forge is temporary bootstrap scaffolding. Image assembly should become host-native:

host repo artifact -> host moss -> host root tree -> disk image

Phase 202 builds a host-side moss binary from the same pinned os-tools source used by Phase 0:

artifacts/host-tools/bin/moss

It requires Rust >= 1.91. The ONIX flake provides a new enough toolchain. If your shell still reports an older rustc, reload the dev shell:

direnv reload

or run the phase explicitly through Nix:

nix develop --impure -c make phase 202

It also records the source pin at:

artifacts/host-tools/os-tools.source
artifacts/host-tools/os-tools.git-deps

That file is generated and gitignored with the rest of artifacts/.

Source policy

ONIX currently treats AerynOS os-tools as pinned bootstrap tooling.

The current source of truth is still:

OS_TOOLS_REPO=https://github.com/AerynOS/os-tools.git
OS_TOOLS_REF=36f78e5bcfa9d594d65d1c6d2e332e950f3e4d0e

The pinned commit protects ONIX from upstream code changes.

It does not protect ONIX from source availability problems such as:

  • upstream repository deletion
  • upstream repository rename
  • GitHub outage
  • git dependency disappearing

So the future source-control policy should be:

1. mirror/fork os-tools into github.com/onix-os/os-tools
2. keep the exact same commit first
3. switch OS_TOOLS_REPO to the ONIX mirror
4. only diverge on an ONIX branch when ONIX needs patches

That means the first ONIX mirror step is boring on purpose. It is availability insurance, not a fork-war.

os-tools may also contain git dependencies such as boot tooling crates. When we switch to ONIX mirrors, we must audit the Cargo.toml/Cargo.lock graph and mirror every git dependency that matters for reproducible bootstrap.

At the current pin, Phase 202 records these git dependencies:

https://github.com/AerynOS/blsforme.git?rev=680720545303e123e47e0df07a8a85178c9f5c19
https://github.com/AerynOS/disks-rs?rev=d08bc11dcfb2ad4d031e2adccb97139f9d42c2b8
https://github.com/AerynOS/ent.git?rev=42416ecae36c0f29e07647747147672448241f85
https://github.com/AerynOS/os-info?rev=26b39c1d49c3b4f30d778729fb56958824c069de
https://github.com/kdl-org/kdl-rs?rev=e9df058c25cd4486df8fe568d2ff24ea2c4ed0e8

The ONIX mirror priority should be the AerynOS-owned dependencies first:

os-tools
blsforme
disks-rs
ent
os-info

kdl-rs is not AerynOS-owned, but it is still a pinned git dependency. We can leave it upstream for now or mirror it later if we want fully independent bootstrap availability.

What Phase 202 proves

Phase 202 proves:

  • the host dev shell has enough Rust/build tooling to compile Moss
  • the host can fetch and checkout the exact same pinned os-tools ref
  • the resulting host binary runs
  • ONIX has a generated host-tool location for future phases

It does not yet replace Phase 201.

That replacement should be a separate phase so the learning step is obvious:

203 = rebuild root tree using host Moss only

At that point the flow becomes:

artifacts/onix-publish/
   │
   ▼
artifacts/host-tools/bin/moss install --to artifacts/onix-root-tree

No SSH, no forge copy, no forge Moss.