dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

packaging/windows: fix build watcher never firing, correct earlier

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
dodox
2026-08-12 11:57:28 +02:00
co-authored by Claude Sonnet 5
parent 7a405ad263
commit e43c3478c9
2 changed files with 31 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packaging/windows/README.md
+19 -9
View File
@@ -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