generated from erix/meta
[FEATURE] Demonstrate two complete generations of EriX built inside EriX #9
Labels
No labels
bug
ci
docs
duplicate
enhancement
help wanted
invalid
performance
phase-6
question
refactor
security
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
erix/integration#9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem and motivation
The required result is a full build of EriX performed within EriX, then repeated within the newly guest-built system. A hello-world, one crate, host cross-build, precompiled product cache or external image assembly does not meet that result.
Proposed behavior and scope
Boot a private admitted seed image, run the complete source-only product build from exsh, and produce signed boot artifacts, complete clean/selected extended disks and documentation. Boot the first generation, repeat the complete build with fresh output/tmp and immutable sources/tools, compare the full inventories, and run matching runtime/regression and trust-chain tests.
This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is Phase 6 and AC1–AC24.
Authority, security and reliability
The guest realm receives explicit source/toolchain reads, scoped output/tmp/execution and finite child/signing routes, with no raw devices, general keys, network, host build RPC or cross-realm control. The external supervisor may record, verify, export authorized outputs and boot VMs; it cannot repair or assemble missing results.
Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel.
Acceptance criteria
inventory, resource/timeout policy and exact build command in a reviewed runbook. Fix all
prerequisites before declaring the timed demonstration started.
source-only inputs. Use an empty output tree and no prior EriX object, incremental, image,
generated-metadata or host tool cache.
mounted authority inventory and tool versions; disable networking and host
shared-directory/build-RPC fallbacks.
compile/link/generate/sign/package step as an EriX process with exact input/output evidence
and actual exit status.
loader, clean dev/release disks, selected extended disks and generated
documentation/manifests. Compare inventory cardinality and hashes; a missing target or
substituted prebuilt output fails the demonstration.
tool/authority-negative tests on that graph; preserve zero-warning full logs.
artifacts/evidence through an explicitly authorized path. The host may record, independently
verify and boot them, but may not repair or assemble a missing build output.
runtime probes; boot the guest-built extended-dev image for the second-generation build.
Record exact booted image hashes.
empty output/tmp trees, then perform a second complete build without importing
first-generation compiled EriX artifacts or mutable caches.
bytes/signatures using the fixed inputs. Investigate every difference; normalization is
allowed only for fields explicitly specified before the run, never to erase unexplained
payload differences.
guest-built artifacts. The external supervisor may start test VMs; nested virtualization
inside EriX is not required and must not conceal a host-side build step.
device/raw-block/key/network/global discovery and no cross-realm control; test denied access,
interrupted build and complete realm teardown.
apply the predeclared budgets; close proven bottlenecks through reviewed fixes and a new
complete evidence cohort, not partial retries to green.
licenses/recipes, commands, full logs, profile summaries, negative tests, output
hashes/signatures, boot/test results and independent review.
signed boot image and all rootfs authority/code objects. Exercise tampering/revocation
failures before declaring the guest-built result accepted.
native boot/hash tools, and verify ttyd#1's independent TTY/default-clear behavior, vtty
switching, mouse selection/paste, boot logo and help/man/extop acceptance on the newly
produced images.
For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates.
Alternatives and tradeoffs
The running seed or first-generation OS and required libc/runtime are inventoried compiled execution substrates, not reusable target objects. Every EriX-authored product and native packaging helper is rebuilt in each generation. The imported compiler and its required Rust/LLVM/C/C++ runtime closure must first be built from source for EriX against its libc/sysroot, as tracked in the EriX-hosted toolchain issue. That initial toolchain may be cross-built on Linux. The extended development image must also rebuild that upstream Rust/LLVM toolchain inside EriX using the supplied offline recipes and dependencies, validate the resulting tools and runtime linkage, and use the guest-built compiler for at least one of the two complete EriX builds. No unrecorded porting changes, downloads, Linux executables or host-side build delegation may fill a missing guest step.
Tracking and rollout
Dependencies: integration#6, integration#1, integration#2, docs#1, integration#3, lib-posixabi#1, posixd#1, posixd#2, kernel#1, posixd#3, lib-cstd#1, dynlinkd#1, exsh#1, integration#4, integration#7, integration#8, meta#2, integration#5, bootloader#1, ttyd#1
Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use
feature/posix-compat, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection.Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.
[FEATURE] [P16] Demonstrate two complete generations of EriX built inside EriXto [FEATURE] Demonstrate two complete generations of EriX built inside EriXerikinkinen referenced this issue2026-09-12 10:21:05 +02:00