From e43c3478c963d093effb2a76d88332832ca4614b Mon Sep 17 00:00:00 2001 From: Dominik Roth Date: Wed, 12 Aug 2026 11:57:28 +0200 Subject: [PATCH] packaging/windows: fix build watcher never firing, correct earlier BTRFS misdiagnosis in README The build watcher was registered as a SYSTEM-context Scheduled Task (schtasks /ru SYSTEM). Confirmed on a real run this never actually works: Z:\ (the /shared mount) is mapped per interactive session, a SYSTEM task has no session of its own and can't see it, so watch_build.bat spun forever on its own "if not exist Z:\" wait -- a build request sat unclaimed for hours with zero indication anything was wrong. Fixed with an All-Users Startup-folder entry instead, which runs in whichever user's session actually logs in. Also correcting the README's earlier "BTRFS boot-loop" entry: that was a misdiagnosis from reading the text log alone (repeated "loading/starting Boot0004" lines). Actually looking at the noVNC screen showed genuine, progressing Windows Setup the whole time -- Setup legitimately reboots the VM multiple times, each one re-prints those same firmware lines. The chattr +C fix stays (real, independently documented dockur/QEMU/BTRFS caveat) but likely wasn't fixing an actual problem that time. Co-Authored-By: Claude Sonnet 5 --- packaging/windows/README.md | 28 +++++++++++++++++++--------- packaging/windows/oem/install.bat | 18 ++++++++++++------ 2 files changed, 31 insertions(+), 15 deletions(-) diff --git a/packaging/windows/README.md b/packaging/windows/README.md index 3c831d3..b335bb3 100644 --- a/packaging/windows/README.md +++ b/packaging/windows/README.md @@ -19,15 +19,25 @@ happen at http://localhost:8006 (dockur's noVNC viewer) if it stalls. - **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. +- **The repeated "loading/starting Boot0004" log lines are NOT a boot + loop** — that was an earlier misdiagnosis here (blamed on BTRFS+QEMU, + "fixed" with `chattr +C` on `storage/`). Checked the actual noVNC + screen instead of just the text log and it was genuine, progressing + Windows Setup the whole time ("This might take a few minutes" → + "Please keep your PC on and plugged in" → desktop) — Setup legitimately + reboots the VM multiple times, each one re-prints those same firmware + log lines. The `chattr +C` disables copy-on-write for the VM's disk + image regardless (a real, independently-documented dockur/QEMU/BTRFS + caveat), so it's staying, but it likely wasn't fixing an actual + problem this time. **Lesson: check the screen, not just the log, + before concluding something's stuck.** +- **The build watcher registered as a SYSTEM-context Scheduled Task + never fires in practice**: `Z:\` (the `/shared` mount) is mapped per + interactive session, invisible to a task with no session of its own, + so it spun forever on `watch_build.bat`'s own `if not exist Z:\` + wait — confirmed by a build request sitting unclaimed for hours. + Fixed in `install.bat`: an All-Users Startup-folder entry instead, + which runs in whichever user's session actually logs in. ## How it fits together diff --git a/packaging/windows/oem/install.bat b/packaging/windows/oem/install.bat index 13e3e37..8e90939 100644 --- a/packaging/windows/oem/install.bat +++ b/packaging/windows/oem/install.bat @@ -61,12 +61,18 @@ powershell -NoProfile -Command ^ "Expand-Archive -Path 'C:\wix311-binaries.zip' -DestinationPath 'C:\wix' -Force" del C:\wix311-binaries.zip -REM -- Register the build watcher to run at every boot from here on, plus -REM kick it off right now too (ONSTART won't retroactively fire for this -REM already-in-progress boot). Runs as SYSTEM so it works with no user -REM logged in. -call :log "registering build watcher ..." -schtasks /create /tn "FenigmaBuildWatcher" /sc onstart /ru SYSTEM /rl HIGHEST /tr "C:\OEM\watch_build.bat" /f >> C:\OEM\install.log 2>&1 +REM -- Register the build watcher to run at every login from here on, +REM plus kick it off right now too (a fresh login won't retroactively +REM fire for this already-logged-in session). Deliberately an All-Users +REM Startup-folder entry, NOT a SYSTEM-context Scheduled Task: confirmed +REM on a real run that a /ru SYSTEM task can't see Z:\ at all and spins +REM forever on watch_build.bat's own "if not exist Z:\" wait -- Z:\ (the +REM /shared mount) is mapped per INTERACTIVE session, invisible to a +REM SYSTEM task with no session of its own. Startup-folder entries run +REM in whichever user's session actually logs in, inheriting their +REM drive mappings correctly. +call :log "registering build watcher (Startup folder) ..." +copy /y C:\OEM\watch_build.bat "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\FenigmaBuildWatcher.bat" >> C:\OEM\install.log 2>&1 start "" cmd /c C:\OEM\watch_build.bat call :log "provisioning done"