Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
System update silently wiped windows vm disk (omarchy-windows-vm)
Reported by Rahelio · filed Sep 30, 2026Closed upstream on 2026-10-01 by its own reporter Rahelio. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
AMD Ryzen 7 PRO 6850H, AMD Radeon 680M, 1tb storage, 16gb RAM
What's wrong?
Environment:
- omarchy-dev / omarchy-settings-dev: updated 4.0.0.r2186.gee8ebf6-1 → 4.0.0.r6663.g3faafba-4/1 (2026-09-28, ~10:48 local)
- Kernel: 7.2.5-4-omarchy
- Windows VM backend: dockurr/windows container (omarchy-windows), managed via omarchy-windows-vm
- Filesystem: btrfs, / and /home are separate subvolumes (@, @home)
What happened:
I had a fully set-up Windows VM (installed 2026-09-16 via omarchy-windows-vm install) with Excel, Bitwarden, Chrome, etc. installed and in daily use for ~11 days. After running a routine pacman -Syu that pulled a large Omarchy update (~4,000 builds, since this system hadn't updated Omarchy in a while), I launched the VM as normal (omarchy-windows-vm launch). It booted into a completely fresh Windows install — all installed apps and data gone.
Root cause (as far as I could trace it):
- ~/.windows is correctly bind-mounted to /var/lib/omarchy/windows/mounts/users/<uid>/storage (confirmed identical inode — the mount itself is not the problem).
- Btrfs file-creation (crtime) timestamps show that every VM state file in ~/.windows — data.img (64G), setup.img, windows.rom, windows.vars, windows.base, windows.mac, windows.ver — was deleted and recreated as a brand-new inode at the exact moment the VM was next launched post-update. This is not a truncation/modification; the files were replaced.
- No reboot occurred, no manual rm in shell history, plenty of free disk space, and the dockurr/windows image itself was unchanged (pulled 2026-08-21). The only thing that changed between "working VM" and "wiped VM" was the Omarchy update to omarchy-windows-vm itself.
- The current omarchy-windows-vm script contains newly added storage-validation/migration logic (pinned-fd bind-mount checks, references to moving off ~/.config/windows for a security fix). This strongly suggests the new validation path didn't recognize my pre-existing storage as already-provisioned and caused dockur/windows's entrypoint to treat /storage as empty, triggering a fresh install over the top of my real disk.
- There is no recovery path: snapper's root config only covers the @ (root) subvolume, not @home — where ~/.windows actually lives — so there's no snapshot to roll back to. The data is unrecoverable.
Impact:
Total, silent, unrecoverable loss of a user's Windows VM disk (installed apps + any files not explicitly saved to /shared) as a side effect of a routine system update, with no warning, confirmation prompt, or backup taken beforehand.
Suggested fix:
- omarchy-windows-vm should detect a non-empty/pre-existing data.img before ever reinitializing storage, and refuse or prompt rather than silently reprovisioning.
- Any update that changes the VM storage/mount handling should include a migration path that preserves existing installs, or at minimum back up the old disk before touching it.
- Consider covering @home (or at least ~/.windows) with a snapshot/backup mechanism, since it currently has zero rollback coverage.
View raw text
### System details AMD Ryzen 7 PRO 6850H, AMD Radeon 680M, 1tb storage, 16gb RAM ### What's wrong? Environment: - omarchy-dev / omarchy-settings-dev: updated 4.0.0.r2186.gee8ebf6-1 → 4.0.0.r6663.g3faafba-4/1 (2026-09-28, ~10:48 local) - Kernel: 7.2.5-4-omarchy - Windows VM backend: dockurr/windows container (omarchy-windows), managed via omarchy-windows-vm - Filesystem: btrfs, / and /home are separate subvolumes (@, @home) What happened: I had a fully set-up Windows VM (installed 2026-09-16 via omarchy-windows-vm install) with Excel, Bitwarden, Chrome, etc. installed and in daily use for ~11 days. After running a routine pacman -Syu that pulled a large Omarchy update (~4,000 builds, since this system hadn't updated Omarchy in a while), I launched the VM as normal (omarchy-windows-vm launch). It booted into a completely fresh Windows install — all installed apps and data gone. Root cause (as far as I could trace it): - ~/.windows is correctly bind-mounted to /var/lib/omarchy/windows/mounts/users/<uid>/storage (confirmed identical inode — the mount itself is not the problem). - Btrfs file-creation (crtime) timestamps show that every VM state file in ~/.windows — data.img (64G), setup.img, windows.rom, windows.vars, windows.base, windows.mac, windows.ver — was deleted and recreated as a brand-new inode at the exact moment the VM was next launched post-update. This is not a truncation/modification; the files were replaced. - No reboot occurred, no manual rm in shell history, plenty of free disk space, and the dockurr/windows image itself was unchanged (pulled 2026-08-21). The only thing that changed between "working VM" and "wiped VM" was the Omarchy update to omarchy-windows-vm itself. - The current omarchy-windows-vm script contains newly added storage-validation/migration logic (pinned-fd bind-mount checks, references to moving off ~/.config/windows for a security fix). This strongly suggests the new validation path didn't recognize my pre-existing storage as already-provisioned and caused dockur/windows's entrypoint to treat /storage as empty, triggering a fresh install over the top of my real disk. - There is no recovery path: snapper's root config only covers the @ (root) subvolume, not @home — where ~/.windows actually lives — so there's no snapshot to roll back to. The data is unrecoverable. Impact: Total, silent, unrecoverable loss of a user's Windows VM disk (installed apps + any files not explicitly saved to /shared) as a side effect of a routine system update, with no warning, confirmation prompt, or backup taken beforehand. Suggested fix: - omarchy-windows-vm should detect a non-empty/pre-existing data.img before ever reinitializing storage, and refuse or prompt rather than silently reprovisioning. - Any update that changes the VM storage/mount handling should include a migration path that preserves existing installs, or at minimum back up the old disk before touching it. - Consider covering @home (or at least ~/.windows) with a snapshot/backup mechanism, since it currently has zero rollback coverage.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.