ARCADIA-Studio/harness/release-linux-validation-options.md

Linux release verification options — 2026-09-06

Latest outcome at 21:53 PDT: the source-6 Linux server built with Rust 1.90 and passed a real-process modular source import/rejection/restart oracle. The full server test build reached its bounded compile timeout before tests executed. QEMU is cleanly stopped; the exact snapshot, binary, logs and cache are preserved. Full Linux tests, desktop/GUI and final packaging remain open. See the final sections for provenance and the next measured gate.

This note records an initial read-only feasibility inspection, subsequent portable QEMU preparation and pilot, and the later user-authorized switch to WSL. The chronological sections distinguish preparation, actual Linux execution, and outstanding release acceptance. No Windows feature/security setting was changed by these investigations.

Observed environment

• Windows 11 Pro, 2 logical CPUs, 8 GiB physical RAM; approximately 3.6 GiB free physical memory at inspection. C: had approximately 29.3 GiB free. D: is the mounted Windows installation DVD, not historical D:/CodexBuilds; that historical directory is absent. Z: is a network/shared-folder drive with approximately 17.7 GiB free, not a suitable assumed local VM/build disk.
• wsl.exe exists but both wsl --status and wsl --list --quiet report that Windows Subsystem for Linux is not installed. No Docker, Podman, QEMU, VirtualBox, Multipass or GitHub CLI executable was found through normal command lookup or their conventional installation directories. No WSL/vmcompute service was found by the bounded service-name query.
• WinHvPlatform.dll exists. A read-only WHvGetCapability(WHvCapabilityCodeHypervisorPresent) query returned HRESULT 0, 4 bytes written and false. The Windows system-information flag HypervisorPresent=true does not establish usable nested acceleration for a new guest. QEMU WHPX should therefore be treated as unavailable now. Microsoft's capability API and QEMU WHPX prerequisites distinguish API availability from the required hypervisor platform.
• Git's bundled SSH executable and 7-Zip are installed. No known Linux remote host is supplied by the current environment; no SSH configurations, credential stores or account sessions were inspected. An SSH client alone is not a remote Linux resource.

Repository routes and one corrected regression

The configured origin is https://gitlab.com/unbleaklessness/ARCADIA-Studio. The tracked CI definition is .github/workflows/ci.yml, with Windows/Ubuntu jobs for fmt, strict clippy, workspace tests, release builds and executable artifacts. There is no tracked .gitlab-ci.yml. The GitHub workflow cannot be assumed to execute on the GitLab origin; no running pipeline or accessible GitHub mirror was established. It also has no interactive Linux desktop acceptance stage, full distribution assembly, restart/deployment probe or final package checksums.

deployment/Dockerfile builds only the server on Rust 1.90/Bookworm and packages it in Debian Bookworm slim; deployment/arcadia-server.service describes a real installed Linux service with a restricted service account. Neither recipe supplies a local Linux kernel or proves deployment. Inspection found that the newly included build/windows_manifest.rs was missing from the Docker source context, even though its runtime body skips Linux. Root corrected this with COPY build ./build. This is a corrected code-inspection finding, not a successful Docker build.

Concrete options

Times and working-disk figures below are planning estimates, not benchmarks. They include this Rust/Iced/WGPU project rather than only the guest OS.

Route	What it can establish	Expected resources / elapsed time	Constraint or risk
Known Linux workstation/VM or authenticated CI runner supplied later	Native Linux builds, tests, MSRV, real HTTP/restart and packages; interactive desktop if a supported display/control route is provided	Typically 10–25 GiB build workspace; 1–4 hours initial automated work on a modest accelerated host, plus acceptance work	No such host/access is currently established. Do not invent endpoints or initiate authentication. CI logs alone do not establish GUI behavior.
User-local QEMU TCG + Ubuntu 24.04 minimal cloud image	A real Linux kernel/userspace executing Linux binaries and tests; a real Linux graphical session with a lightweight desktop and Mesa software Vulkan	About 0.45 GiB initial QEMU installer + image downloads, then guest packages/toolchain/crates. Budget a 20–24 GiB sparse guest disk, 2–3 GiB guest RAM plus 2 GiB guest swap. Provisioning could take 1–3 hours; full cold workspace build/test/release under TCG may take 8–24+ hours and must be measured	No hardware acceleration presently available. CPU emulation plus software Vulkan may make interactive acceptance slow. Remaining Windows RAM/disk is tight; pause heavy Windows builds before starting. This is emulated Linux acceptance, not Linux hardware/GPU-performance evidence.
User-local QEMU TCG + Debian amd64 netinst, lightweight Xfce session	Same real Linux execution categories as above	Netinst downloads only needed packages; roughly 4 GiB OS + Xfce before Rust/build outputs, with the same 20–24 GiB working-disk budget and TCG timing risk	Installer is more interactive than a seeded cloud image. Debian coverage does not replace the repository's documented Ubuntu 24.04 package-runtime claim. Debian requirements, task sizes.
Full Ubuntu Desktop installer under TCG	Ubuntu desktop environment without manually adding a session	Official Ubuntu 24.04 guidance asks for at least 25 GB storage before this project's build workspace	Poor fit for ~29 GiB currently free and 8 GiB total host RAM. Prefer minimal Ubuntu plus only needed GUI/runtime packages. Ubuntu installation guide.
WSL2/WSLg, Docker Desktop, Hyper-V, VirtualBox or WHPX installation	Potentially faster real Linux environments after setup	Likely needs Windows feature/driver installation and possibly reboot; nested virtualization also matters on this already virtualized host	Not a user-local equivalent of portable QEMU TCG, and outside this inspection's allowed actions. The earlier rejected build-tools installer is not authorization to modify these features.
Windows cross-build/MSYS2/Cygwin or downloaded Linux artifacts only	Compilation or artifact inspection	Potentially smaller/faster than a guest, but desktop Linux linking still needs a target sysroot/native dependencies	Does not execute Linux tests, filesystem behavior, service restart or Linux GUI. Cannot close the remaining Linux release gates.

Recommended feasible local pilot

Use a bounded Ubuntu 24.04 minimal QEMU/TCG pilot if no actual Linux host becomes available. This keeps the documented runtime family and avoids system feature changes. Do not commit to a full emulated build before measuring its speed.

1. Obtain a pinned Windows QEMU build from the Windows provider linked by QEMU's download page. The linked Stefan Weil distribution currently lists approximately 197 MB installers and matching SHA-512 files. Prefer extracting the payload under ignored .local with the available 7-Zip, then verify the binaries and firmware are runnable without installer execution; portable extraction has not been tested here. Do not silently substitute an installer requiring elevation if extraction fails.
2. Use Canonical's Ubuntu 24.04 minimal amd64 QCow2 image, currently listed as 252 MB with SHA256SUMS and signatures. Pin the dated release and checksum in the evidence ledger instead of relying on a moving URL. It is a UEFI/GPT bootable disk: configure matching x86 UEFI firmware from the QEMU bundle and an independent writable variables file, and create a separate sparse overlay rather than modify the downloaded base.
3. Seed a fresh guest account using cloud-init NoCloud. A tiny CIDATA ISO/FAT seed is one option; NoCloud also supports SMBIOS configuration with an HTTP seed directory, avoiding a host ISO-building dependency. The seed can contain new disposable guest credentials/keys, never existing user credentials. Keep the seed and source transfer server scoped to a task-specific directory. Use QEMU's unprivileged user-mode networking and loopback-only host forwarding, not TAP/bridges; QEMU documents this backend as requiring no administrator privilege.
4. Start at 2 GiB guest RAM, 1–2 emulated CPUs and -accel tcg; add 2 GiB guest swap. First verify boot, ext4 write/reopen, package networking, Rust installation and one small core compile/test. Record wall time, available host memory and real allocated disk after 30–60 minutes. If the pilot cannot make useful progress without sustained host paging, prefer an actual accelerated Linux host rather than consuming the Windows acceptance environment.
5. Copy a snapshot of the exact source revision plus any explicitly recorded uncommitted patch into the guest filesystem; do not build on the shared Z: drive or use Windows target output as a Linux cache. Build with one Cargo job and incremental compilation disabled if disk pressure requires it; the repository already sets dev debug info to zero. Reserve at least 5 GiB free host disk for Windows, logs and final evidence. Sparse virtual capacity is a maximum, not a guarantee of low physical use; measure growth before each major stage.
6. Provision only required Linux build libraries and a lightweight Xorg/desktop session initially. Add Mesa Vulkan software rendering and inspect vulkaninfo before launching Studio. Mesa documents the software-driver ICD naming, including lvp_icd.x86_64.json, in its installation guide; discover the actual installed path. Set the recorded WGPU/Vulkan environment intentionally. A displayed Linux window must be exercised through the root's permitted GUI-control surface. An Xvfb screenshot or successful process launch is only a smoke test. Add a real Wayland session separately if both display-backend acceptance claims are required.

The milestone output should include Linux kernel/distribution, Rust versions, emulator/CPU/RAM/rendering mode, exact source revision, automated command results, real HTTP/restart results, native workflow evidence, fresh package hashes and known limits. TCG does run the Linux binary on a Linux kernel; it does not justify claims about physical Linux hardware acceleration or performance. No current Linux release gate is closed by this feasibility report.

Preparation completed later on 2026-09-06 — VM not booted

Root authorized download, verification and local extraction after the read-only feasibility pass. All pilot files are in ignored .local/linux-qa; no installer was executed, Windows feature changed or existing credential read. There is no extraction blocker.

Prepared input	Pinned URL / verified result
QEMU Windows payload	https://qemu.weilnetz.de/w64/qemu-w64-setup-20260811.exe, 206,615,928 bytes. SHA-512 matches https://qemu.weilnetz.de/w64/qemu-w64-setup-20260811.sha512: 5bcf9eed634e8575a37b74f445af41a2fe4106da512d0c30c368301d4c105037fdfab40a5287367a28a957624cddebbc8c07e16c88ab6634f554cdf3d16bf543.
Ubuntu disk	https://cloud-images.ubuntu.com/minimal/releases/noble/release-20260905/ubuntu-24.04-minimal-cloudimg-amd64.img, 264,372,224 bytes. SHA-256 matches the same dated directory's SHA256SUMS: 46b0dbaffa6950a7da5ff2dc5ed34c46084610b3b6d1fae8f1ec2d7e953984a3.

These are matches against the published checksum files fetched over HTTPS; no independent OpenPGP signature verification is claimed. QEMU was extracted with the installed 7-Zip into .local/linux-qa/qemu. Its console executable reports 11.1.0 (v11.1.0-12130-ge470268ff4). --version, -display help and qemu-img info exited successfully as the normal user; GTK and SDL display backends are listed. No guest was launched by those probes.

QEMU's x86_64 firmware descriptor specifies share/edk2-x86_64-code.fd (3,653,632 bytes) and share/edk2-i386-vars.fd (540,672 bytes). The latter was copied to the task's independent runtime/uefi-vars.fd. qemu-img info recognizes the downloaded image as clean QCow2, with 3.5 GiB virtual capacity. runtime/pilot.qcow2 is a separate 20 GiB virtual overlay backed by that unchanged image; its initial physical file size is 197,120 bytes. Prepared files occupy approximately 1.61 GiB in total; C: retained approximately 27.4 GiB free at preparation completion. No unrelated caches were removed.

seed/user-data and seed/meta-data configure only the disposable guest account arcadia, its new Ed25519 public key, password-disabled SSH, hostname and no package update/upgrade. The private key exists only under .local/linux-qa/keys; it is not embedded in the seed, report or tracked files. Public-key fingerprint: SHA256:36NIvdOXSeBW4ifQFCqQD6Tgfi6PU0aFc1r+mLA9yCk. The pinned Ubuntu package manifest includes cloud-init and openssh-server, so first-boot SSH does not depend on a package-install command.

serve-seed.cjs binds 127.0.0.1:18080 and serves only /user-data and /meta-data. A brief host-only smoke test verified both responses and 404 rejection of private-key/path-traversal requests; the server then stopped. launch-pilot.cjs syntax and --describe passed. It waits for seed-server readiness, then would launch QEMU with:

• q35, tcg,thread=multi, CPU max, 2 vCPUs and 2 GiB RAM;
• read-only UEFI code, independent writable variables and the 20 GiB overlay;
• Virtio disk/network and user-mode networking with only 127.0.0.1:2222 → guest:22 inbound forwarding;
• NoCloud SMBIOS seed URL http://10.0.2.2:18080/, no monitor listener, serial output to runtime/serial.log, headless display by default;
• hidden helper processes with logs/PIDs confined to runtime; --gui selects GTK when interactive verification is authorized.

The complete resolved argument vector is in .local/linux-qa/ready-command.json. The following command is ready but has not been run; root retains the boot/resource gate while Windows work and the optional existing-Linux-host question are pending:

& 'C:\Users\User\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe' .local/linux-qa/launch-pilot.cjs

After an authorized boot completes, the intended guest connection uses the disposable key and a separate task-local host-key file:

& 'C:\Program Files\Git\usr\bin\ssh.exe' -i .local/linux-qa/keys/guest_ed25519 -p 2222 -o IdentitiesOnly=yes -o UserKnownHostsFile=.local/linux-qa/keys/known_hosts -o StrictHostKeyChecking=accept-new arcadia@127.0.0.1

The key connection, guest boot, cloud-init, network-to-host seed access, guest filesystem growth, Rust build speed and Linux GUI remain untested. No swap or toolchain packages have been provisioned in the guest. Preparation creates a reproducible pilot starting point, not Linux release acceptance.

Bounded QEMU pilot — actual guest execution

Root authorized a headless pilot with one vCPU and 2 GiB RAM, initially bounded to 30 minutes, then allowed one 10-minute recovery extension after network/account setup made useful progress. Processes were hidden; networking remained user-mode NAT with loopback-only host listeners. A task-local watchdog sampled memory/disk every 20 seconds, with stop thresholds of 512 MiB free host RAM and 5 GiB free disk. Concurrent Windows work reached 100% host CPU, so timings below describe a contended two-CPU machine, not an isolated emulator benchmark.

Attempt (2026-09-06 PDT)	Observed result
15:37:47–15:47:10, original headless display	Ubuntu kernel/root filesystem/systemd started, but BOOT/UEFI/ttyS0 device jobs timed out before udev coldplug completed. Numerous framebuffer slow-work warnings. No SSH. Disk and logs retained as runtime/attempt1-*.
15:47:51–15:54:14, fresh overlay with -vga none	Framebuffer warnings disappeared. The same device-job timeouts caused emergency mode; VGA removal alone did not fix startup. Logs and pre-recovery disk retained as runtime/attempt2-*.
From 15:55:03, retained second disk with loopback TCP serial	GRUB automatically retried with initrd after previous initrdless failure. Device jobs still initially timed out. Coldplug, cloud-init network setup and mount recovery eventually completed. SSH with the disposable arcadia key succeeded; cloud-init finished at 16:08:17, about 13m14s after this launch.
16:10:51–16:14:10, after guest timeout adjustment	Relaunched following a clean guest reboot request. Startup reached serial-getty/user sessions without the earlier recorded device timeout at that point. The user then supplied WSL and root directed stopping QEMU; post-reboot SSH/file verification was not completed.

The third attempt established real Linux execution: Ubuntu 24.04.4 LTS, kernel 6.8.0-139-generic, x86_64 under QEMU TCG. cloud-init status --long returned done, errors: [], and recoverable_errors: {} with DataSourceNoCloudNet [seed=dmi,http://10.0.2.2:18080/]. The root filesystem expanded to 19 GiB, with 514 MiB used and 18 GiB available. lsblk confirmed vda15 labeled UEFI mounted on /boot/efi and vda16 labeled BOOT mounted on /boot.

The guest obtained 10.0.2.15 with gateway 10.0.2.2; DNS resolved archive.ubuntu.com. An explicit write, sync, and reread of ~/pilot-check.txt returned the exact arcadia-linux-pilot content. The guest reported 1961 MiB RAM, 281 MiB used, 1679 MiB available and no swap. systemctl --failed listed zero units after bootstrap recovery. No existing credentials were inspected or tried. The maintenance prompt never yielded a root shell; access used only the seeded disposable SSH identity. No package installation, Rust toolchain, source transfer, Cargo build/test, GUI session, or Linux release gate was completed.

To accommodate observed late coldplug under TCG, the authorized guest-only file /etc/systemd/system.conf.d/90-tcg-pilot.conf contains:

[Manager]
DefaultDeviceTimeoutSec=600s
DefaultTimeoutStartSec=600s

systemctl daemon-reload followed by systemctl show confirmed both defaults at 10 minutes. This is an emulator bootstrap allowance, not an application performance relaxation. These settings are supported by systemd 255's documented manager configuration. A clean sudo systemctl reboot completed, after which QEMU exited as configured by -no-reboot. The subsequent cold startup was interrupted by the authorized WSL switch; a fully verified clean reboot remains outstanding.

At the 16:12 resource summary, 91 samples across attempts showed minimum free host memory 2026459136 bytes (1.89 GiB) and minimum free disk 24309592064 bytes (22.64 GiB). The current overlay file length was 36831232 bytes, plus preserved failed-attempt overlays of 7995392 and 6619136 bytes. These are QCow2 file lengths, not the advertised 20 GiB virtual capacity. Windows build output also consumed host disk during the pilot.

All pilot processes were stopped on the WSL switch after verifying their identities: QEMU 9008, seed 8780, launcher 10840, watchdog 1244 and serial client 2544. .local/linux-qa/runtime/guest-timeout-reboot.log, attempt logs, resource samples, saved overlays and task-local known-hosts remain available. The launch helper now uses -vga none and loopback TCP serial 127.0.0.1:4444 with serial logging; serial-console.cjs sends only explicitly written task-local command messages. The watchdog still records this pilot's fixed start/budget and must be assigned a new explicit budget before any future pilot. Do not reuse its expired deadline accidentally.

This experiment does not establish that Linux is unavailable. It established usable Linux SSH/filesystem/network behavior and a concrete boot-timing issue with a guest-only adaptation. If WSL cannot run, the retained booted guest is a valid fallback for a further measured pilot; plan roughly 15–20 minutes for a bounded cold-boot/recovery check before committing to Rust provisioning. Full emulated-build and GUI timings remain unmeasured.

User-installed WSL — distro attempt and pending host restart

The user subsequently reported installing WSL and explicitly authorized creating a Linux test distro. The QEMU pilot was stopped as directed, preserving its disk and evidence. WSL inspection now reports WSL 2.7.13.0, kernel 6.18.33.2-2, WSLg 1.0.73.2, and default version 2. No existing distributions were registered; none were modified. Ubuntu-24.04 is listed by --list --online.

The current runtime is not yet usable: wsl --status reports that WSL2 cannot start because virtualization is unavailable. Read-only component/service checks found VirtualMachinePlatform enabled (CIM InstallState 1), WSL1's optional component disabled (2), WslService running, and no vmcompute or hns service. Component Based Servicing reports RebootPending=true. CPU inventory reports virtualization firmware/extensions/SLAT false while HypervisorPresent is true. These observations do not distinguish an outstanding Windows reboot from every nested-virtualization constraint; complete the pending user-controlled reboot and recheck first. No restart, Windows feature change, service-start override, registry edit, WSL global setting or existing credential access was attempted by the agent.

Prepared the official Ubuntu 24.04.4 WSL image under .local/linux-wsl/ubuntu-24.04.4-wsl-amd64.wsl: 391541571 bytes, SHA-256 9b2f7730dc68227dd04a9f3e5eab86ad85caf556b8606ad94f1f29ff5c4fd3f5, matching the release directory's HTTPS SHA256SUMS. No independent OpenPGP verification is claimed. This is the supported Ubuntu WSL root-filesystem image, not the earlier QEMU QCow2.

The distro-only attempt deliberately avoided an install command that might enable Windows components:

wsl.exe --import ArcadiaLinuxQA `
  C:/Users/User/Documents/Git/ARCADIA-Studio/.local/linux-wsl/ArcadiaLinuxQA `
  C:/Users/User/Documents/Git/ARCADIA-Studio/.local/linux-wsl/ubuntu-24.04.4-wsl-amd64.wsl `
  --version 2

It failed after 524 ms, before registration, with Wsl/Service/RegisterDistro/CreateVm/HCS/HCS_E_SERVICE_NOT_AVAILABLE and a required-feature-unavailable message. A following distro list remained empty; WSL removed the attempted empty install directory. Exact decoded outputs are retained in .local/linux-wsl/{status,version,list,help,import-result,post-import-list}.json. Microsoft documents the distro-import operation and separate platform installation in WSL commands and installation guidance.

There is no WSL guest session, initialized Linux workspace or installed Linux toolchain yet. Host resources after QEMU shutdown and image download were approximately 3.97 GiB free RAM and 21.82 GiB free disk. After the host prerequisite is resolved, recheck wsl --status and wsl --list --verbose; if the task name remains absent, the verified image and .local/linux-wsl/import.cjs can retry the same isolated import without another download. The helper refuses an existing install directory, so inspect any partial state rather than overwriting it.

Once that distro actually starts, create its task-local non-root build account/workspace, provision only the required Rust/native prerequisites, and coordinate source snapshot identity with the Windows owner. Build inside the distro filesystem, not /mnt/c and not the Windows Cargo target. Start with one Cargo job and an isolated Linux target directory; the first proposed check, after prerequisites and source transfer, is CARGO_BUILD_JOBS=1 CARGO_INCREMENTAL=0 cargo test --locked -p oa-core --lib. Measure its wall time, peak memory and disk growth before broad workspace/GUI provisioning. Reserve at least 5 GiB free host disk. WSL installation by itself does not close any Linux build, runtime, GUI or package acceptance gate.

Later QEMU resume and build preparation (in progress)

At 18:46 PDT the read-only WSL status still reported virtualization unavailable and no distributions; Windows last boot remained 10:31:42. No import was retried and no host feature/restart was changed. Root authorized continued work in the retained QEMU guest, with Windows compilation taking priority.

The retained guest restarted at 18:47:16, one vCPU, 2 GiB RAM, BelowNormal Windows process priority, no display, and the same loopback-only networking. Cloud-init completed normally at 18:51:10, guest uptime 222.69 seconds, without the earlier device/emergency failures. SSH verified the retained host identity using the actual first-pilot host-key file runtime/known_hosts (the earlier preparation example's keys/known_hosts was a proposed path). The guest reported zero failed services, 529 MiB used on its 19 GiB root filesystem, and 1701 MiB available RAM. Logs: runtime/resume-ssh-baseline.log, resume-ssh-debug.log, and resume-attempt1-serial.log.

Official Rust bootstrap 1.28.2, from https://static.rust-lang.org/rustup/archive/1.28.2/x86_64-unknown-linux-gnu/rustup-init, was downloaded inside the guest and matched its published .sha256. The official rustup manual-installation method supplies this archive/checksum convention. Its minimal Rust 1.90.0 installation completed and executed rustc 1.90.0 (1159e78c4 2025-09-14) / cargo 1.90.0 (840b83a10 2025-07-30), host x86_64-unknown-linux-gnu, LLVM 20.1.8. The toolchain occupies 587 MiB under /home/arcadia/qa-toolchain/{cargo,rustup}; shell profiles were not modified. The host-fed script ended with an extra CRLF being interpreted as an empty command after those successful checks, so its final shell exit alone is not reported as a clean provisioning result. Future scripts are transferred as files. Log: runtime/resume-rust-provision.log.

An authenticated Ubuntu apt index update fetched 34.2 MB in 2m44s. The build-essential, pkg-config, ca-certificates operation planned 58 new packages, no upgrades/removals, 79.3 MB download and 302 MB added guest disk; package download completed in 34 seconds. Its installation was interrupted as described below and must be repaired/verified before building.

The immutable working-source snapshot at /home/arcadia/qa-source/20260907T015812Z contains 226 files (6.0 MiB), with QA-SNAPSHOT.json recording each file SHA-256 and parent commit 2b2d2bc18bc11ca71ef8c4c5d26610939c1b1f42. It includes current uncommitted source, not only that commit, and is explicitly a core pilot snapshot rather than a final release tree. The 1,450,254-byte archive SHA-256 is db37874f1196315a6de9ea5728ca5012762ca3d5668f903d8da3d6edc60c9b4d, matched after SSH transfer. Task-local generator and manifest: snapshot-source.py, runtime/source-snapshot-summary.json, runtime/source-20260907T015812Z.tar.manifest.json; transfer/extraction log: runtime/source-unpack.log.

Root authorized extending the initial 30-minute experiment after measured progress. During replacement of its initially hardcoded launcher timer, stopping the old launcher also unexpectedly terminated QEMU and the seed helper. This was an unclean task-VM stop, not a successful reboot or resource-threshold stop; neither monitor wrote a threshold-stop record. Rust installation had completed, but apt was unpacking linux-libc-dev. Its logs and the overlay are preserved. The old launcher/VM/seed IDs were 9348/6396/8304. The replacement launcher now reads a live deadline file each sample, avoiding another parent-process handoff. It restarted the same guest at 19:04:59, launcher 8332, QEMU 3100, seed 11088, with an explicitly extended deadline of 20:17:16 PDT and the same 512 MiB free-host-memory / 5 GiB free-host-disk stop thresholds. runtime/resume-budget.json is the active budget; the obsolete external watcher is not the owner of this new VM.

The replacement guest completed cloud-init at 19:07:32 (141.75 seconds guest uptime), again with zero failed units. dpkg --audit precisely identified the interrupted linux-libc-dev unpack and pending configurations. A normal dpkg --configure -a, reinstall of the same cached linux-libc-dev package, and completion of the original apt package set restored a clean audit with exit 0. No packages were removed, no additional package archive download was needed for repair, and no host setting was changed. GCC 13.3.0 and pkg-config 1.8.1 executed successfully. Log: runtime/resume2-dpkg-repair.log.

At 19:13 the actual Linux Rust 1.90 smoke program compiled in 11.042 seconds (7.059 user, 3.016 system) and ran in 0.057 seconds, writing then rereading exact UTF-8 file contents successfully. Log: runtime/linux-rust190-hello2.log; script hello-and-core.sh --hello-only. Bootstrap SHA-256 was recorded as 20a06e644b0d9bd2fbdbfd52d42540bdde820ea7df86e92e533c073da0cdd43c. SSH connection latency is excluded from these internal shell timings; a preceding connection attempt timed out at 45 seconds during package processing and did not execute the test. The successful connection allowed a 120-second handshake for this emulated environment.

With the Windows build lease released, the first actual application-core Linux/MSRV run started at 19:14:03: CARGO_BUILD_JOBS=1 CARGO_INCREMENTAL=0 CARGO_TARGET_DIR=/home/arcadia/qa-target cargo test --locked -p oa-core --lib, inside the immutable source snapshot above. Output streams to runtime/linux-rust190-core-lib.log. This run is in progress; no application test result or graphical acceptance is claimed yet.

A lightweight real-filesystem probe on this guest confirmed the remaining non-Windows publication limitation: ordinary directory rename replaced a competing empty destination created after the preflight, while renameat2(..., RENAME_NOREPLACE) returned EEXIST (17), retaining both the staged source and competing destination. The same no-replace operation successfully published to an absent destination. Log: runtime/linux-rename-probe.log; isolated test script: rename-probe.py. This exercises Ubuntu's current kernel/filesystem, not the application writer. It supports a bounded future cfg(target_os = "linux") publication implementation using no-replace rename, with unsupported syscall/filesystem errors failing closed instead of falling back to overwriting rename. The existing application source was not changed by this QA task. Linux documents the flag and filesystem support in rename(2).

During the core build at 19:21:35 PDT, the guest reported 1537 MiB available RAM, no swap, 2.0 GiB used / 17 GiB available on the 19 GiB root filesystem, and 65 MiB in the isolated Cargo target. Host monitoring at 19:21:20 still showed 1.65 GiB free RAM and 17.28 GiB free disk. Log: runtime/core-build-resources.log. These point samples complement the continuous host samples; they are not a claimed peak-memory measurement.

A transient host-memory dip at 19:22:20 reached 580681728 bytes free (~554 MiB), above the 512 MiB stop threshold. It recovered to 1703440384 bytes on the next 20-second sample; the watchdog did not stop the VM. Root paused concurrent Windows build work. At 19:31:21, main rustc had run 9m34s (8m59 CPU), RSS ~767 MiB, with 887 MiB available guest RAM and an 83 MiB target directory. Host free memory was ~1.00 GiB. The compile was active, with no error yet; continuous resource sampling remains authoritative for the guard.

For the subsequent Linux journal regression, a separately hashed three-file patch (source_files.rs, core manifest, lockfile) was staged in /home/arcadia/qa-source/journal-20260907T022917Z. The patch archive SHA-256 is 3e57dad3be4c3c23b7952500924c41c5b671bcadb0e02a1d49d86f5bfa8f9300. prepare-journal-delta.py verified all 226 original file hashes before copying, checked the exact before/after patch hashes, then verified all 226 final files; the original source snapshot was unchanged. Log: runtime/journal-delta-prepare.log. findmnt confirmed the guest root filesystem is ext4. strace was absent (the final presence check returned 1); root authorized its small guest-only installation after the normal focused tests pass. The ignored injection oracle has not yet been executed and is not counted as passing.

First actual Linux/MSRV core result: PASS. On the original immutable snapshot, cargo test --locked -p oa-core --lib finished its cold dependency/core compilation in 19m15s, then ran 38 tests: 38 passed, 0 failed, 0 ignored, in 14.15 seconds. Total timed Cargo invocation was 1171.450 seconds (980.274 user, 127.817 system), completed at 19:33:37 PDT. The isolated target occupied 86 MiB; the guest filesystem was 2.0 GiB used / 17 GiB available. Exact output: runtime/linux-rust190-core-lib.log. This establishes real Ubuntu/Linux execution of this source snapshot with the declared Rust 1.90.0 minimum; it does not establish all integration tests, desktop/server build, GUI, packaging, other architectures/libcs/filesystems, or a final-release source revision. Some platform-independent retry tests simulate Windows error codes; they do not exercise the Windows API on Linux.

The authorized focused run against the separate Linux journal delta started after this result: cargo test --locked -p oa-core --lib linux_journal_publication. Log: runtime/linux-journal-focused.log. Normal cases and the explicitly ignored injected-error oracle are reported separately; no new result is claimed until this run completes.

Patched Linux journal result: PASS. The exact delta compiled with Rust 1.90 in 8m20s; its four normal focused tests passed in 1.19 seconds (one explicitly ignored fault oracle). Total timed focused Cargo run was 504.145 seconds. Cargo's JSON artifact output identified /home/arcadia/qa-target/debug/deps/oa_core-44b2b37bea4366c0; this same binary then ran 42 normal library tests, all passed, with the injection oracle still ignored, in 19.28 seconds. This includes the existing interrupted-save, version-1/version-2 recovery and external-write preservation cases using the new Linux publication path.

After those normal passes, Ubuntu installed strace 6.8 and its libunwind8 dependency: 639 kB fetched, 2345 kB added, no upgrades/removals, 17.694 seconds, clean dpkg --audit. The ignored full-save oracle was then explicitly executed and passed three separate times, injecting ENOSYS (38), EINVAL (22) and EOPNOTSUPP (95) at the actual renameat2(..., RENAME_NOREPLACE) syscall. Each run asserted the exact error and journal path, unchanged source bytes/expectations, no ownership transfer, no source replacements, and no pending journal. Raw traces contain the corresponding (INJECTED) kernel-call result. This is executed fault-injection evidence, not a skipped test counted as passing. Timed test-body results were 0.62, 0.48 and 0.45 seconds.

Logs: runtime/linux-journal-focused.log, runtime/linux-journal-all-and-injection.log, runtime/journal-injection-{ENOSYS,EINVAL,EOPNOTSUPP}.strace, plus the Cargo artifact JSON and binary-path record. The reviewed source_files.rs SHA-256 is 669491dbddb8e8e6556161426dffa1a49ac1c826d31020bff0956d81a4d84683; the exact delta manifest records the core manifest and lockfile hashes too. These results cover Ubuntu 24.04.4, x86_64, glibc 2.39 and ext4; they do not establish every Linux architecture/libc/filesystem, crash/power-loss durability, model-file compare-and-swap, or a complete release build.

At completion (19:45:13 PDT), guest available RAM was 1645 MiB, root filesystem 2.0 GiB used / 17 GiB available, and isolated Cargo target 117 MiB. Root approved a clean guest poweroff after preserving these traces to release its retained host memory for Windows checks. Source snapshots, disposable identity, Rust toolchain, package state and compiled target remain on the retained overlay for the next measured Linux gate.

Clean stop and resource release: sync; sudo systemctl poweroff was issued at 19:47:03 PDT. The serial log reached poweroff.target and reboot: Power down; QEMU 3100, launcher 8332 and seed 11088 were all absent at the subsequent check. At 19:48:15, host free RAM was 4542193664 bytes (4.23 GiB) and free disk 18560270336 bytes (17.29 GiB). Logs: runtime/resume-clean-poweroff.log, runtime/serial.log, runtime/post-poweroff-resources.json. Windows heavy-build ownership was released only after this confirmation.

Exact resumption and next measured gate

The VM is stopped. Before a later authorized run, confirm no existing task VM/seed is running and coordinate the Windows build lease. The old deadline is historical; assign a new explicit budget. This launches only the retained task-local guest and keeps the process hidden:

$linuxQaDir = (Resolve-Path '.local/linux-qa').Path
$linuxQaNode = 'C:\Users\User\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe'
$linuxQaStamp = Get-Date -Format 'yyyyMMddTHHmmss'
$linuxQaBudget = @{ deadline_utc = [DateTime]::UtcNow.AddMinutes(90).ToString('o'); reason = 'Authorized next measured Linux gate' } | ConvertTo-Json
[IO.File]::WriteAllText((Join-Path $linuxQaDir 'runtime/resume-budget.json'), $linuxQaBudget, [Text.UTF8Encoding]::new($false))
Start-Process -FilePath $linuxQaNode -ArgumentList ('"{0}"' -f (Join-Path $linuxQaDir 'launch-pilot.cjs')) -WorkingDirectory $linuxQaDir -WindowStyle Hidden -RedirectStandardOutput (Join-Path $linuxQaDir "runtime/$linuxQaStamp-launch.log") -RedirectStandardError (Join-Path $linuxQaDir "runtime/$linuxQaStamp-launch-error.log")

Read the newly written runtime/pids.json; use only those verified task identities. SSH remains loopback 127.0.0.1:2222, user arcadia, identity keys/guest_ed25519, known-host file runtime/known_hosts, with IdentitiesOnly=yes, StrictHostKeyChecking=yes, BatchMode=yes, and a 120-second connect allowance. Preserve the one-vCPU/two-GiB settings and the existing 512 MiB free-host-memory / 5 GiB free-host-disk guards. Do not kill the launcher to extend time: adjust the live budget JSON before its deadline. Stop cleanly through the guest after active work finishes.

The next useful build gate is the headless Linux server, followed separately by HTTP/runtime tests. The guest already has its compiler prerequisites; unlike the desktop, this target does not first require graphical libraries. On a freshly verified source snapshot, retain the existing custom Rust/Cargo homes and target, one build job and no incremental compilation. A bounded proposed first command is:

export RUSTUP_HOME=/home/arcadia/qa-toolchain/rustup
export CARGO_HOME=/home/arcadia/qa-toolchain/cargo
export PATH="$CARGO_HOME/bin:$PATH"
export CARGO_BUILD_JOBS=1 CARGO_INCREMENTAL=0
export CARGO_TARGET_DIR=/home/arcadia/qa-target
# cd to the explicitly verified next source snapshot first.
time timeout --signal=INT --kill-after=120s 50m cargo build --locked -p oa-server --bin arcadia-server

The 50-minute bound is an experiment budget, not a predicted successful server-build duration. Current measurements are a 19m15s cold core build and 8m20s core rebuild; additional server dependency cost is unmeasured. Allow up to 10 minutes for the observed 2.5–4-minute cold boot plus SSH, inspect compile/resource progress after 20 minutes, and reserve time for clean shutdown before the 90-minute watchdog. If the bounded command times out, retain its completed dependency cache and replan from the measured stage. No server command above has yet been run. Desktop compilation/GUI need a separate package and graphics-session plan and a fresh budget; a headless build alone cannot accept native Linux UI behavior. WSL remains awaiting the user-controlled restart, and its import must not be repeated before that prerequisite changes.

The final serial shutdown log was copied to runtime/resume-final-20260907T024703Z-serial.log so a later boot cannot replace this evidence. runtime/linux-validation-log-hashes.json records SHA-256 for the focused/all-unit logs and each injected syscall trace.

Linux server/MSRV gate — next immutable snapshot

Root authorized the next headless application gate after the Windows Home-hook checks released their resource lease. Prelaunch at 20:33 PDT: 3.93 GiB free host RAM, 16.57 GiB free disk, no active QEMU/Cargo/rustc processes. The retained guest started at 20:33:36 PDT with QEMU PID10880, launcher8652 and seed10696, one vCPU, 2 GiB RAM, BelowNormal priority and the same loopback-only networking. The live budget ends 22:03:35 PDT. The task-local launcher now requests sync; sudo systemctl poweroff over the disposable SSH connection with a 180-second deadline reserve or upon the existing memory/disk threshold; if the guest does not exit in that reserve, a recorded forced task-VM stop remains the fallback. Launcher JavaScript syntax was checked before launch. No Windows setting or WSL import was changed.

The first SSH attempt expired during boot and a second encountered startup connection reset. The next connection succeeded at 20:37:13; cloud-init subsequently reported done, no errors or recoverable errors, dpkg --audit was clean, and systemctl --failed listed no failed units. Guest root is ext4, 2.0 GiB used / 17 GiB available; guest available memory before the build was 1720 MiB. Boot logs are runtime/server-boot-baseline{,2,3}.log and the current serial log.

The snapshot server-20260907T033312Z includes 281 files: current core/server/desktop source, build helpers, all documentation (including the server's embedded OpenAPI file), source-6 teaching project and Home-hook code/tests. Its archive is 1,739,164 bytes, SHA-256 394197749a01afe5a6e911f0ad4594bfef034c0da4cdc7ffd96454354a51c5c6. Parent commit is 2b2d2bc18bc11ca71ef8c4c5d26610939c1b1f42; the per-file manifest records the actual uncommitted bytes, so this is not falsely described as that clean commit. The guest verified the archive and all 281 file hashes before compiling. Working-tree teaching corrections made after this snapshot are deliberately excluded and need separate acceptance; no snapshot was mutated mid-build.

Actual command started 20:39:56 PDT in /home/arcadia/qa-source/server-20260907T033312Z using the preserved /home/arcadia/qa-toolchain/{cargo,rustup}, Rust 1.90.0, and /home/arcadia/qa-target: CARGO_BUILD_JOBS=1 CARGO_INCREMENTAL=0 timeout --signal=INT --kill-after=120s 50m cargo build --locked -p oa-server --bin arcadia-server. Source-verifying driver SHA-256: 3a81194092dd4b65585ebf3aae02bf7928815664a213bbb5039f7901d9a75936. Logs: runtime/server-source-unpack.log, runtime/linux-rust190-server-build.log, continuous resume-resource-samples.jsonl. This command is in progress at this entry; no server build, HTTP, full integration, GUI or release-package result is claimed yet.

At 20:57 the Linux server dependencies had compiled and oa-core was compiling. Guest available RAM was 1565 MiB; the target occupied 213 MiB. Root requested a brief Windows verification slice. After checking Cargo PID 754's working directory and dedicated PGID 753, only that guest timeout/Cargo/rustc group received SIGSTOP at 20:58:02, then SIGCONT at 21:01:26 after Windows completion: 3m24s paused. T/Tl and subsequent S/Rl/Sl process states were captured in server-build-scoped-{pause,resume}.log. The timeout retains its original wallclock budget (including the pause); the source snapshot is unchanged. During this overlap, free host RAM briefly reached 949800960 bytes (~906 MiB), above the 512 MiB floor, then recovered; no watchdog stop occurred. At 21:01:37 it was 2.11 GiB free with 15.79 GiB free disk. These elapsed compile timings include real emulation and this explicit scheduling pause, not physical Linux performance.

Linux server build PASS: Cargo completed at 21:14:44 PDT, exit 0, reporting 34m42s; the timed command was 2083.938 seconds (1585.444 user, 215.920 system), including the scheduling pause. The Linux target occupied 355 MiB, guest available RAM 1619 MiB, root filesystem 2.3 GiB used / 17 GiB available. The real executable /home/arcadia/qa-target/debug/arcadia-server --version returned 0.2.0 under the Ubuntu guest.

Real server process / HTTP / restart oracle PASS: the task-local Python standard-library driver started the built executable on guest loopback 127.0.0.1:18787 with a fresh /home/arcadia/arcadia-server-gate-h1z0bkqd/store. It imported the snapshot's 28-file source-6 teaching bundle, compared the returned full model with the snapshot's model.json, checked exact modular source, submitted syntactically invalid source and verified unchanged accepted source/ETag, requested graceful SIGTERM shutdown, restarted the same binary/store, and verified exact model/source/ETag again. Both process shutdowns exited 0. Resource identity: 4973c893-79f0-4fbb-9351-ebd60a2095cc, ETag "p-4973c893-79f0-4fbb-9351-ebd60a2095cc-r1". Driver and log: .local/linux-qa/server-http-smoke.py, runtime/linux-server-real-http-smoke.log. The guest store/logs remain available. This is actual Linux application execution, not cross-compilation; it does not establish desktop/GUI acceptance or the later corrected 30-module teaching content.

At 21:15:46 PDT, after re-verifying all 281 snapshot file hashes, cargo test --locked -p oa-server -- --test-threads=1 started with one build job and a 35-minute timeout. Log: runtime/linux-rust190-server-tests.log. This later test stage is in progress; the preceding build and real-process smoke must not be presented as a passing full server test suite.

Full server tests remain incomplete. A second explicitly approved scheduling pause stopped only the verified test process group 1654 from 21:31:24 to 21:36:34 (5m10s; SSH completion exceeded the nominal five minutes by ten seconds). Its original 35-minute wallclock limit was retained. The subsequent brief one-job Windows Clippy/build overlapped the lightweight dependency stage without another pause; measured memory stayed above the guard. The Linux command reached its limit during the additional oa-core build required by the dev-test dependency feature set. It ended nonzero after 2104.777 seconds (921.705 user, 134.911 system); no server tests executed and no Rust diagnostic was emitted. This is a bounded compilation timeout, not an assertion failure or full-suite pass. There was no blind retry or 90-minute VM-budget extension. Completed dependency artifacts remain available; the interrupted core compilation itself must be completed on the next run.

The successful server executable was preserved separately before test artifacts could replace it: /home/arcadia/qa-artifacts/server-20260907T033312Z/arcadia-server, 34,950,168 bytes, SHA-256 dcd216a34049a107c3b1234fb87c7d6d11f2e6c565c7cea8ac35232b42527d42. readelf identifies an x86-64 ELF64 position-independent executable. ldd resolves libgcc_s.so.1, libm.so.6, libc.so.6 and the glibc loader on this Ubuntu guest. This is a debug-profile tested artifact, not a final Linux release package or a claim about older glibc systems. linux-server-binary-metadata.log records the exact output.

Final verification at 21:52:13 rechecked all 281 source hashes unchanged and found no remaining Cargo/rustc/server process. Guest available RAM was 1670 MiB; root filesystem 2.6 GiB used / 16 GiB available; retained target 570 MiB. The real server process log was copied to runtime/linux-server-real-process.log. A clean sync; sudo systemctl poweroff was requested at 21:53:05, serial reached poweroff.target and Power down, and QEMU 10880 / launcher 8652 / seed 10696 were absent at 21:53:56. Host available RAM recovered to 4435210240 bytes (4.13 GiB); free disk was 16901267456 bytes (15.74 GiB). Logs: linux-server-final-evidence.log, server-gate-clean-poweroff.log, server-gate-post-poweroff-resources.json, and preserved server-gate-20260907T045305Z-final-serial.log.

Across 239 samples in this run, minimum free host RAM was 874897408 bytes (~834 MiB) and minimum free disk 15001563136 bytes (13.97 GiB). No resource watchdog stop occurred. runtime/server-gate-summary.json records these bounded-run statistics and SHA-256 for 14 result/process/pause/shutdown logs. The clean stop happened before the original 22:03:35 deadline, and no WSL retry, Windows setting change or existing user credential access occurred.

Next Linux gate after this clean stop

The VM is off and Windows heavy-build ownership has been released. On a future authorized 90-minute lease, use the same explicit live-budget launcher procedure, verify the retained guest and snapshot, then run the pending server tests with a 50-minute command allowance and no concurrent Windows compilation. This allowance is informed by the 35-minute incomplete test build (including 5m10s pause and additional contention), rather than treating emulated compile time as a correctness failure. Preserve /home/arcadia/qa-target and the custom Rust homes. The existing server-gate.sh SNAPSHOT test 50m driver rechecks source hashes; add explicit exit-status recording in a new version of the driver before the next run rather than modifying the already-hashed evidence script. If the intended test tree has changed, create a new separately hashed snapshot instead of overwriting this one.

Required later gates remain the full server suite, full core integration suite, Linux desktop compilation and actual GUI workflows, and final release packaging. The current source-6 server build and real HTTP/restart proof establish meaningful Linux/MSRV progress; they do not accept later source-7 changes, the corrected 30-module teaching project, desktop UX changes made after this snapshot, other architectures/libcs/filesystems, or complete Linux release readiness.