ARCADIA-Studio/harness/release-wsl-readiness-9e8r6t-20260911.md

Local WSL readiness — 2026-09-11

Owner: Codex-9e8r6t /root/linux_readiness. Bounded local setup and dependency preparation; root owns heavy Cargo scheduling and Linux application acceptance.

User-directed pause — 15:28 UTC

The user has directed that Linux builds and checking be skipped for now and will notify us when they resolve WSL2 networking. All further Linux setup, WSL launches/diagnostics, service actions, builds and checks are paused. Preserve the existing VirtioProxy configuration, verified caches and evidence. Windows and product work continues. Gitea issue1 comment356 records this direction. The historical next steps below apply only after the user resumes Linux work.

Last measured state — 15:05 UTC

Ubuntu 26.04 is installed as WSL2 and a real root shell was verified. Mirrored networking was applied and proved unusable on this host. The user's newer VirtioProxy configuration is installed, but both the initial launch and one root-authorized retry after Windows compilation ended timed out before guest execution. VirtioProxy networking remains untested. A distinct root-authorized WslService restart was denied by service access permissions; it remains Running. No elevation workaround or further guest restart followed. No VPN changes.

Windows downloads provide all five hash-verified native Rust 1.98.1 components; 60 exact apt packages (80,287,656 bytes) completed download with every SHA256 verified against the official index. Apt metadata signature verification and guest package installation remain pending. No Linux compilation or application pass exists.

Next: root handles the service-access prerequisite and repeated CreateVm timeout. No further guest restart or configuration change is scheduled by this worker. Once a guest is usable, verify the requested mode/routes/DNS/HTTPS and stop troubleshooting if it works. Verify Ubuntu metadata signatures before installing offline packages, install the pinned native toolchain, remeasure backing-disk capacity and hand exact build commands to root. Linux Cargo stays held.

The small experiments/wsl-postboot-9e8r6t-20260911/setup-through-1457.zip and adjacent manifest preserve 28 setup records (36,464 bytes compressed), with every entry read back against its SHA256. Package blobs and complete distro images are excluded. Later preparation/install results remain separately scoped.

Initial evidence

At 14:03 UTC this host is DESKTOP-3D601S7, boot 13:59:33.500 UTC. No active Cargo/rustc/Ubuntu/WSL installer process was observed. The earlier 13:51:50.500 boot differs because the user rebooted again. Root's private shared-host probe was read back with exact token root-20260911-postboot-281; its hostname and 13:51:50.500 boot matched the worker then. Do not infer shared registration from the other Gitea owner's 13:41:27 boot or download progress.

Before the latest reboot, local wsl --list --verbose reported no installed distribution, no Ubuntu Appx/Lxss child existed, and only wslservice was running. The official wsl --list --online includes Ubuntu-26.04. Root's fresh postboot probe again reports no distribution. Gitea issue 1 comments 281–282 coordinate this worker separately from Codex-ytr83r's comments 273/277. The current open PR list was empty; LinuxHostYtr83r20260911 Wiki is historical other-host evidence.

Capacity before setup

Fresh C: free space was 4,464,992,256 bytes. Installation was initially held while root ratified a scoped capacity plan. Read-only inventory found .local/target-gnullvm/debug/incremental contains 34,420 compiler-generated files, 10,148,598,387 bytes. This directory is the proposed reproducible-cache cleanup candidate only after the sole Cargo owner confirms it is idle. Binaries under deps, immutable GUI stages, source manifests, logs and native evidence are outside that candidate. No files have been deleted and no installer was started.

Private evidence: .local/wsl-postboot-9e8r6t/storage-audit-1403.json records exact resolved path, per-directory inventory, reparse-point check, host/boot and space.

Root subsequently authorized removal of only that incremental cache, with the sole compiler lease held. The submitted native PowerShell command checked exact resolved path, ancestor/descendant reparse points and absent compiler processes before planned inventory and Remove-Item -LiteralPath. Automatic approval review rejected the command before execution: rejected: blocked by policy. No more specific reason was returned. No cleanup or install occurred; the incremental directory remains. Do not retry equivalent deletion through another tool or syntax to bypass this rejection. Root was informed and retains the capacity decision. Its initial install gate required more than 12 GB free.

Capacity recovered without deleting — 14:29 UTC

After new explicit user authorization, root's second exact removal attempt was also rejected before execution. Root then selected a distinct action: ordinary NTFS compression, retaining files and bytes. Initial incremental-cache compression session 53364 was intentionally stopped with Ctrl+C/exit 1 and is not a completed compression pass. Subsequent generated-executable compression session 54860 completed exit 0 for 282 files, with every before/after SHA256 unchanged. Root reported 11,777,519,616 free bytes (10.97 GiB); worker's fresh 14:29:34 probe measured 11,772,731,392. Root accepted this measured capacity for setup. No file deletion or OS/security/boot setting change occurred.

Private binary-compression-result.json, binary-compression-records.jsonl and compression logs preserve root's actual results and interrupted first action.

Supported install started — 14:30 UTC

Fresh local inventory still showed no registered distribution and no WSL/Ubuntu installer or Cargo/rustc process. Worker started one ordinary installation in exec session 32405. install-start.json and install.log preserve command, boot, free space and output; install-result.json is written only on terminal completion. Gitea issue 1 comment 308 records ownership. No registration or Linux shell success was inferred while this process was live.

Installation completed at 14:36:46.120 UTC, exit 0, with the explicit message Distribution successfully installed. Fresh list showed Ubuntu-26.04, WSL version 2, initially Stopped. install-result.json measured 10,513,858,560 host free bytes. The downloaded 415,361,247-byte image was independently SHA256 checked before install completion: 96c7f5fb28a7fe28245331f9bfbe4375f18dd29a4850116ad3c4f60f6700c55c, matching the official Microsoft distribution catalog. image-hash.json preserves the exact comparison. This validates the supplied installer input; registration is separate from application acceptance.

First bounded root-shell inventory via wsl -d Ubuntu-26.04 -u root --exec /bin/sh -c ..., session 51462, completed exit 0 at 14:39:22 UTC. Exact guest output/result is retained separately. /etc/os-release proves Ubuntu 26.04 LTS (Resolute Raccoon); uname -a proves x86_64 Linux 6.18.33.2-microsoft-standard-WSL2; id proves root access. /dev/sdd is mounted, /mnt/wslg exists, and apt-get/curl are installed. /etc/wsl.conf enables systemd. No UID 1000 account or Linux Rust/Cargo executable was observed.

Guest networking has eth0 172.29.43.171 with default route via 172.29.32.1. Root filesystem reports a virtual 955 GiB available, but the actual Windows backing disk had only 10,432,016,384 free bytes: use the host value for capacity. First root startup emitted Failed to start the systemd user session for 'root'. A bounded read-only systemd/network/prerequisite probe follows; this warning is not silently treated as a clean user session. No account/authentication was set.

The subsequent read-only probe completed at 14:40:49 UTC. Both Ubuntu and Rust HTTPS HEAD probes timed out (curl 28, about 6 seconds each). The script's final process exit 0 is not a networking pass. systemd reported starting and no failed units; user@0 was inactive after recorded clean session shutdown. Base image has ca-certificates, curl, git, Python 3.14 and Mesa Vulkan drivers; the requested development packages and Rust/Cargo are not established.

User-directed mirrored networking correction

Read exact user issue 1 comment 316: preserve host VPN, set mirrored networking plus DNS tunneling, restart WSL and verify. Windows 11 Pro build 26200 was inspected. C:/Users/User/.wslconfig did not exist; its absence is recorded in wslconfig-before.json. With no remaining WSL client/apt operation, worker wrote only:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

After SHA256 is 12C518CC5B3BA24F2F579151FC360FBC99F9E184ADB79EBCE29CF909B7574540; wslconfig-after.json preserves exact content. One wsl --shutdown completed exit 0 at 14:41:45 UTC. Existing Windows Cargo/rustc remained active as expected. Fresh Ubuntu routing, numeric ping, DNS and HTTPS probes are in session 82441, with explicit per-probe exit codes in mirrored-network.log. No VPN, firewall, security/boot, manual route or resolv.conf edits were made.

Mirrored probe completed 14:44:28 UTC: only loopback, no default route; numeric ping exit 2 Network is unreachable, DNS exit 2, all three HTTPS probes exit 6 (DNS failure). Again, wrapper exit 0 only means probes ran. Subsequent real /usr/bin/wslinfo --networking-mode reported mirrored, exit 0 at 14:47:41 UTC: the setting is applied at runtime, but connectivity is failing. The first guessed wslinfo path was absent (exit 127), retained separately. /etc/resolv.conf points to absent /mnt/wsl/resolv.conf. Guest journal records systemd init/user startup timeouts and unsuccessful graceful poweroff followed by WSL's forced poweroff; no additional explicit worker shutdown occurred.

Read-only host checks found DisabledComponents=4294967295 (0xFFFFFFFF) under HKLM/SYSTEM/CurrentControlSet/Services/Tcpip6/Parameters. Physical Ethernet0 (Intel 82574L) is Up and its IPv6 adapter binding is enabled. This is a concrete configuration clue, not proof of root cause; root is evaluating reported WSL issues with similar loopback-only symptoms. No registry or adapter was changed. host-ipv6-readonly.json, runtime-mode.log, guest logs and a bounded VmSwitch event sample preserve observations. The sample includes NetEventBindFailed but does not by itself prove which component caused the missing mirrored interface.

User-directed VirtioProxy correction — 14:52 UTC

The user's newer comment 328 supersedes the mirrored configuration: treat AmneziaWG as immutable, including no inspection, and switch only WSL to VirtioProxy. Worker read the exact comment, confirmed all prior WSL probes were terminal, and verified the current config was exactly the two previously written keys. wslconfig-mirrored-backup.ini preserves its original bytes. Replacement contains only [wsl2] and networkingMode=virtioproxy; SHA256 5D8F32148682FEF35DABB4F506F1B206EB56DA8B9CB94589A530F7588C8164D6. One shutdown completed exit 0 at 14:52:32 UTC. The requested runtime-mode, address, route, numeric ping, github.com DNS and HTTPS tests run in session 18271. No further VPN/adapter/registry/firewall inspection or mutation was performed.

The offline apt plan independently completed exit 0 before this change: base image retains official main/restricted indexes and can resolve README's build prerequisites without an index download. No apt/dpkg mutation has yet run. Native Linux Rust 1.98.1 components are being downloaded on Windows from the official HTTPS manifest, verified against its SHA256 values; no prior reusable native Rust or Debian package archive was found in the bounded task caches. The five components are compiler, Cargo, Linux standard library, rustfmt and Clippy; downloads do not constitute installation or compilation.

The first VirtioProxy guest launch failed before any guest command ran: session 18271 terminated exit -1 at 14:54:57 UTC with Wsl/Service/CreateInstance/CreateVm/0x800705b4 (timeout). There is no runtime-mode, route, ping, DNS or HTTPS result for VirtioProxy yet. This is a VM startup failure, not evidence that VirtioProxy networking failed. Root holds further guest launch until Windows GUI compilation is terminal; one ordinary root shell with --cd / and the same bounded probes is then planned. Config remains unchanged.

All five native Rust component archives have now individually passed manifest SHA256 checks. First downloader exited 1 only because rustfmt's DNS resolution failed; the other four archives passed. A separate bounded rustfmt retry passed the same expected SHA256, retaining the initial failure. No guest install ran. Official Ubuntu resolute InRelease and main Packages.xz were fetched on Windows; the index's exact size/SHA256 matches InRelease. GPG signature verification in the guest is required before any package install. Existing apt print-URI plan selects concrete package versions and SHA256 from that index, avoiding duplicate distribution/index trees. First local planner stopped before downloads on an encoded ++ path; URL decoding was corrected without changing metadata/hashes.

After Windows GUI compilation was confirmed terminal, root authorized one ordinary persistent shell retry with --cd /, no additional shutdown/config change. Session 54267 also terminated before guest commands, exit 1 and the same CreateVm timeout. virtioproxy-retry-result.json preserves the exact terminal error text (PTY control escapes omitted), command and observation. Failure after the compiler cleared means concurrent Cargo alone cannot explain the outcome; the actual cause remains unresolved. All guest installs remain unexecuted.

Distinct WslService reset hypothesis — 15:05 UTC

Root authorized a single restart of WslService only after preserving state. Preflight found WslService Running, no WSL/Ubuntu/installer client processes, and wsl --list --running --quiet exit 0 with no distro output. Current config hash remained unchanged. Lxss event log was not found; accessing the Hyper-V Compute Operational event log explicitly required elevated user rights, so no failure-event diagnosis is claimed from that inaccessible log.

Restart-Service -Name WslService -ErrorAction Stop then failed at 15:05:23 UTC: Cannot open 'WslService' service on computer '.'. The service remained Running. This is a command-level service-access failure, distinct from the earlier automatic approval rejection of file deletion. No elevation UI/workaround, second service attempt or guest launch followed. HNS, vmcompute, network adapters, firewall and VPN were not changed or restarted. Exact preflight, running-distro result, denied event access and service result are preserved in the private service-reset-* records.

Historical supported installation method and setup inputs

After coordinated capacity recovery, the successful installation used:

wsl --install Ubuntu-26.04 --no-launch --version 2

Its terminal result and real guest checks are recorded above. Interactive authentication/account choices stay with the user. No host security/features/boot changes or QEMU workaround are part of this task.

Repository setup inputs are README.md, rust-toolchain.toml, Cargo.toml and docs/linux-packaging.md. README requests build-essential, pkg-config, libxkbcommon-dev, libxkbcommon-x11-0, libwayland-dev, libvulkan-dev, libx11-dev, libxrandr-dev and libxi-dev; Mesa Vulkan runtime is needed for the documented software-adapter trial. rust-toolchain.toml selects stable with rustfmt/clippy; workspace MSRV is 1.90. The packaging document's Ubuntu 24.04 baseline is distinct from the newly requested Ubuntu 26.04 host and must remain explicit.

Ubuntu registration and a real root shell are now verified. Dependency installation, Rust toolchain, application build, package, GUI and service acceptance remain unestablished. No Cargo compilation was started.