This document is retained only as a retirement note for the older direct-OCI Windows validation helper.
The canonical Windows clean-machine validation workflow is now:
That OracleTestVMs flow is the only supported path because it separates:
- a Windows build VM for
msys2/clang64packaging work - a separate clean Windows VM for first-install and manual validation
Going forward, that OracleTestVMs path is expected to use libvirt-backed
Windows leases by default rather than OCI-backed ones.
As of 2026-04-14:
- the Windows build VM was repaired enough to rebuild the MSI from the current repo state
Win11ThemeandWinUIThemebuild successfully there when the theme build is given-DHAVE_MODE_T=1- the root cause is documented in:
- the rebuilt MSI was staged onto a fresh clean Windows VM
- unattended smoke install on the clean VM still hit transient Windows first-boot installer contention (
1618) - a lower-level OCI rerun exposed that this repo's older direct-SSH script had drifted from the
OracleTestVMsWindows contract by assuming the SSH user wasopc
Practical implication:
- the packaging pipeline is back to a point where a fresh MSI can be built on a controlled Windows VM
- the next manual validation step is still to sign in over RDP as the test user and run the MSI interactively on a fresh clean VM
The old direct-OCI helper:
has been retired as a supported validation path.
Reason:
- it drifted from the supported Windows bootstrap/access contract
- it encouraged direct-SSH assumptions that are no longer the source of truth
- keeping both models live would keep recreating validation drift
Use instead: