Phase 202 — build host-side Moss
At a glance
| Field | Value |
|---|---|
| Phase family | Phase 2 — bootable image |
| Run command | make phase 202 |
| Underlying make target/script | vm/phase2/build-host-moss.sh |
| Runs on | host |
| Main proof/artifact | Builds 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-toolsref - 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.