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.
Framework Desktop: shutdown hangs on Omarchy logo with Thunderbolt display (Studio Display XDR) on 4.0.4
Reported by Aayush9029 · filed Sep 28, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Framework Desktop (AMD Ryzen AI Max+ 395, Radeon 8060S), Insyde BIOS 03.06, Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2. Display: Apple Studio Display XDR on USB4/Thunderbolt (40 Gb/s, authorized via boltd), 5120x2880@120 on DP-5. Root on LUKS + btrfs, Limine 12.8.0, Secure Boot on.
What's wrong?
Shutdown never finishes. The screen shows the Omarchy Plymouth logo and stays there, and the machine doesn't power off until I force it with the power button.
Steps to reproduce:
1. Boot normally with the Studio Display XDR connected over Thunderbolt/USB4.
2. Shut down via System menu → Shutdown (omarchy-system-shutdown), or run sudo shutdown now in a terminal.
3. The Omarchy logo stays on screen indefinitely and the system never powers off.
It happens both ways, so it doesn't look specific to the menu script. omarchy-system-shutdown already schedules the poweroff via systemd-run --user, so this is not the old nohup problem from #5832.
What the journal shows (several recent shutdowns, journalctl -b -1/-2/-3):
- logind logs poweroff requested from client ... ('systemctl') (unit [email protected]) → System is powering down.
- Userspace teardown looks clean: no stop-sigterm timed out, no Killing from system units, and mounts (/home, /boot, external exFAT drive) unmount normally.
- The journal ends at the unmount phase with no errors. So the hang comes after journald stops, in the final shutdown stage (LUKS/root teardown, device shutdown, or the firmware poweroff).
This looks like the same hardware/display combination as #3918 (Framework Desktop + Thunderbolt/USB-C monitor, power never goes off). There, unplugging or turning off the monitor after starting the shutdown made it complete. That was on 3.2.3, so it seems to still reproduce on 4.0.4, showing up as a hang on the logo instead of a restart.
Happy to provide omarchy-debug output, or boot once without quiet splash to capture the last console line before the hang.
View raw text
### System details
Framework Desktop (AMD Ryzen AI Max+ 395, Radeon 8060S), Insyde BIOS 03.06, Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2. Display: Apple Studio Display XDR on USB4/Thunderbolt (40 Gb/s, authorized via boltd), 5120x2880@120 on DP-5. Root on LUKS + btrfs, Limine 12.8.0, Secure Boot on.
### What's wrong?
Shutdown never finishes. The screen shows the Omarchy Plymouth logo and stays there, and the machine doesn't power off until I force it with the power button.
Steps to reproduce:
1. Boot normally with the Studio Display XDR connected over Thunderbolt/USB4.
2. Shut down via **System menu → Shutdown** (`omarchy-system-shutdown`), or run `sudo shutdown now` in a terminal.
3. The Omarchy logo stays on screen indefinitely and the system never powers off.
It happens both ways, so it doesn't look specific to the menu script. `omarchy-system-shutdown` already schedules the poweroff via `systemd-run --user`, so this is not the old nohup problem from #5832.
What the journal shows (several recent shutdowns, `journalctl -b -1/-2/-3`):
- logind logs `poweroff requested from client ... ('systemctl') (unit [email protected])` → `System is powering down.`
- Userspace teardown looks clean: no `stop-sigterm timed out`, no `Killing` from system units, and mounts (`/home`, `/boot`, external exFAT drive) unmount normally.
- The journal ends at the unmount phase with no errors. So the hang comes after journald stops, in the final shutdown stage (LUKS/root teardown, device shutdown, or the firmware poweroff).
This looks like the same hardware/display combination as #3918 (Framework Desktop + Thunderbolt/USB-C monitor, power never goes off). There, unplugging or turning off the monitor after starting the shutdown made it complete. That was on 3.2.3, so it seems to still reproduce on 4.0.4, showing up as a hang on the logo instead of a restart.
Happy to provide `omarchy-debug` output, or boot once without `quiet splash` to capture the last console line before the hang.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 20:03 UTC