Repository navigation
[enhancement] Give the option to boot into the linux system as a VM from Windows #178
Description
Problem / Motivation
The easiest first step for a user would be to test out their system as a windowed/fullscreen QEMU VM or soemthing from Widnows itself, the next step would be to reboot into it.
Proposed solution
give the option as a first stepp to boot into the liux system as a VM
Alternatives considered
No response
Contribution
- Yes — I'd like to work on this (would you like a good-first-issue tag?)
Activity
feat: offline image bundle, and build the Try-in-VM assets (#177, #178)…
hanthor commentedon Aug 21, 2026
Worth recording what's actually in the tree, because the code for this already exists.
app/vm_windows.goimplements the whole feature:GetFreshVMCapability()/TryInVMFresh(imageRef)— buildspreview.rawfrom an OCI image in a headless builder VM, then launches an interactive preview window. This is exactly the "try it as a VM first" step this issue asks for.GetVMCapability()/BootInVM()— boots the installed system in a VM (SPEC §6.2).vmpreviewscreen and a "Try in VM" button on the launchpad, gated onstate.freshVmCapability?.available.So the feature isn't missing — it's dark.
GetFreshVMCapability()refuses unless it finds QEMU, the edk2 firmware, and a bundled Alpine builder kernel/initramfs underC:\wootc\qemu\.payload/builder/build-builder.shalready existed to produce those builder artifacts, but nothing referenced it — not the justfile, not CI, not the docs. So they were never built, the capability check always failed, and the button never appeared.PR #187 adds
just build-builderto wire that script up.What's still needed to close this is packaging, not code: a release has to actually ship
builder-vmlinuz+builder-initramfs.img, QEMU, and the edk2 firmware alongsidewootc.exe. That's a distribution-size and hosting decision (QEMU alone is ~100 MB), which is why I've left it rather than guessing — and it's the same question as #177, which PR #187 also addresses on the image side.feat: assemble an offline release bundle, and pin the installer to it (…
docs: refresh ROADMAP into the road to 1.0 — version ladder, mileston…
docs: roadmap to 1.0 with milestone ladder and tracking boards (#214)
docs: record 1.0 scope decision cutting pre-install Try-in-VM (M4.3) (#…
hanthor commentedon Sep 26, 2026
The 2026-09-26 experiments show that this needs more than packaging. The original helper did not load its VirtIO disk driver, exited zero after failure, and the Windows caller could mistake an existing blank disk for success. #411 fixes that false-success path. The required product journey is now explicit in ADR 0004: one persistent Linux disk, first used inside Windows, then eligible for native boot without losing the user's work.
Observed so far:
Still required before closing this issue: an ordinary fresh Windows user obtains the runtime through the app, reaches a usable Linux desktop, keeps a file and setting across shutdown/relaunch, and follows a proven same-disk native promotion path. Low-memory/low-disk recovery and actual older-PC compatibility need their own evidence. Server KVM/WHPX results do not establish that hardware coverage. Runtime source/dependency provenance must also be complete before release distribution.
Experiment records:
docs/experiments/vm-first-2026-09-26.mdanddocs/experiments/windows-vm-runtime-2026-09-26.md(the latter in #419).hanthor commentedon Sep 26, 2026
2026-09-26 experiment update: Phase 1 must start inside Windows
I confirm the originally stated Phase 1: the person first prepares and uses Linux in a Windows VM, then may move that same persistent system to native boot. We have been restoring that product direction in ADR 0004; native-only migration remains useful but cannot stand in for this first step.
New component evidence since the ADR:
Detailed immutable evidence is linked from the merged wootc PR #415 (
docs/experiments/vm-helper-2026-09-26.md) and PR #429. The product gate is still open; only the Windows-hosted round trip can establish the North Star journey.