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](https://raw.githubusercontent.com/microsoft/WSL/master/distributions/DistributionInfo.json).
`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](http://217.177.34.108:3000/sorokin.oleg.edu/ARCADIA-Studio/issues/1#issuecomment-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:

```ini
[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](http://217.177.34.108:3000/sorokin.oleg.edu/ARCADIA-Studio/issues/1#issuecomment-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:

```powershell
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.