From 2282a7d52101cdf9ca68469b6ffc14c06b375980 Mon Sep 17 00:00:00 2001 From: Dominik Roth Date: Tue, 11 Aug 2026 21:16:24 +0200 Subject: [PATCH] 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 --- packaging/windows/README.md | 28 ++++++++++++++++++++++------ packaging/windows/build_windows.sh | 11 +++++++++++ 2 files changed, 33 insertions(+), 6 deletions(-) diff --git a/packaging/windows/README.md b/packaging/windows/README.md index 1ac1462..3c831d3 100644 --- a/packaging/windows/README.md +++ b/packaging/windows/README.md @@ -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 diff --git a/packaging/windows/build_windows.sh b/packaging/windows/build_windows.sh index e5699ab..49fd991 100755 --- a/packaging/windows/build_windows.sh +++ b/packaging/windows/build_windows.sh @@ -30,6 +30,17 @@ fi command -v docker >/dev/null 2>&1 || { echo "docker not found." >&2; exit 1; } mkdir -p storage oem shared/src shared/dist "$OUT_DIR" +# dockur/windows itself warns about this ("you are using the BTRFS +# filesystem for /storage, this might introduce issues with Windows +# Setup!") and it's not idle: confirmed on this host as a genuine +# multi-hour Windows Setup boot-loop (repeating the same boot-manager +# log lines forever, disk barely growing) -- QEMU disk images on a +# copy-on-write filesystem are a known bad combination. +C only takes +# effect for files created AFTER it's set on an empty directory, so +# this only helps on a fresh/emptied storage/; it's a no-op (harmless, +# chattr just errors quietly) on a non-btrfs filesystem or an +# already-populated storage/ from a previous run. +chattr +C storage 2>/dev/null || true echo "==> starting the Windows build VM (docker compose up -d)" docker compose up -d