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

Linux release verification options — 2026-09-06

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.