EriX Integration Repository

integration is the cross-repository system integration and VM validation repository for EriX.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

Technical requirements are tracked in the EriX requirements, conventions, and project documentation.

See:

• docs for design documents, specifications, and development plans.
• Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.

Purpose of This Repository

This repository implements the EriX integration harness. Its purpose in EriX is to prove cross-repository system behavior in deterministic appliance and VM scenarios.

Functionally, it builds component sets, generates test media, runs scenarios, and checks expected markers and artifacts. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• assemble component revisions into runnable system images
• generate deterministic test media and VM scenarios
• verify cross-component behavior, authority failures, and persistence checks

Clean-Room Policy

EriX follows a strict clean-room philosophy:

• No external source code may be copied.
• No external Rust crates are allowed.
• No code generation tools that embed third-party code.
• All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.

This repository follows the project roadmap and the validation rules documented in its own roadmap.

Deterministic VM Test Contract (Current)

Scenario-driven VM tests are grouped as:

• full-system normal run
• subsystem positive run
• subsystem negative run
• targeted scenario groups under tests/scenario-groups, including fs-compliance-matrix for the cross-filesystem compliance matrix smoke gate, fs-cross-api for the expanded VFS rename/truncate/symlink/readlink, hard-link denial, and metadata-update verifier and fat-metadata for focused FAT32 timestamp/attribute stat and mutation checks and exfat-metadata for focused exFAT primary-entry timestamp/attribute stat and mutation checks and exfat-entry-types for focused exFAT Volume Label/GUID, benign vendor, TexFAT padding, and malformed entry-type checks and exfat-rename for focused exFAT file and empty-directory replacement checks with host fsck.exfat and fat-truncate for FAT12/FAT16/FAT32 truncate shrink/grow media checks and ext-links for ext2/ext3/ext4 symlink, hard-link, and special-inode metadata verification and ext-rename for ext2/ext3/ext4 rename, overwrite, directory-move, and HTree rename verification and ext-truncate for ext2/ext3/ext4 regular-file truncate shrink/grow media checks and ext-sparse for ext4 write-past-EOF sparse-hole and truncate-hole media checks and ext-metadata for ext2/ext3/ext4 inode metadata stat and mutation media checks and ext-oversized-geometry for fail-closed ext2/ext3/ext4 media outside the current 4 KiB block / 512-byte inode provider envelope and ext-advanced-corpus-maintenance for advanced ext corpus maintenance across fast-commit indexed directories, sparse/unwritten extents, metadata mutation checks, legacy fscrypt v1, fsverity built-in signature policy, and oversized-geometry rejection and ext-xattr-policy for ext2/ext4 xattr and POSIX ACL preservation plus malformed xattr fail-closed checks with mandatory host debugfs/e2fsck -fn and optional getfattr/getfacl projection when FUSE is available and vfs-memory-provider-rename for the memory-provider ABI and startup-peer rename path

Runtime and appliance scenarios also forbid the direct ERIX_DRV_SERIAL:PROVIDER_REGISTERED driver debug marker; the public serial readiness surface in dev/runtime fixture boots is ERIX_DEVICED:READY:DRV_SERIAL, and dev runtime framebuffer output receives the configured ERIX_DEVICED:READY:* driver startup set through logd's fbcond-only mirror path. Release runtime images suppress every ready stamp except final ERIX_ROOTD:READY.

The Phase 4.7 loader contract scenario is subsystem-phase4-loader-contract-positive. It runs only the new memory-VFS based contract proof, requires ERIX_ROOTD:READY:LOADER_CONTRACT, and does not replace older Phase 4 filesystem scenarios.

The Phase 4.7 loader ELF-plan scenario is subsystem-phase4-loader-elf-plan-positive. It runs only the focused block-backed loader path, requires ERIX_ROOTD:READY:LOADER_ELF_PLAN, and keeps older VM scenario groups out of the local validation path.

The Phase 4.7 loader process-handoff scenario is subsystem-phase4-loader-process-handoff-positive. It runs only the focused block-backed loader path, requires ERIX_LOADERD:LOAD_SUCCESS, ERIX_LOADERD:LAUNCH_SUCCESS, and ERIX_ROOTD:READY:LOADER_PROCESS_HANDOFF, and skips older VM scenario groups for local validation.

The Phase 4.7 loader materialized-launch scenario is subsystem-phase4-loader-materialized-launch-positive. It uses the same focused block-backed mode but expects the disk /data/bin/loader-ok and /data/bin/loader-alt ELF bytes to be transferred into procd-created child images and to exit through the native process-exit syscall with distinct file-specific markers. The same scenario requires a changed-source executable fixture to fail before a process id is returned.

The Phase 4.7 loader cleanup-authority scenario is subsystem-phase4-loader-cleanup-authority-positive. It runs only the focused cleanup and authority regression path, requires materialization success, cleanup-failure markers for each injected partial state, authority-denial markers for unwanted provider/block/key/journal/peer/scratch/caller authority, and ERIX_ROOTD:READY:LOADER_CLEANUP_AUTHORITY.

The Phase 4.7 loader closure group is phase4-loader-closure. It runs only the focused filesystem-discovery, ELF-plan, materialized-launch, and cleanup-authority scenarios needed to prove Phase 4.7 AC11 through AC13 without running older broad VM groups.

The Phase 4.7 boot/image integration group is phase4-loader-boot-image-integration. It covers the runtime features.program_loader toggle, optional omission with the same VFS/storage stack, and the appliance disk-image path that installs a disk-loadable native loader fixture under /bin.

All scenario classes execute as full-system VM boots. The default full-system scenario now validates core multi-service bootstrap smoke (bootloader -> kernel -> rootd -> {memd,vspaced,pagerd,procd} contract checks). CI runs ./scripts/run-scenarios.sh without an explicit scenario list, so every committed tests/scenarios/*.toml file runs on every CI trigger.

Filesystem Compliance and Strict Gate

scripts/fs_compliance_matrix.py is the checked cross-filesystem status matrix. It records FAT12, FAT16, FAT32, VFAT, exFAT, ext2, ext3, and ext4 rows as read-write, read-only, rejected, obsolete-rejected, or planned, and links accepted states to unit tests, deterministic media, host producer tools, host verification tools, and VM scenarios. Negative media is grouped by malformed feature bits, metadata checksums, geometry, allocation accounting, directory entries, journal state, and bitmap state. Operation probes are checked alongside the status matrix. They record the current provider result for mount, open/create, read/write, directory, rename, truncate, symlink/readlink, hard-link, metadata-update, unlink/rmdir, and xattr surfaces for each FAT/exFAT/ext format. The matrix checker rejects rows that advertise a mutable operation while the current provider path is explicitly denied, and it documents preservation-only or permanent non-goal surfaces without adding new provider authority.

tests/fs-compliance-matrix.sh remains available as a local matrix-drift diagnostic without running a VM. In an integration-only checkout, cross-repo evidence is resolved from out/components/<repo> after scripts/clone-components.sh; in a monorepo checkout, sibling repos such as ../fatd and ../e2fsd are used directly. CI relies on the focused fs-compliance-matrix VM scenario group instead of running the standalone matrix checker as a separate gate. scripts/fs-strict-validation.sh is the local strict filesystem slice gate: it runs the ext feature-registry and ext interoperability checkers, then runs cargo fmt --all -- --check, cargo clippy --all-targets -- -D warnings, and cargo test --all-targets for the filesystem Rust repos, and finally runs the focused fs-compliance-matrix VM scenario group unless ERIX_FS_STRICT_SKIP_VM=1 is set.

Scenario schema includes rootd bring-up controls:

• kernel_rootd_test (none|smoke|runtime)
• rootd_test_mode (none|smoke|force-fail|phase0-*|phase1-*|phase2-*|phase3-*|phase4-*)
  • in current implementation this is translated into a generated BootConfig payload (out/fixtures/boot-config.bin) instead of selecting rootd launch arrays at compile-time
  • phase4-loader-contract selects validation profile 26 and the same memory-provider/vfsd service stack as phase4-vfs-memory
• runtime_config_profile (dev|release)
  • selects runtime.<profile>.toml at integration repo root
• runtime_config_path (optional, relative to integration root or absolute)
  • explicit runtime TOML override for scenario/appliance builds
  • if omitted and runtime.local.toml exists, it is used
  • otherwise runtime.<profile>.toml is used
  • features.program_loader=true adds loaderd behind the Phase 4.7 runtime toggle, requires VFS plus ext-backed storage, and selects phase4-loader-fs for automatic block-storage fixture media
• block_storage_image (auto|none|gpt|malformed-gpt|phase4-fs|phase4-loader-fs|phase4-fs-ext2|phase4-fs-ext2-indirect|phase4-fs-ext2-compat|phase4-fs-ext2-xattr|phase4-fs-ext2-geometry-512|phase4-fs-ext2-links|phase4-fs-ext2-rename|phase4-fs-ext2-corpus-1k|phase4-fs-ext2-corpus-2k|phase4-fs-ext2-corpus-4k|phase4-fs-ext3|phase4-fs-ext3-replay|phase4-fs-ext3-external-journal|phase4-fs-ext3-jbd2-legacy|phase4-fs-ext3-jbd2-csum-v2|phase4-fs-ext3-jbd2-csum-v3|phase4-fs-ext3-many-journal|phase4-fs-ext3-fast-commit|phase4-fs-ext3-htree|phase4-fs-ext3-htree-depth0|phase4-fs-ext3-htree-depth1|phase4-fs-ext3-geometry-512|phase4-fs-ext3-links|phase4-fs-ext3-rename|phase4-fs-ext4-metadata|phase4-fs-ext4-extent-tree|phase4-fs-ext4-bigalloc|phase4-fs-ext4-meta-bg|phase4-fs-ext4-stable-resize|phase4-fs-ext4-xattr|phase4-fs-ext4-quota|phase4-fs-ext4-orphan-list|phase4-fs-ext4-orphan-file|phase4-fs-ext4-mmp|phase4-fs-ext4-large-dir|phase4-fs-ext4-encrypted|phase4-fs-ext4-encrypted-casefold|phase4-fs-ext4-casefold|phase4-fs-ext4-inline|phase4-fs-ext4-verity|phase4-fs-ext4-verity-salted|phase4-fs-ext4-verity-large|phase4-fs-ext4-shared-blocks|phase4-fs-ext4-geometry-512|phase4-fs-ext4-links|phase4-fs-ext4-rename|phase4-fs-fat12|phase4-fs-fat12-metadata|phase4-fs-fat16|phase4-fs-fat16-metadata|phase4-fs-fat32-primary-only|phase4-fs-fat32-mirrored|phase4-fs-fat32-active-fat|phase4-fs-fat32-metadata-clean|phase4-fs-fat32-directory-metadata|phase4-fs-fat32-metadata-set|phase4-fs-fat32-short-name|phase4-fs-fat32-rename|phase4-fs-fat32-vfat-unicode|phase4-fs-fat32-stress|phase4-fs-exfat|phase4-fs-exfat-boot-region|phase4-fs-exfat-stale-backup|phase4-fs-exfat-one-fat|phase4-fs-exfat-active-fat|phase4-fs-exfat-unicode|phase4-fs-exfat-contiguous|phase4-fs-exfat-stream-metadata|phase4-fs-exfat-metadata|phase4-fs-exfat-entry-types|phase4-fs-exfat-rename|phase4-fs-exfat-corpus|malformed-fat|malformed-exfat|exfat-bad-upcase-table|exfat-bad-name-hash|exfat-duplicate-upcase-name|exfat-malformed-utf16-name|exfat-bad-main-boot|exfat-bad-backup-boot|exfat-bad-extended-boot|exfat-boot-region-mismatch|exfat-dirty-volume|exfat-media-failure|exfat-invalid-active-fat|exfat-reserved-volume-flags|exfat-duplicate-bitmap-entry|exfat-duplicate-upcase-entry|exfat-bad-bitmap-entry|exfat-bad-bitmap-length|exfat-corrupt-directory-set|exfat-bad-entry-type|exfat-bitmap-fat-mismatch|exfat-duplicate-cluster|exfat-no-fat-missing-bitmap|exfat-leaked-cluster|exfat-chain-loop|exfat-out-of-range-chain|exfat-invalid-valid-data|malformed-ext|ext2-oversized-block|ext3-oversized-block|ext4-oversized-inode|ext2-bad-block-map|ext2-bad-dirent|ext2-bad-inode-size|ext2-bad-bitmap|ext2-reserved-inode-corruption|ext-needs-recovery|fat-mirror-mismatch|fat-cluster-loop|fat-bad-lfn|fat-bad-lfn-ordinal|fat-orphan-lfn|fat-duplicate-alias|fat-short-leading-e5|fat-oem-short-name|fat-invalid-nt-flags|fat-ambiguous-lfn-alias|fat-bad-cluster-chain|fat-file-chain-loop|fat-cross-linked-files|fat-out-of-range-chain|fat32-bad-fsinfo-count|fat32-bad-backup-boot|fat32-dirty-metadata|fat32-hard-error-metadata|fat32-bad-reserved-entry|ext-checksum-failure|ext-unsupported-feature|ext-obsolete-feature-corpus|ext-unknown-feature-corpus|ext-unknown-feature-gap-corpus|ext-readonly-feature|ext-shared-blocks-feature|ext-journal-device-volume|ext-bigalloc-bad-bitmap|ext4-meta-bg-bad-descriptor|ext4-encrypted-missing-key|ext4-encrypted-wrong-key|ext4-encrypted-casefold-missing-key|ext4-encrypted-casefold-wrong-key|ext4-bad-fscrypt-policy|ext4-bad-encrypted-casefold-policy|ext4-bad-encrypted-casefold-name|ext4-bad-casefold-encoding|ext4-bad-casefold-name|ext4-bad-xattr|ext4-bad-quota|ext4-bad-orphan-list|ext4-bad-orphan-file|ext4-bad-mmp-active|ext4-bad-mmp-checksum|ext4-bad-inline-data|ext4-bad-verity-data|ext4-bad-verity-algorithm|ext4-bad-verity-signature|ext4-verity-signature|ext4-verity-encrypted|ext4-bad-verity-merkle|ext-external-journal|ext-jbd2-unknown-feature|ext-jbd2-csum-failure|ext-fast-commit-mutating|ext-fast-commit-htree|ext-fast-commit-linear|ext-fast-commit-bad-tail|ext-external-journal-uuid-mismatch|ext-external-journal-misroute|ext-malformed-extent|ext-malformed-htree|ext-malformed-htree-index|ext-malformed-htree-deep)
  • auto attaches the deterministic GPT disk only when features.user_storage=true and features.storage_virtio=true
  • non-none variants attach a secondary raw modern-only virtio-blk disk to QEMU (virtio-blk-pci,disable-legacy=on) in read-only mode so the deterministic fixture cannot be rewritten during negative-path boots
  • phase4-fs builds a GPT disk with erix-esp FAT32 and erix-data ext4 partitions; phase4-loader-fs adds two executable /data/bin ELFs with distinct byte fingerprints and exit markers plus a changed-source ELF used to prove stale materialization fails before process start; host-side scenario verification checks those fingerprints are present only in the filesystem executable fixtures and absent from boot image service modules; phase4-fs-ext2 and phase4-fs-ext3 use clean ext2/ext3 data partitions for legacy provider coverage; phase4-fs-ext2-indirect adds a host-generated ext2 large-file corpus that crosses the direct-block boundary and verifies a VFS-created block-stride probe file after shutdown; phase4-fs-ext2-compat carries dir_prealloc, imagic_inodes, ext_attr, and resize_inode for ext2 compatibility safety coverage; phase4-fs-ext2-xattr adds user xattr and POSIX ACL payloads and verifies host debugfs plus e2fsck -fn xattr/ACL preservation after VM mutation, with getfattr/getfacl projection when FUSE is available; phase4-fs-ext2-geometry-512 keeps ext2 at the supported 4 KiB block limit while validating 512-byte inode tables and inline xattr preservation; phase4-fs-ext2-corpus-1k, phase4-fs-ext2-corpus-2k, and phase4-fs-ext2-corpus-4k broaden ext2 coverage with varied block/inode geometry, sparse superblocks, non-default blocks-per-group, grown directories, and sparse triple-indirect host files; ext2-oversized-block keeps >4 KiB block geometry fail-closed; ext2-bad-block-map, ext2-bad-dirent, ext2-bad-inode-size, ext2-bad-bitmap, and ext2-reserved-inode-corruption provide fail-closed malformed ext2 media; phase4-fs-ext3-replay, phase4-fs-ext3-external-journal, phase4-fs-ext3-jbd2-legacy, phase4-fs-ext3-jbd2-csum-v2, phase4-fs-ext3-jbd2-csum-v3, phase4-fs-ext3-many-journal, phase4-fs-ext3-fast-commit, ext-fast-commit-mutating, ext-fast-commit-htree, ext-fast-commit-linear, ext-fast-commit-bad-tail, phase4-fs-ext3-htree, phase4-fs-ext3-htree-depth0, phase4-fs-ext3-htree-depth1, and phase4-fs-ext3-geometry-512 exercise recovery-required replay, explicit external-journal mapping, legacy and CRC32C checksum-v2/v3 JBD2 dialect validation, journal-ring replay without a fixed transaction-count cap, split provider-originated journaled writeback, ordered-data large writes, fast-commit no-delta validation, supported multi-segment mutating-delta replay, indexed-directory and multi-block linear dentry replay, and bad-tail fast-commit fail-closed media; ext3-oversized-block keeps journaled >4 KiB block geometry fail-closed; indexed-directory ext3 mutation coverage; ext-malformed-htree-index and ext-malformed-htree-deep keep malformed index layouts and non-large_dir depth-2 HTree metadata fail-closed; these malformed fixtures keep scenario-local QEMU timeouts because they must prove public mount exposure before the focused malformed-directory operation fails; ext-external-journal, ext-journal-device-volume, ext-external-journal-uuid-mismatch, and ext-external-journal-misroute cover fail-closed missing mapping, standalone journal-device, UUID, and BootConfig mapping failures; phase4-fs-ext4-metadata adds metadata checksums and a host-built indexed HTree directory; phase4-fs-ext4-extent-tree fragments free space so VFS-created large files spill into indexed extent leaf blocks and are checked after shutdown; the focused ext sparse scenario reuses that media to prove write-past-EOF gaps stay unmapped with host debugfs bmap and clean e2fsck -fn; phase4-fs-ext4-bigalloc uses e2fsprogs bigalloc media to prove cluster bitmap and free-count accounting, while ext-bigalloc-bad-bitmap flips a free cluster bit without fixing counters so mount validation fails closed; phase4-fs-ext4-meta-bg uses e2fsprogs meta_bg descriptor placement with non-default blocks-per-group, and ext4-meta-bg-bad-descriptor corrupts s_first_meta_bg so e2fsd rejects impossible descriptor layout; phase4-fs-ext4-stable-resize carries stable_inodes plus resize_inode media so VM mutation, host e2fsck -fn, and generator checks cover stable inode mutation safety and resize-reserved metadata preservation; phase4-fs-ext4-xattr carries metadata-checksummed external xattr blocks, inline inode-body xattr metadata, a large user xattr, and a POSIX ACL, verifies preservation with host debugfs plus e2fsck -fn, projects getfattr/getfacl checks when FUSE is available, while ext4-bad-xattr corrupts the external xattr checksum for fail-closed validation; phase4-fs-ext4-quota carries user/group/project quota metadata and a PROJINHERIT directory, while ext4-bad-quota corrupts quota metadata for fail-closed validation; phase4-fs-ext4-orphan-list and phase4-fs-ext4-orphan-file carry recoverable legacy and orphan-file orphan state, while ext4-bad-orphan-list and ext4-bad-orphan-file cover fail-closed corrupt orphan metadata; phase4-fs-ext4-mmp carries clean metadata-checksummed MMP media, while ext4-bad-mmp-active and ext4-bad-mmp-checksum prove active and malformed MMP state fail closed; phase4-fs-ext4-large-dir carries ext4 large_dir media with a depth-2 HTree for VFS marker insertion and host debugfs/e2fsck -fn checks; phase4-fs-ext4-encrypted carries an fscrypt v2 encrypted host marker unlocked only through keyd startup material, while ext4-encrypted-missing-key, ext4-encrypted-wrong-key, and ext4-bad-fscrypt-policy prove missing material, mismatched material, and malformed policy modes fail closed; ext4-fscrypt-v1-policy, ext4-fscrypt-hctr2-policy, ext4-fscrypt-direct-key-policy, and ext4-fscrypt-data-unit-policy prove explicit non-goal fscrypt policies fail closed before key lookup; phase4-fs-ext4-encrypted-casefold carries an encrypted case-insensitive directory that is unlocked through keyd and verified by lookup plus readdir, while ext4-encrypted-casefold-missing-key, ext4-encrypted-casefold-wrong-key, ext4-bad-encrypted-casefold-policy, and ext4-bad-encrypted-casefold-name prove missing material, mismatched material, malformed policy metadata, and malformed encrypted names fail closed; phase4-fs-ext4-casefold carries host-created UTF-8 casefold directories with root-level folded lookup and indexed /htree mutation, while ext4-bad-casefold-encoding and ext4-bad-casefold-name prove unsupported encodings and malformed normalized names fail closed; phase4-fs-ext4-inline carries ext4 inline-data files and directories, verifies inline host and VFS markers with debugfs plus e2fsck -fn, and ext4-bad-inline-data proves malformed inline payloads fail closed; phase4-fs-ext4-verity carries a read-only Linux-layout fsverity host marker unlocked through a private keyd trust root, phase4-fs-ext4-verity-salted adds descriptor salt coverage, and ext4-bad-verity-data, ext4-bad-verity-algorithm, ext4-bad-verity-signature, ext4-verity-signature, ext4-verity-encrypted, and ext4-bad-verity-merkle prove fail-closed data, algorithm, malformed PKCS#7, unsupported signature-policy, encrypted verity, and Merkle-tree tamper rejection; phase4-fs-ext4-shared-blocks carries shared-block ext4 media with a depth-2 HTree and uses rootd's read-only profile for host-marker traversal, while ext-shared-blocks-feature proves read-write mount denial; phase4-fs-ext4-geometry-512 carries 4 KiB blocks and 512-byte inodes with metadata checksums, extents, an internal journal, indexed directories, inode-body xattrs, and inline-data payloads; ext4-oversized-inode keeps 1024-byte inode records rejected until the provider envelope grows; phase4-fs-ext2-links, phase4-fs-ext3-links, and phase4-fs-ext4-links carry host-created fast and block-backed symlinks, regular-file hard links, and FIFO/character/block special inode metadata; the ext-links group verifies readlink/stat/link-count behavior and proves special-file metadata does not imply openable device authority; phase4-fs-ext2-rename, phase4-fs-ext3-rename, and phase4-fs-ext4-rename carry host-created rename fixtures for same-directory moves, cross-directory moves, compatible overwrite, directory .. repair, special metadata entries, and indexed HTree entries; the ext-rename group verifies the public VFS-visible results and leaves the media clean for host e2fsck -fn; phase4-fs-fat12, phase4-fs-fat12-metadata, phase4-fs-fat16, phase4-fs-fat16-metadata, phase4-fs-fat32-primary-only, phase4-fs-fat32-mirrored, phase4-fs-fat32-active-fat, phase4-fs-fat32-metadata-clean, phase4-fs-fat32-directory-metadata, phase4-fs-fat32-metadata-set, phase4-fs-fat32-short-name, phase4-fs-fat32-rename, phase4-fs-fat32-vfat-unicode, phase4-fs-fat32-stress, phase4-fs-exfat, phase4-fs-exfat-boot-region, phase4-fs-exfat-stale-backup, phase4-fs-exfat-one-fat, phase4-fs-exfat-active-fat, phase4-fs-exfat-unicode, phase4-fs-exfat-contiguous, phase4-fs-exfat-stream-metadata, phase4-fs-exfat-metadata, phase4-fs-exfat-entry-types, phase4-fs-exfat-rename, and phase4-fs-exfat-corpus vary ESP media geometry, FAT32 extended-BPB policy, FAT32 reserved-entry state, FAT directory-entry metadata, VFAT Unicode/dense-alias entries, fragmented FAT allocation, grown directories, sparse-looking payloads, free-slot reuse, exFAT main/backup boot-region checksum policy, exFAT active-FAT/volume-state policy, exFAT upcase-table Unicode NameHash policy, exFAT no-FAT-chain allocation policy, exFAT ValidDataLength zero-fill behavior, and fragmented exFAT streams, plus 1 KiB exFAT clusters, two FATs, dual allocation bitmaps, a grown root chain, fragmented host data, deep Unicode-heavy paths, and spare allocation clusters for public VFS mutations while keeping the same clean ext4 data partition and phase4 marker flow; active-FAT media uses a direct FAT divergence check because dosfstools repairs the intentionally inactive FAT copy even when ExtFlags selects FAT 1; ext-obsolete-feature-corpus sets all obsolete ext feature bits rejected by e2fsd, ext-unknown-feature-corpus sets high future compat, incompat, and ro-compat bits, and ext-unknown-feature-gap-corpus sets currently undefined feature-bit gaps so negative VM scenarios prove fail-closed mount behavior before VFS state is exposed; phase4-e2fs-fat positives set qemu_block_readonly=false to exercise writable mount requests; phase4-e2fs-fat-readonly positives attach writable QEMU media but pass the VFS read-only mount flag for /data
  • malformed-gpt corrupts the primary GPT header CRC and entry array after CRCs are written so phase4 fail-closed negatives stay deterministic
  • malformed FAT/ext variants derive from the filesystem disk and corrupt provider-specific media, including FAT mirror mismatch, FAT cluster loops, bad VFAT LFN entries, duplicate short aliases, bad referenced FAT chains, cross-linked files, out-of-range FAT links, inconsistent FSInfo counts, malformed exFAT upcase metadata, bad exFAT NameHash entries, duplicate exFAT upcase-equivalent names, malformed exFAT UTF-16 names, bitmap/FAT mismatches, duplicate exFAT cluster ownership, missing no-FAT-chain bitmap coverage, leaked clusters, exFAT chain loops, out-of-range exFAT starts, ext checksum- required media, unsupported/obsolete/unknown ext features, external journal metadata, standalone journal-device volumes, external-journal UUID/mapping failures, unknown JBD2 feature bits, JBD2 checksum failures, bad fast-commit tails and mixed/indexed/linear fast-commit replay after full commits, malformed extents, malformed HTree metadata, malformed ext4 casefold metadata, and malformed inline-data metadata
• qemu_block_readonly (true|false)
  • defaults to true for existing block-storage scenarios
  • set to false only when a scenario intentionally validates writable media
• disk_image_case (no-virtio-sata|single-virtio-junk-sata|single-virtio-esp-raw-sata|single-virtio-gpt|two-virtio-disks)
  • used with run_mode=vm-disk-image to boot the packaged .img through QEMU and validate SATA/virtio storage topology behavior
• phase0_missing_service (none|memd|vspaced|pagerd|procd|phase0-probe|named|timed|logd|crashd|irqd|deviced|probed|hotplugd|drv-acpi|drv-serial|drv-virtio-block|seriald|blockd|fbcond|console-font|drv-i8042|drv-ps2-keyboard|drv-ps2-mouse|inputd|ramfsd|keyd|e2fsd|fatd|vfsd|phase1-lookup|phase1-time|phase2-irq|phase2-driver-hold|phase2-driver-capcheck)
  • in phase4-e2fs-fat, missing-provider negatives prove the specific absent provider blocks VFS exposure; the missing-FAT-provider case still expects E2FSD readiness because rootd starts the ext provider first
• service_primary_control_fault (none|probed-omit-primary-control|probed-misroute-primary-control|drv-acpi-omit-primary-control|drv-acpi-misroute-primary-control|drv-serial-omit-primary-control|drv-serial-misroute-primary-control|drv-i8042-omit-primary-control|drv-i8042-misroute-primary-control)
  • integration-only authority-shape override for staged service startup
  • used to prove fail-closed behavior when a narrow primary-control endpoint is omitted or replaced with the wrong endpoint family
• service_explicit_endpoint_fault (none|deviced-misroute-pci-config-endpoint|deviced-misroute-pci-device-endpoint)
  • integration-only wrong-kind auxiliary endpoint override for staged service startup
  • used to prove fail-closed validation of explicit endpoint source-slot and endpoint-kind contracts outside the primary control slot
• service_startup_peer_fault (none|probed-omit-deviced-peer|probed-misroute-deviced-peer|probed-inject-undeclared-peer|inputd-omit-deviced-peer|inputd-misroute-deviced-peer|drv-serial-omit-deviced-peer|drv-serial-misroute-deviced-peer|vfsd-omit-memory-provider-peer|vfsd-misroute-memory-provider-peer|e2fsd-omit-blockd-peer|e2fsd-misroute-blockd-peer|e2fsd-omit-keyd-peer|e2fsd-misroute-keyd-peer|fatd-omit-blockd-peer|fatd-misroute-blockd-peer|vfsd-omit-e2fsd-peer|vfsd-misroute-e2fsd-peer|vfsd-omit-fatd-peer|vfsd-misroute-fatd-peer)
  • integration-only startup-peer override for split delegated peers
  • used to prove fail-closed rejection of omitted, misrouted, or undeclared startup peers for both root-launched and deviced-launched consumers
  • project requirements: probed-* -> rootd_test_mode=phase2-probe, inputd-* -> rootd_test_mode=phase3-input, drv-serial-* -> rootd_test_mode=phase3-serial, vfsd-omit-memory-provider-peer|vfsd-misroute-memory-provider-peer -> rootd_test_mode=phase4-vfs-memory, and e2fsd-*|fatd-*|vfsd-*-e2fsd-peer|vfsd-*-fatd-peer -> rootd_test_mode=phase4-e2fs-fat
  • the omitted memory-provider peer case may still require VFSD readiness as precursor evidence, but it must forbid VFS_MOUNT and VFS_IO
• per-service build modes:
  • memd_test_mode, vspaced_test_mode, pagerd_test_mode, procd_test_mode, named_test_mode, timed_test_mode, logd_test_mode, crashd_test_mode, irqd_test_mode, deviced_test_mode, probed_test_mode, hotplugd_test_mode, drv_acpi_test_mode, drv_serial_test_mode, drv_virtio_block_test_mode, seriald_test_mode, blockd_test_mode, fbcond_test_mode, drv_i8042_test_mode, drv_ps2_keyboard_test_mode, drv_ps2_mouse_test_mode, inputd_test_mode
  • values: none|runtime|smoke|serial-probe|force-fail (serial-probe currently applies to drv_serial_test_mode)

Runtime policy:

• kernel_rootd_test=runtime is bootstrap-only bring-up driven by generated BootConfig from runtime TOML, with validation_profile=none.
• runtime VM scenarios opt into RUNTIME_IMAGE_TEST_HARNESS=1 so QEMU exits classed success/failure without enabling smoke-only service feature gates.
• runtime/appliance kernel builds enable kernel-runtime-image; packaged dev and release artifacts leave RUNTIME_IMAGE_TEST_HARNESS=0 so kernel-rootd-smoke-test and integration debug-exit code are not included.
• runtime/appliance rootd builds keep diagnostic chatter quiet as well: ERIX_ROOTD:TRACE:*, late VFS verifier probes, and focused test-marker mutation paths are reserved for integration smoke runs and must stay out of ordinary runtime/appliance serial output.
• runtime mode must not rely on synthetic probe/client workflows.
• when features.user_storage=true and features.storage_virtio=true, the harness generates a deterministic GPT disk image locally and attaches it as a secondary raw modern-only virtio-blk disk for both subsystem and appliance runs.
• disk-image VM scenarios boot the built GPT appliance image directly and cover no virtio disk, junk virtio media, raw ESP-only virtio media, a single virtio GPT boot image, and a two-virtio-disk topology.
• storage-capable VM runners default to QEMU_MEMORY=1G, keeping the current DMA window rooted at 0x2000_0000 inside guest RAM for virtio queue/data buffers; callers can still override QEMU_MEMORY explicitly when needed.
• smoke/negative matrices remain unchanged and continue to use integration smoke features.
• smoke/negative matrices keep mode knobs as fixture-generation inputs and feed rootd through BootConfig payloads.
• rootd_test_mode=phase0-stress-1k stays on the normal narrowed runtime endpoint inventory. Its leak-bound assertions use SNAPSHOT_RESOURCE_COUNTS over the dedicated process endpoint and do not inject kernel-rootd-test-root-endpoint.
• runtime TOML also controls filesystem composition: user_vfs=true|false adds or removes the public vfsd service, while fs_ramfs, fs_e2fs, and fs_fat select the private filesystem providers that may be delegated to it. fs_e2fs also includes private keyd, which is required for ext fscrypt authority.
  • [[mounts]] rows are encoded into the generated BootConfig mount table and decide the runtime namespace layout independently of provider selection
  • runtime/appliance validation proves configured filesystem bring-up through ERIX_ROOTD:READY:VFSD, ERIX_ROOTD:READY:VFS_MOUNT, and ERIX_ROOTD:READY:VFS_IO; provider-ready markers appear only for selected providers
  • runtime BootConfig mount scenarios use provider-neutral basic VFS I/O, so FAT-root coverage does not require symlink/readlink or POSIX metadata semantics that FAT providers intentionally deny

Current integration checks consume these marker families:

• ERIX_BOOTLOADER:* (bootloader startup and failure markers)
• ERIX_KERNEL:* and ERIX_KERNEL_STUB:* (kernel bring-up/test markers)
• ERIX_KRN:* (kernel library/runtime diagnostics)

Rootd smoke negatives now assert the specific reported failure class when available:

• ERIX_KERNEL:ROOTD_SMOKE:CONTRACT_INVALID
• ERIX_KERNEL:ROOTD_SMOKE:INTERNAL_ERROR
• ERIX_KERNEL:ROOTD_SMOKE:SERVICE_FAIL

The generic ERIX_KERNEL:ROOTD_SMOKE:FAIL marker is reserved for unknown or legacy rootd failure reports.

The phase0-force-service-fail negative path now forces failure from rootd's real post-START_PROCESS startup handshake and requires ERIX_ROOTD:DBG:POST_START_CLEANUP_OK so the VM suite proves that the started child was torn down before exit class 0x14 is reported.

Phase0-positive scenarios now assert staged rootd progress markers in order:

• ERIX_KERNEL:ROOTD_STAGE:INTAKE_VALIDATED
• ERIX_KERNEL:ROOTD_STAGE:MODULES_DISCOVERED
• ERIX_KERNEL:ROOTD_STAGE:MEMD_READY
• ERIX_KERNEL:ROOTD_STAGE:VSPACED_READY
• ERIX_KERNEL:ROOTD_STAGE:PAGERD_READY
• ERIX_KERNEL:ROOTD_STAGE:PROCD_READY
• ERIX_KERNEL:ROOTD_STAGE:SERVICES_READY
• ERIX_KERNEL:ROOTD_STAGE:PROBE_SPAWN_REQUESTED
• ERIX_KERNEL:ROOTD_STAGE:PROBE_SPAWNED
• ERIX_KERNEL:PHASE0:FAULT_NOTIFY_SENT
• ERIX_KERNEL:PHASE0:FAULT_RESOLVED
• ERIX_KERNEL:ROOTD_STAGE:PROBE_EVENT_RECEIVED
• ERIX_KERNEL:ROOTD_STAGE:PROBE_COMPLETED

Phase1-time scenarios additionally assert:

• ERIX_KERNEL:ROOTD_STAGE:TIMED_READY
• ERIX_KERNEL:ROOTD_STAGE:TIME_READY

Phase3-framebuffer scenarios additionally assert framebuffer continuity contracts and enforce fail-closed behavior when the console-font blob is missing.

Phase3-input scenarios additionally assert deterministic input stack staging:

• ERIX_DEVICED:READY:DRV_I8042
• ERIX_DEVICED:READY:DRV_PS2_KEYBOARD
• ERIX_DEVICED:READY:DRV_PS2_MOUSE
• ERIX_KERNEL:ROOTD_STAGE:INPUTD_READY
• ERIX_KERNEL:ROOTD_STAGE:INPUT_ROUTING_READY
• ERIX_KERNEL:ROOTD_STAGE:CONSOLE_INPUT_READY

Current unwanted-explicit-authority negatives additionally cover:

• wrong-kind auxiliary explicit endpoint transfer into deviced
• wrong-kind PCI-device/MMIO explicit endpoint transfer into deviced
• root-launched split startup-peer misroutes such as inputd -> deviced
• deviced-launched split startup-peer misroutes such as drv-serial -> deviced
• phase-scoped startup-peer harness validation so phase2/phase3 delegated-peer negatives run under the matching rootd bring-up mode instead of being misclassified as probe-only

EXT-CROSS validation is tracked by a repository-local manifest:

• scripts/check-ext-cross-corpus.py compares the e2fsd feature registry against scripts/ext_cross_corpus.py, verifies that every accepted feature has focused positive VM coverage, checks malformed-media negatives for fail-closed VFS exposure, pins authority-negative scenarios, and enforces the 1k LoC boundary on near-limit ext media modules.
• scripts/check-fs-compliance-matrix.py also validates the advanced ext corpus rows in scripts/ext_cross_corpus.py, requiring implemented, planned, rejected, obsolete-rejected, and permanent non-goal classes to carry VM scenarios, unit evidence, and documentation links before the matrix can pass.
• scripts/check-ext-interoperability-corpus.py validates the Linux/e2fsprogs ext interoperability matrix in scripts/ext_interop_corpus.py. The matrix links each ext2/ext3/ext4 corpus image to the feature bits it proves, required host tools, malformed companions, and provider-mutation VM scenarios.
• tests/ext-cross-corpus.sh is the unit-style entrypoint for the manifest check.
• tests/ext-interoperability-corpus.sh is the unit-style entrypoint for the interoperability matrix check.
• tests/scenario-groups/ext-cross-*.txt groups the focused VM subsets for feature positives, feature-registry negatives, malformed ext media, and authority regressions; tests/scenario-groups/ext-interoperability-corpus.txt groups the focused ext2/ext3/ext4 Linux/e2fsprogs corpus VM subset; tests/scenario-groups/vfs-memory-provider-rename.txt groups the renamed volatile-memory provider VFS scenarios; tests/scenario-groups/fat-01.txt groups the targeted FAT32 extended-BPB media scenarios, and tests/scenario-groups/fat-02.txt groups FAT32 reserved-entry, dirty-state, and hard-error-state scenarios. tests/scenario-groups/fat-03.txt groups FAT12/FAT16/FAT32 directory metadata scenarios. tests/scenario-groups/fat-04.txt groups the VFAT Unicode/dense-alias positive scenario plus malformed ordinal, orphan-chain, and duplicate-alias fail-closed scenarios. tests/scenario-groups/fat-short-name.txt groups lowercase short-entry NT-flag positive media plus short-byte, OEM-byte, NT-flag, ambiguous-LFN, and duplicate-alias fail-closed scenarios. Its positive scenario uses rootd_test_mode=phase4-e2fs-fat-short-name to keep the VM path focused on the new verifier while preserving the real block-backed VFS stack. tests/scenario-groups/fat-rename.txt groups the focused FAT32 rename replacement scenario. It uses rootd_test_mode=phase4-e2fs-fat-rename, then verifies file-over-file replacement, empty directory replacement, rejected incompatible replacements, and clean host fsck.fat media. tests/scenario-groups/fat-metadata.txt groups the focused FAT32 metadata scenario. It uses rootd_test_mode=phase4-e2fs-fat-metadata, then verifies host-created timestamp stat fields, explicit VFS atime/mtime/fs_flags mutation, read-only denial, and clean host fsck.fat media. tests/scenario-groups/exfat-metadata.txt groups the focused exFAT metadata scenario. It uses rootd_test_mode=phase4-e2fs-fat-exfat-metadata, then verifies host-created primary-entry timestamps, UTC offsets, attribute stat fields, explicit VFS atime/mtime/fs_flags mutation, read-only denial, and clean host fsck.exfat/dump.exfat media. tests/scenario-groups/ext-truncate.txt groups the focused ext2/ext3/ext4 regular-file truncate scenarios. It uses rootd_test_mode=phase4-e2fs-fat-ext-truncate, then verifies public VFS shrink/grow behavior and clean host debugfs/e2fsck -fn media. tests/scenario-groups/ext-sparse.txt groups the focused ext4 sparse-hole scenario. It uses rootd_test_mode=phase4-e2fs-fat-ext-sparse, then verifies write-past-EOF holes, sparse truncate tail trimming, host debugfs bmap allocation state, and clean e2fsck -fn media. tests/scenario-groups/ext-fscrypt-policy.txt groups focused ext4 fscrypt policy negatives for v1 descriptor access, AES-256-HCTR2, direct-key, and non-default data-unit-size media. tests/scenario-groups/ext-metadata.txt groups the focused ext2/ext3/ext4 inode metadata scenarios. It uses rootd_test_mode=phase4-e2fs-fat-ext-metadata, then verifies public VFS mode, owner, atime, mtime, and filesystem flag updates, immutable denial, and clean host debugfs/stat/e2fsck -fn media. tests/scenario-groups/exfat-entry-types.txt groups the exFAT Volume Label/GUID, TexFAT padding, and benign vendor-entry positive media plus an unsupported vendor-allocation entry-set negative. tests/scenario-groups/exfat-rename.txt groups the focused exFAT rename replacement scenario. It uses rootd_test_mode=phase4-e2fs-fat-rename, then verifies file-over-file replacement, empty directory replacement, rejected incompatible replacements, clean host fsck.exfat media, and direct parser checks for removed source names. tests/scenario-groups/exfat-percent.txt groups primary percent-in-use refresh media and a patched partial-update dirty-volume negative. tests/scenario-groups/fat-05.txt groups allocation-stress media, tests/scenario-groups/exfat-03.txt groups exFAT upcase-table Unicode lookup plus bad-NameHash, duplicate-upcase-name, and malformed-UTF16 fail-closed media, and tests/scenario-groups/exfat-04.txt groups exFAT allocation reconciliation positive and fail-closed media. tests/scenario-groups/exfat-05.txt groups sparse-valid-data/fragmented-stream exFAT media and invalid valid-data fail-closed media. tests/scenario-groups/exfat-06.txt groups the broadened exFAT interoperability corpus and root-metadata fail-closed media. tests/scenario-groups/ext-geometry.txt groups the targeted ext2/ext3/ext4 512-byte-inode VM media, tests/scenario-groups/ext-oversized-geometry.txt groups oversized ext2/ext3 block and ext4 inode fail-closed media, tests/scenario-groups/ext-links.txt groups the ext2/ext3/ext4 symlink, hard-link, and special-inode metadata VM media, and tests/scenario-groups/ext-rename.txt groups the ext2/ext3/ext4 rename and directory-move VM media. tests/scenario-groups/ext-truncate.txt groups focused ext2/ext3/ext4 regular-file truncate VM media, and tests/scenario-groups/ext-sparse.txt groups focused ext4 sparse-hole VM media. tests/scenario-groups/ext-fscrypt-policy.txt groups focused ext4 fscrypt policy fail-closed VM media, and tests/scenario-groups/ext-verity-signature-policy.txt groups focused ext4 fsverity built-in signature, missing/wrong-root, and encrypted-verity fail-closed VM media. tests/scenario-groups/phase4-loader-fs-discovery.txt groups the focused Phase 4.7 loader filesystem-discovery scenario using rootd_test_mode=phase4-loader-fs-discovery and phase4-loader-fs media. tests/scenario-groups/phase4-loader-elf-plan.txt groups the focused Phase 4.7 loader ELF-plan scenario using the same rootd mode and media, but asserts the dedicated ERIX_ROOTD:READY:LOADER_ELF_PLAN proof marker. tests/scenario-groups/phase4-loader-process-handoff.txt groups the focused Phase 4.7 loader process-handoff scenario using the same rootd mode and media, but asserts ERIX_LOADERD:LOAD_SUCCESS, ERIX_LOADERD:LAUNCH_SUCCESS, and ERIX_ROOTD:READY:LOADER_PROCESS_HANDOFF. tests/scenario-groups/phase4-loader-materialized-launch.txt groups the Phase 4.7.9 materialized-launch scenario using the same rootd mode and media, but treats two distinct successful child exits plus stale-source rejection and host fixture fingerprint inspection as evidence that filesystem bytes, not a boot-module summary, executed. tests/scenario-groups/phase4-loader-cleanup-authority.txt groups the Phase 4.7.10 cleanup-authority scenario using the same media while asserting only the new cleanup and authority-denial marker family. tests/scenario-groups/phase4-loader-closure.txt groups the final Phase 4.7 closure evidence set: VFS policy, malformed ELF/load-plan rejection, true filesystem-byte execution, stale-source rejection, cleanup, and authority denial. tests/scenario-groups/phase4-loader-boot-image-integration.txt groups the Phase 4.7 boot/image scenarios for runtime loader enablement, optional omission, and appliance disk-image fixture packaging.
• scripts/run-scenario-group.sh <group> runs only a named scenario group, so cross-cutting work can validate new VM coverage without invoking the older full scenario matrix locally.

Phase4 storage scenarios now additionally cover:

• positive block bring-up through blockd
• positive GPT partition publication through blockd
• missing drv-virtio-block
• missing blockd
• malformed GPT media
• wrong-kind deviced PCI-device/MMIO authority
• runtime disk-image topology coverage for SATA boot without virtio storage, junk virtio media, ESP-only virtio media, a single GPT virtio boot disk, and two virtio disks

Current exit-code class mapping:

• 0x10: success
• 0x11: bootloader failure
• 0x12: kernel failure
• 0x13: rootd failure
• 0x14: service bootstrap failure

Repository Layout (Current)

integration/
├── components.toml
├── cargo-repos.toml
├── scripts/
│   ├── clone-components.sh
│   ├── build-all.sh
│   ├── build-kernel-fixture.sh
│   ├── generate-monorepo-cargo-config.py
│   ├── setup-component-ci-overrides.sh
│   ├── setup-component-ci-overrides.py
│   ├── generate-boot-config.py
│   ├── parse-runtime-config.py
│   ├── check-ext-cross-corpus.py
│   ├── ext_cross_corpus.py
│   ├── run-scenario.sh
│   ├── run-scenario-group.sh
│   ├── run-scenarios.sh
│   ├── run-vm.sh
│   ├── run-bootloader-vm.sh
│   ├── run-disk-image-vm.sh
│   ├── run-kernel-exception-negative-tests.sh
│   ├── package-appliance.sh
│   ├── build-disk-image.sh
│   ├── publish-release-artifacts.sh
│   ├── assert-markers.sh
│   ├── lib/scenario.sh
│   └── lib/components.sh
├── tests/
│   ├── generate-monorepo-cargo-config.sh
│   ├── ext-cross-corpus.sh
│   ├── scenario-groups/*.txt
│   └── scenarios/*.toml
├── runtime.sample.toml
├── runtime.dev.toml
├── runtime.release.toml
├── .github/workflows/ci.yml
├── README.md
├── ARCHITECTURE.md
└── ROADMAP.md

Quick Start

From integration/:

./scripts/clone-components.sh
./scripts/build-all.sh
./scripts/run-scenarios.sh
./scripts/run-scenario.sh tests/scenarios/full-system-normal.toml
./tests/ext-cross-corpus.sh
./scripts/run-scenario-group.sh ext-cross-feature-registry
./scripts/run-scenario-group.sh fat-truncate
./tests/generate-monorepo-cargo-config.sh
./scripts/package-appliance.sh
./scripts/build-disk-image.sh
APPLIANCE_NAME=erix-release RUNTIME_CONFIG_PROFILE=release ./scripts/package-appliance.sh
./scripts/build-disk-image.sh erix-release
PUBLISH_DRY_RUN=1 ./scripts/publish-release-artifacts.sh
./scripts/setup-component-ci-overrides.sh /path/to/component feature/example

To bootstrap the full multi-repository checkout into the current directory without first cloning integration, fetch the standalone clone script and pipe it to sh:

base=https://git.erikinkinen.fi/erix/integration/raw/branch/main
curl "$base/scripts/bootstrap-repos.sh" | sh

The script fetches the current components.toml and cargo-repos.toml catalogs, then clones missing repositories from https://git.erikinkinen.fi/erix/${repo}.git. Existing clean repositories are updated with git pull --ff-only; dirty repositories are skipped. To clone missing repositories over SSH instead:

base=https://git.erikinkinen.fi/erix/integration/raw/branch/main
curl "$base/scripts/bootstrap-repos.sh" | sh -s -- --ssh

build-kernel-fixture.sh now generates and injects a required boot-config section payload for rootd orchestration.

Runtime appliance defaults:

• KERNEL_ROOTD_TEST=runtime
• RUNTIME_IMAGE_TEST_HARNESS=0
• RUNTIME_CONFIG_PROFILE=dev
• ROOTD_TEST_MODE=none (runtime image composition is config-driven, not phase-mode-driven)

Runtime config files:

• runtime.dev.toml (default dev profile)
• runtime.release.toml (default release profile)
• runtime.sample.toml (schema + documented behavior)
• runtime.local.toml (local override, gitignored)
• committed dev/release defaults mount / from ext on erix-data, /boot from FAT on erix-esp, and /tmp from ramfs
• features.program_loader is the Phase 4.7 loader toggle. The dev profile enables it and packages loaderd plus the loader executable fixture path; the release profile leaves it disabled by default.

Phase4 storage helpers:

• scripts/generate-block-test-disk.py builds deterministic gpt, malformed-gpt, phase4-fs, FAT12/FAT16/FAT32/exFAT ESP variants, exFAT boot-region, active-state, percent-in-use, and upcase-name positive/negative variants, malformed FAT/exFAT/ext, ext recovery-required, encrypted ext4, casefold ext4, inline-data ext4, and Linux-layout fsverity ext4 raw disks locally. CI installs the host fsverity package alongside e2fsprogs/exfatprogs so fsverity media coverage has the expected host tooling available. tests/generate-block-test-disk.sh checks GPT CRC corruption, FAT12/FAT16 marker readability, deterministic exFAT marker readability via scripts/verify-exfat-image.py, malformed-media variant generation, and host fsck.fat -n / fsck.exfat -n / e2fsck -fn on the filesystem fixture. FAT32 active-FAT VM verification uses scripts/verify-fat32-active-fat.py after mutation so valid inactive-FAT divergence is not normalized away. exFAT active-FAT VM verification uses scripts/verify-exfat-image.py because the installed fsck.exfat rejects two-FAT TexFAT-style images even though the fixture is intentionally exercising the provider's active-selector policy. EXFAT-03 Unicode-name VM verification also uses scripts/verify-exfat-image.py so upcase-table lookup and stream NameHash semantics are checked with the same deterministic parser. EXFAT-04 VM verification uses the same parser to reconcile all reachable exFAT stream ownership against the allocation bitmap and uses host fsck.exfat -n on the accepted contiguous no-FAT-chain image. EXFAT-05 VM verification checks sparse valid data, DataLength, ValidDataLength, zero-filled ranges, and fragmented stream chains. Focused exFAT metadata VM verification checks host-created primary-entry attributes, create/modify/access timestamps, 10 ms increments, UTC offsets, VFS-updated metadata, and read-only denial, then verifies the ESP with fsck.exfat, dump.exfat, and direct exFAT entry-set checks. Focused ext metadata VM verification checks VFS-updated mode, owner, atime, mtime, nodump/noatime/immutable flags, immutable mutation denial, and the resulting data partition with debugfs, host stat, and e2fsck -fn. Focused ext sparse VM verification checks that a write past EOF reads a zero-filled hole without allocating logical block zero, that the tail block is allocated, that truncating a sparse file keeps the leading hole unmapped, and that the resulting data partition passes e2fsck -fn. exFAT entry-type VM verification checks Volume Label/GUID root metadata, TexFAT padding, preserved vendor-extension secondaries, and fail-closed vendor-allocation media with the direct parser and host exFAT tools. exFAT rename VM verification reuses the public rootd rename flow and checks the resulting ESP with fsck.exfat plus direct payload and absence checks. exFAT percent-in-use VM verification starts from unknown primary/backup percent values, requires the accepted image's primary value to match the allocation bitmap after public VFS mutations, keeps backup stale, and rejects patched dirty partial-update media on read-write mount. EXFAT-06 VM verification uses the same parser to assert 1 KiB clusters, two FATs, a grown root chain, fragmented deep Unicode-path payloads, and spare allocation clusters for public VFS mutations; its negative media rejects bad upcase tables, malformed bitmap entries, duplicate critical metadata entries, and corrupt directory-entry sets before VFS readiness. FAT32 dirty and hard-error metadata variants are negative read-write mount tests; malformed reserved-entry variants keep mirrors consistent so fatd fails specifically on FAT[0]/FAT[1] metadata validation. FAT-04 verifies host mtools listing/lookup for accepted VFAT Unicode and dense-alias fixtures after VM execution and patches malformed LFN/alias fixtures for targeted negative mount failures. FAT short-name verification checks host-created lowercase short entries and VFS-created lowercase short entries with direct NT-flag parsing after VM execution. FAT-05 verifies fragmented cluster chains, multi-cluster directories, slot reuse, sparse-looking payloads, and fail-closed malformed referenced-chain media. EXFAT-03 verifies upcase-table Unicode lookup and bad-NameHash, duplicate-upcase-name, and malformed-UTF16 fail-closed media. EXFAT-04 verifies no-FAT-chain contiguous streams plus bitmap/FAT mismatch, duplicate ownership, missing bitmap allocation, leaked allocation, loop, and out-of-range fail-closed media. FAT12/FAT16/FAT32 directory-metadata variants use scripts/verify-fat-directory-metadata.py plus mtools to verify timestamps, attributes, volume labels, lowercase short-name flags, and VFS-created archive/timestamp metadata after the VM. FAT metadata mutation uses scripts/verify-fat-metadata.py plus mtools and direct directory-entry parsing to verify host-created timestamps, date-only access time, two-second modification time, stat-only creation time, and read-only attributes after the VM. FAT rename replacement uses scripts/verify-fat-rename.py plus mtools and fsck.fat -n to verify the destination file payload, renamed directory child, rejected non-empty destination, and removed source names after the VM. exFAT rename replacement uses scripts/verify-exfat-image.py plus fsck.exfat -n to verify the same public VFS mutations on exFAT media. exFAT percent-in-use media uses the direct parser to verify the final primary percent against the active allocation bitmap while preserving stale backup PercentInUse=0xff. FAT truncate variants use scripts/verify-fat-truncate.py, host mtools, and fsck.fat -n to verify shrink, zero-length shrink, zero-filled growth, released-chain cleanup, and FAT32 FSInfo accounting after the VM. Ext truncate variants use debugfs and e2fsck -fn to verify the focused /data/EXTTRUNC.BIN shrink/grow result after the VM. Ext metadata variants use scripts/verify-ext-metadata.py, host stat, and e2fsck -fn to verify /data/EXTMETA.TXT mode, owner, timestamps, flags, payload, and clean media.
• BLOCK_STORAGE_IMAGE=auto|none|gpt|malformed-gpt|phase4-fs|phase4-loader-fs|phase4-fs-ext2|phase4-fs-ext2-indirect|phase4-fs-ext2-compat|phase4-fs-ext2-xattr|phase4-fs-ext2-geometry-512|phase4-fs-ext2-links|phase4-fs-ext2-rename|phase4-fs-ext2-corpus-1k|phase4-fs-ext2-corpus-2k|phase4-fs-ext2-corpus-4k|phase4-fs-ext3|phase4-fs-ext3-replay|phase4-fs-ext3-external-journal|phase4-fs-ext3-jbd2-legacy|phase4-fs-ext3-jbd2-csum-v2|phase4-fs-ext3-jbd2-csum-v3|phase4-fs-ext3-many-journal|phase4-fs-ext3-fast-commit|phase4-fs-ext3-htree|phase4-fs-ext3-htree-depth0|phase4-fs-ext3-htree-depth1|phase4-fs-ext3-geometry-512|phase4-fs-ext3-links|phase4-fs-ext3-rename|phase4-fs-ext4-metadata|phase4-fs-ext4-extent-tree|phase4-fs-ext4-bigalloc|phase4-fs-ext4-meta-bg|phase4-fs-ext4-stable-resize|phase4-fs-ext4-xattr|phase4-fs-ext4-quota|phase4-fs-ext4-orphan-list|phase4-fs-ext4-orphan-file|phase4-fs-ext4-mmp|phase4-fs-ext4-large-dir|phase4-fs-ext4-encrypted|phase4-fs-ext4-encrypted-casefold|phase4-fs-ext4-casefold|phase4-fs-ext4-inline|phase4-fs-ext4-verity|phase4-fs-ext4-verity-salted|phase4-fs-ext4-verity-large|phase4-fs-ext4-shared-blocks|phase4-fs-ext4-geometry-512|phase4-fs-ext4-links|phase4-fs-ext4-rename|phase4-fs-fat12|phase4-fs-fat12-metadata|phase4-fs-fat16|phase4-fs-fat16-metadata|phase4-fs-fat32-primary-only|phase4-fs-fat32-mirrored|phase4-fs-fat32-active-fat|phase4-fs-fat32-metadata-clean|phase4-fs-fat32-directory-metadata|phase4-fs-fat32-metadata-set|phase4-fs-fat32-rename|phase4-fs-fat32-vfat-unicode|phase4-fs-fat32-stress|phase4-fs-exfat|phase4-fs-exfat-boot-region|phase4-fs-exfat-stale-backup|phase4-fs-exfat-one-fat|phase4-fs-exfat-active-fat|phase4-fs-exfat-unicode|phase4-fs-exfat-contiguous|phase4-fs-exfat-stream-metadata|phase4-fs-exfat-metadata|phase4-fs-exfat-entry-types|phase4-fs-exfat-rename|phase4-fs-exfat-percent|phase4-fs-exfat-corpus|malformed-fat|malformed-exfat|exfat-bad-upcase-table|exfat-bad-name-hash|exfat-duplicate-upcase-name|exfat-malformed-utf16-name|exfat-bad-main-boot|exfat-bad-backup-boot|exfat-bad-extended-boot|exfat-boot-region-mismatch|exfat-dirty-volume|exfat-partial-update-dirty|exfat-media-failure|exfat-invalid-active-fat|exfat-reserved-volume-flags|exfat-duplicate-bitmap-entry|exfat-duplicate-upcase-entry|exfat-bad-bitmap-entry|exfat-bad-bitmap-length|exfat-corrupt-directory-set|exfat-bad-entry-type|exfat-bitmap-fat-mismatch|exfat-duplicate-cluster|exfat-no-fat-missing-bitmap|exfat-leaked-cluster|exfat-chain-loop|exfat-out-of-range-chain|exfat-invalid-valid-data|malformed-ext|ext2-oversized-block|ext3-oversized-block|ext4-oversized-inode|ext2-bad-block-map|ext2-bad-dirent|ext2-bad-inode-size|ext2-bad-bitmap|ext2-reserved-inode-corruption|ext-needs-recovery|fat-mirror-mismatch|fat-cluster-loop|fat-bad-lfn|fat-bad-lfn-ordinal|fat-orphan-lfn|fat-duplicate-alias|fat-bad-cluster-chain|fat-file-chain-loop|fat-cross-linked-files|fat-out-of-range-chain|fat32-bad-fsinfo-count|fat32-bad-backup-boot|fat32-dirty-metadata|fat32-hard-error-metadata|fat32-bad-reserved-entry|ext-checksum-failure|ext-unsupported-feature|ext-obsolete-feature-corpus|ext-unknown-feature-corpus|ext-unknown-feature-gap-corpus|ext-readonly-feature|ext-shared-blocks-feature|ext-journal-device-volume|ext-bigalloc-bad-bitmap|ext4-meta-bg-bad-descriptor|ext4-encrypted-missing-key|ext4-encrypted-wrong-key|ext4-encrypted-casefold-missing-key|ext4-encrypted-casefold-wrong-key|ext4-bad-fscrypt-policy|ext4-bad-encrypted-casefold-policy|ext4-bad-encrypted-casefold-name|ext4-bad-casefold-encoding|ext4-bad-casefold-name|ext4-bad-xattr|ext4-bad-quota|ext4-bad-orphan-list|ext4-bad-orphan-file|ext4-bad-mmp-active|ext4-bad-mmp-checksum|ext4-bad-inline-data|ext4-bad-verity-data|ext4-bad-verity-algorithm|ext4-bad-verity-signature|ext4-verity-signature|ext4-verity-encrypted|ext4-bad-verity-merkle|ext-external-journal|ext-jbd2-unknown-feature|ext-jbd2-csum-failure|ext-fast-commit-mutating|ext-fast-commit-htree|ext-fast-commit-linear|ext-fast-commit-bad-tail|ext-external-journal-uuid-mismatch|ext-external-journal-misroute|ext-malformed-extent|ext-malformed-htree|ext-malformed-htree-index|ext-malformed-htree-deep controls whether a secondary read-only virtio-blk disk is attached during fixture, subsystem, and appliance runs.
• fscrypt scenarios may set keyd_fscrypt_material_id_hex and keyd_fscrypt_material_hex; the harness encodes those bytes in rootd's private keyd startup material tail, not in named or provider metadata.
• fsverity scenarios may set keyd_fsverity_root_id_hex and keyd_fsverity_root_hex; the harness encodes those bytes in the same private keyd startup material tail as trust-root material for e2fsd and selects rootd's targeted fsverity validation profile for positive/tamper media. Linux-layout fsverity coverage is grouped under tests/scenario-groups/ext-verity-linux.txt, while explicit signature and authority-policy negatives are grouped under tests/scenario-groups/ext-verity-signature-policy.txt.
• scripts/build-disk-image.sh builds erix-dev.img and erix-release.img as GPT-partitioned raw disks. Partition 1 is a FAT32 ESP named erix-esp; partition 2 is an empty ext4 filesystem named erix-data.
• CI builds and publishes runtime appliance images after the non-runtime VM suite passes. Runtime appliance VM scenarios remain available for local harness use, but they are not part of the default CI VM gate.
• EXT-CROSS groups live under tests/scenario-groups/; use scripts/run-scenario-group.sh ext-cross-feature-registry for the fail-closed feature-bit subset, ext-cross-feature-positives for accepted feature media, ext-cross-malformed-media for malformed ext fixtures, and ext-cross-authority for authority-shape negatives.
• Use scripts/run-scenario-group.sh ext-advanced-corpus-maintenance for the targeted advanced ext corpus maintenance subset without rerunning older broad VM groups.
• Use scripts/run-scenario-group.sh ext-interoperability-corpus for the targeted Linux/e2fsprogs ext2/ext3/ext4 interoperability subset without running older VM scenarios.

Set RUNTIME_CONFIG_PROFILE=release (or RUNTIME_CONFIG_PATH=...) to select runtime image behavior, and APPLIANCE_NAME to select output artifact prefix.

Monorepo mode:

• set ERIX_COMPONENT_SOURCE=monorepo to build directly from sibling repos
• Cargo sources are patched per build, not globally, so touched repos can share the active local crate graph without unused patch or path-override warnings
• the generated CARGO_HOME also rewrites internal git URLs to local synthetic main mirrors so component manifests can stay on branch = "main" while local validation still follows the active branch
• appliance / VM validation in monorepo mode is expected to remain warning-free

Main outputs:

• out/resolved-revisions.json
• VM serial logs generated by the active harness
• out/appliance/erix-dev.tar.gz
• out/appliance/erix-dev.img
• out/appliance/erix-dev.img.sha256
• out/appliance/erix-dev.img.zst and out/appliance/erix-dev.img.zst.sha256 (when compression is enabled)
• out/appliance/erix-release.tar.gz
• out/appliance/erix-release.img
• out/appliance/erix-release.img.sha256
• out/appliance/erix-release.img.zst and out/appliance/erix-release.img.zst.sha256 (when compression is enabled)

Governance Principles

integration governance is scoped to assembling, building, and validating cross-repository EriX systems.

The scoped governance rules are:

• Scenarios must be deterministic and make component revision selection explicit.
• Generated media and VM tests must fail closed on missing tools, warnings, or authority regressions.
• Branch overrides belong in integration-controlled CI setup, not committed component manifests.
• New system behavior requires targeted positive and negative scenarios before it is considered validated.
• Cross-cutting ext work must update the EXT-CROSS and ext interoperability corpus manifests plus grouped scenario lists in the same branch as feature-registry, authority, or media boundary changes.

Validation Boundaries

• integration may coordinate component builds but does not own component source policy.
• Driver daemons remain managed through deviced and procd; tests should assert that ownership boundary.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

No decisions are considered valid without documented rationale.

Maintainers can be reached via email: admin@erikinkinen.fi.