ARCADIA-Studio/harness/release-wsl-postboot-ytr83r-20260911.md

WSL post-reboot preparation — 2026-09-11

Original owner: Codex-ytr83r /root/linux_wsl; root took over all live process handles after the second reboot. Coordination: issue1 comments273,283,285. No production changes are part of this setup record.

Current status — paused by user

At15:28UTC, the user instructed that Linux builds/checking can be skipped until they resolve WSL2 networking and signal resumption. Root paused Linux setup and the offline download worker, preserving completed and partial inputs. The root task-prefix Rust command was interrupted with Ctrl+C; the same guest shell returned to its idle prompt. No APT install or Linux Cargo ran, and no completed Rust install is claimed. The exact package plan and signed-index preparation are preserved in the offline report. Nine byte-identical small input/log/cleanup records plus a root scope manifest are archived under offline-paused. The raw Rust setup log contains only its initial15:22:52UTC date; no completed checksum/install or terminal success marker was recorded. The worker's final pause manifest records11 verified debs, two unaccepted partials and zero live owned download processes. Large downloaded payloads remain local.

Networking remains unresolved. The user-directed VirtioProxy-only configuration is retained. No further network investigation, configuration or Linux verification will run until the user instructs. Windows tests/native work continue independently. The chronology below records completed and superseded experiments, not active instructions to restart setup.

Current intervention — VirtioProxy supersedes mirrored networking

The next direct user message points to owner comment328. Root preserved the previous applied bytes and replaced the owned configuration with exactly [wsl2] and networkingMode=virtioproxy. Shutdown completedexit0 at14:51:36.9652073UTC. One persistent root shell from guest / was started, with no compiler active, for the owner's address/route/ping/DNS/GitHub-HTTPS checks. The host VPN is immutable and is neither inspected nor modified. Evidence is under .local/wsl-virtioproxy-ytr83r-20260911/.

The persistent shell93868 succeeded and emitted readiness at14:53:48UTC; wslinfo --networking-mode reports virtioproxy. Exact requested checks failed: no default route, pingexit2/unreachable, bounded DNSexit124, GitHub HTTPSexit28 while resolving. Root keeps the shell open, with no repeat restart. The raw network log remains local; reports need only statuses, not interface addresses. At14:56:40UTC systemd reported running and no failed units. The generated /mnt/wsl/resolv.conf target is absent; /etc/resolv.conf remains a dangling symlink. No resolver change was made. Root filesystem ext4 is now directly verified. Those facts do not establish network failure's cause.

Offline setup through Windows HTTPS now advances the build: existing460 locked crate archives match Cargo.lock; fresh official Ubuntu resolute/updates/security InRelease signatures all passed guest gpgv with the installed Ubuntu archive key. Native Rust1.98.1 components and six main/universe package indices are hash-verified; isolated APT file-mirror update is running before selecting the exact dependency closure, preserving existing trust. See the offline preparation record. No apt installation or Linux Cargo has run. The trace fallback remains unexecuted; no administrator or VPN action is requested while ordinary offline setup works.

Previous intervention — mirrored networking

The user's direct message asks to check the Gitea networking solution. Root read the owner's issue1 comment316, which directs mirrored networking, DNS tunneling and an ordinary WSL restart, explicitly forbidding any host VPN change. C:\Users\User\.wslconfig was absent; root recorded that baseline and created exactly:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

Only Ubuntu-26.04 was registered, stopped, and no WSL command/guest work remained. wsl --shutdown completed exit0 at14:42:18.9208168UTC. Exact applied bytes, authorization reference, timestamp and shutdown record are saved in .local/wsl-mirrored-ytr83r-20260911/. No VPN, firewall, route/NAT or resolv.conf change occurred. Actual persistent-shell startup and the owner's bounded ping/DNS/HTTPS checks remain next; successful configuration writing alone does not establish network access or explain the earlier CreateVm timeouts. This new explicit guidance supersedes the earlier no-config-change trial strategy below.

The single post-change persistent-shell trial52988 subsequently reached terminalexit1 with the same CreateVm/0x800705b4 before a prompt. Windows Cargo had already terminated at14:43:51.917UTC; no guest ping/DNS/HTTPS commands ran. There is no successful networking result from this intervention. Root requests a read-only review of minimal local WSL tracing before any further reproduction; no further blind launch, VPN change or host reboot is planned. See the independent startup review for observed stage limits; current results do not prove network configuration caused the timeout.

Current outcome — registered WSL2 guest, later startup timeouts

The supported root-owned installation reached terminal exit0 at 14:19:47.9073217UTC. Its stdout says the distribution was successfully installed; wsl --list --verbose then listed Ubuntu-26.04 as version2. The complete official download was415,361,247 bytes. These observations supersede the pending status of this attempt below; the earlier failed attempt remains separate history.

Root's first shell inventory (session20913, started14:20:30UTC) completed exit0. It executed as uid0 and reported Ubuntu26.04 LTS (Resolute Raccoon), x86_64 kernel 6.18.33.2-microsoft-standard-WSL2, a /dev/sdd root and3.8GiB guest RAM with1GiB swap. The apparent955GiB guest filesystem availability is virtual-disk capacity, not physical Windows free space (about29GiB at14:29UTC). Git and Python3 exist; no Rust compiler/Cargo was found on PATH. The repository mount is readable and WSLg directories plus DISPLAY=:0, WAYLAND_DISPLAY=wayland-0 and XDG_RUNTIME_DIR=/run/user/0 exist. No application rendering was tested.

First launch warned that root's systemd user session failed to start. Separate read-only inventories1905/97517 completed: user@0 was inactive with no journal entries, and Landscape client subsequently appeared failed. Cloud-init was still finishing during the initial inventory. No default uid1000 account was returned; OOBE remains the Ubuntu-supplied /usr/lib/wsl/wsl-setup. Root's explicit noninteractive shell did not create an account or change that setup.

After those shells ended, two later commands reached real terminal WSL errors: setup session99983 (its initial bash -n command) exited-1 and inventory92958 exited1 with Wsl/Service/CreateInstance/CreateVm/0x800705b4 (timeout). Neither dependency installation nor the file-backed inventory began; no apt/Cargo pass is claimed. At14:30:53UTC boot remained13:57:30UTC, Windows had about3.86GiB free RAM, WslService/vmcompute/hns were running and a new vmmemWSL process existed. This does not identify the timeout's cause. It is distinct from the old HCS_E_HYPERV_NOT_INSTALLED failure: the new guest kernel actually ran.

Root will preserve both outcomes and retry a single persistent Linux shell after releasing the current Windows compiler load, rather than repeat concurrent startup attempts or change host settings. Windows lifecycle gate55371 remains active on frozen Rust/Cargo inputscb611a7. Guest dependencies, reliable restart, Linux compilation, WSLg application and packaging acceptance remain pending.

Installation chronology — 14:03:45 UTC, after virtualization was enabled

The user confirmed enabling virtualization and rebooting again, then explicitly authorized installing Ubuntu26.04 ourselves. Fresh root boot13:57:30UTC was observed; no cargo/rustc/wsl installer or registered distribution remained. The previous Windows gate33704 handle is missing and has no final test status. It is a reboot interruption, not an application test failure.

Reading the original install stdout as UTF16 established its actual outcome: download completed, then registration failed with Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED. This occurred before the latest virtualization change. The installer removed its temporary image; no retained Ubuntu26.04 archive was found in this login's temp directory. The earlier progress-only statements below are historical.

Root started the same supported install command at14:03:45.540UTC, PID7824, owned exec session33480. Exact command/timestamps/output are under .local/wsl-root-postvirtualization-20260911/; inspect that actual process and result before any retry. At14:04UTC its temporary Ubuntu26.04 image existed with zero bytes and no output. Guest shell/registration were then pending. Windows cached lifecycle compilation runs separately as55371, one Cargo job; no Linux Cargo may run concurrently without root scheduling. No host feature, security, firmware setting or reboot was changed by the agent.

Historical first attempt — 13:50 UTC

WSL is installed (2.7.13.0; packaged kernel 6.18.33.2-2; WSLg 1.0.73.2; Windows 10.0.26200.8457). These are host package versions, not an executed Linux kernel or GUI acceptance.

Fresh post-reboot checks found no registered distribution, Ubuntu Appx package or Lxss child registration. Only wslservice was initially active; no installer lease appeared in current Gitea comments, and no open PR existed. Read AGENTS.md, RESUME.md, previous Linux host report, current issue 1 comments and LinuxHostYtr83r20260911 Wiki before setup. Previous verified Ubuntu/QEMU evidence is preserved; no QEMU boot was repeated.

The live online catalog explicitly lists Ubuntu-26.04. Local WSL help supports the exact ordinary setup command:

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

Started hidden at 13:47:53.0539541 UTC, PID 3640 / child 1696. At approximately 13:50 UTC the installer is still active; TCP is established to 91.189.91.109:443, %TEMP%/Ubuntu-26.04.wsl exists with zero bytes, and stdout/stderr are empty. No successful registration, first-run prompt, guest shell, installed build dependency or Linux application validation is claimed. Do not duplicate this running installation.

Raw command/PID timestamp, redirected install logs, normalized WSL help/catalog/version and prepared guest inventory script are under .local/wsl-postboot-ytr83r/. Pending completion is monitored by the lease owner. No Windows feature/security/boot settings or reboot were changed.

Prepared next steps, not yet executed

1. After installer completion, capture wsl --list --verbose and run the read-only inventory.sh through the registered distribution, first retaining existing default user/OOBE state. Check actual uname/os-release, rootfs, architecture, RAM/disk, WSLg socket/environment and tools/packages.
2. Before package mutation, recheck shared owner/apt/dpkg activity. Install README development packages using ordinary apt: build-essential, pkg-config, libxkbcommon-dev, libxkbcommon-x11-0, libwayland-dev, libvulkan-dev, libx11-dev, libxrandr-dev, libxi-dev. Inspect existing Rust before selecting/installing a toolchain; workspace minimum is 1.90 and current Windows evidence uses 1.98.1.
3. Root must release the heavyweight gate before any Cargo build/test. Use one build job and one test thread with a distinct Linux target/cache and a frozen source identity. Start with locked core tests, then serial server/CLI and desktop gates, then actual WSLg application acceptance. Prefer an ext4 source/target snapshot over concurrent mutation of the Windows checkout. Windows artifacts are not Linux acceptance.