packaging/windows: fix BTRFS+QEMU boot-loop, document what's confirmed

Real issue hit on a real run: dockur/windows warns about BTRFS storage
but it's not idle -- on this host it boot-looped Windows Setup for
hours (same log lines repeating forever, disk barely growing), a known
bad combination for QEMU disk images on a copy-on-write filesystem.
build_windows.sh now disables COW on storage/ itself (chattr +C,
harmless no-op on non-btrfs or an already-populated dir from a prior
run). README updated to reflect both real fixes now confirmed needed
on this host (this one, plus the earlier SELinux :Z mount fix) instead
of the original "written but never run" status.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-11 21:16:24 +02:00
co-authored by Claude Sonnet 5
parent 4556da37ff
commit 2282a7d521
2 changed files with 33 additions and 6 deletions
+22 -6
View File
@@ -6,12 +6,28 @@ machine and no GitHub, by booting a real Windows VM inside a container
hood, no license key needed for the eval install it fetches automatically)
and driving the whole build over a shared folder.
**Status: written, not yet run against a real boot.** Everything here
follows dockur/windows's and WiX's documented mechanics, but there's no
KVM/Windows available in the environment this was authored in to actually
exercise it end to end. Treat the first run as a debugging session, not a
push-button success — watch it happen at http://localhost:8006 (dockur's
noVNC viewer) so you can see where it's stuck if it stalls.
**Status: has actually been run.** Two real environment issues hit and
fixed so far (both already applied in this directory, see "Confirmed
issues hit" below); Windows install itself was still in progress as of
last check. `oem/install.bat` onward (MSYS2/GTK4/WiX provisioning, the
actual .msi packaging) has NOT been reached/exercised yet — treat that
part as still a debugging session, not a push-button success. Watch it
happen at http://localhost:8006 (dockur's noVNC viewer) if it stalls.
## Confirmed issues hit (on Fedora + BTRFS)
- **SELinux blocks the bind mounts** ("Storage folder (/storage) is not
writeable!") — fixed with `:Z` on every volume in `docker-compose.yml`.
Harmless no-op on a host without SELinux.
- **BTRFS + QEMU disk images boot-loop Windows Setup for hours** with no
error, just the same boot-manager log lines repeating forever and the
disk barely growing — dockur/windows warns about this itself
("you are using the BTRFS filesystem for /storage, this might
introduce issues with Windows Setup!"), and on this host it wasn't
idle chatter. Fixed by disabling copy-on-write on `storage/` before
the VM ever writes to it (`chattr +C`, only affects files created
after it's set, so it needs an empty directory) — `build_windows.sh`
now does this itself on every run. No-op on a non-btrfs filesystem.
## How it fits together