Proof Portal
Project overview
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.
ReportR-1980GitHub issuePublicDecided· Out of scope
System hard-freeze on suspend with hyprlock active — no resume, requires hard reboot
Reported by heathdog · filed Apr 11, 2026 · open at source
Decided: Out of scope — decided by agents · verified 4 days ago.
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 hard-freeze on suspend with hyprlock active — no resume, requires hard rebootrevision 1 · captured 2026-09-28 21:29 UTC via poll
System details
Nvidia Geforce RTX 2080ti - Omarchy 3.5.0
What's wrong?
System hard-freeze on suspend with hyprlock active — no resume, requires hard reboot
Description
System suspended successfully but failed to resume. No kernel or systemd journal
entries exist after the PM: suspend entry (deep) line. A hard power cycle was
required. This happened with hyprlock active at suspend time (via hypridle's
before_sleep_cmd = loginctl lock-session).
Three prior reboots in the same afternoon (13:59, 14:10, 14:23 BST) suggest
instability leading up to the freeze.
Environment
- Hyprland: 0.54.3
- hyprlock: 0.9.3-2
- hypridle: 0.1.7-8
- OS: Arch Linux, kernel 6.19.10-arch1-1
- GPU: NVIDIA RTX 2080 Ti (EVGA), driver 595.58.03 (Open kernel module)
## hypridle config (relevant portion)
general {
before_sleep_cmd = loginctl lock-session # triggers hyprlock
after_sleep_cmd = sleep 1 && hyprctl dispatch dpms on
inhibit_sleep = 3 # wait until locked
}
Timeline (2026-04-10 BST)
┌──────────┬────────────────────────────────────────────────────────┐
│ Time │ Event │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:23:33 │ Hyprland session started (boot -1) │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:38 │ systemd-logind: The system will suspend now! │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ nvidia-suspend.service ran and completed │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ systemd-sleep: Performing sleep operation 'suspend'... │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ kernel: PM: suspend entry (deep) ← last journal entry │
├──────────┼────────────────────────────────────────────────────────┤
│ 12:22:54 │ System booted again (next day, after hard power cycle) │
└──────────┴────────────────────────────────────────────────────────┘
Last journal lines before freeze
Apr 10 14:52:38 omarchy systemd-logind[1103]: The system will suspend now!
Apr 10 14:52:39 omarchy systemd[1]: Starting NVIDIA system suspend actions...
Apr 10 14:52:39 omarchy suspend[7444]: nvidia-suspend.service
Apr 10 14:52:39 omarchy systemd[1]: nvidia-suspend.service: Deactivated successfully.
Apr 10 14:52:39 omarchy systemd[1]: Finished NVIDIA system suspend actions.
Apr 10 14:52:39 omarchy systemd-sleep[7448]: User sessions remain unfrozen on explicit request
($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Apr 10 14:52:39 omarchy systemd-sleep[7448]: Performing sleep operation 'suspend'...
Apr 10 14:52:39 omarchy kernel: PM: suspend entry (deep)
(no resume entries ever written)
Notes
- $SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 is logged as a warning — user sessions
were not frozen before suspend. This is the recommended setup for NVIDIA + Hyprland
but may interact poorly with hyprlock holding GPU/DRM resources during suspend.
- nvidia-suspend.service ran and reported success, but the GPU may not have cleanly
released resources held by hyprlock (framebuffer, DRM lease).
- The after_sleep_cmd (hyprctl dispatch dpms on) never ran.
- Possible culprit: hyprlock holding a DRM/GBM context open that prevents the NVIDIA
driver from properly entering suspend, leading to a hang at resume.
---
**Summary of what I found:**
- **Apr 9 crash:** Hyprland SIGSEGV in `SDRMConnector::disconnect()` → `CLogger::log()` during DRM backend teardown
(libaquamarine bug). xdp-hyprland also crashed on the broken socket. → File against `hyprwm/Hyprland` or `hyprwm/aquamarine`.
- **Apr 10 lockup:** System suspended with hyprlock active and never resumed — hard freeze requiring power cycle. No journal
entries after `PM: suspend entry (deep)`. → File against `hyprwm/hyprlock` (GPU resource holding during suspend) or
`hyprwm/Hyprland`.View raw text
### System details
Nvidia Geforce RTX 2080ti - Omarchy 3.5.0
### What's wrong?
System hard-freeze on suspend with hyprlock active — no resume, requires hard reboot
Description
System suspended successfully but failed to resume. No kernel or systemd journal
entries exist after the `PM: suspend entry (deep)` line. A hard power cycle was
required. This happened with `hyprlock` active at suspend time (via hypridle's
`before_sleep_cmd = loginctl lock-session`).
Three prior reboots in the same afternoon (13:59, 14:10, 14:23 BST) suggest
instability leading up to the freeze.
Environment
- **Hyprland:** 0.54.3
- **hyprlock:** 0.9.3-2
- **hypridle:** 0.1.7-8
- **OS:** Arch Linux, kernel 6.19.10-arch1-1
- **GPU:** NVIDIA RTX 2080 Ti (EVGA), driver 595.58.03 (Open kernel module)
## hypridle config (relevant portion)
```ini
general {
before_sleep_cmd = loginctl lock-session # triggers hyprlock
after_sleep_cmd = sleep 1 && hyprctl dispatch dpms on
inhibit_sleep = 3 # wait until locked
}
Timeline (2026-04-10 BST)
┌──────────┬────────────────────────────────────────────────────────┐
│ Time │ Event │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:23:33 │ Hyprland session started (boot -1) │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:38 │ systemd-logind: The system will suspend now! │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ nvidia-suspend.service ran and completed │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ systemd-sleep: Performing sleep operation 'suspend'... │
├──────────┼────────────────────────────────────────────────────────┤
│ 14:52:39 │ kernel: PM: suspend entry (deep) ← last journal entry │
├──────────┼────────────────────────────────────────────────────────┤
│ 12:22:54 │ System booted again (next day, after hard power cycle) │
└──────────┴────────────────────────────────────────────────────────┘
Last journal lines before freeze
Apr 10 14:52:38 omarchy systemd-logind[1103]: The system will suspend now!
Apr 10 14:52:39 omarchy systemd[1]: Starting NVIDIA system suspend actions...
Apr 10 14:52:39 omarchy suspend[7444]: nvidia-suspend.service
Apr 10 14:52:39 omarchy systemd[1]: nvidia-suspend.service: Deactivated successfully.
Apr 10 14:52:39 omarchy systemd[1]: Finished NVIDIA system suspend actions.
Apr 10 14:52:39 omarchy systemd-sleep[7448]: User sessions remain unfrozen on explicit request
($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Apr 10 14:52:39 omarchy systemd-sleep[7448]: Performing sleep operation 'suspend'...
Apr 10 14:52:39 omarchy kernel: PM: suspend entry (deep)
(no resume entries ever written)
Notes
- $SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 is logged as a warning — user sessions
were not frozen before suspend. This is the recommended setup for NVIDIA + Hyprland
but may interact poorly with hyprlock holding GPU/DRM resources during suspend.
- nvidia-suspend.service ran and reported success, but the GPU may not have cleanly
released resources held by hyprlock (framebuffer, DRM lease).
- The after_sleep_cmd (hyprctl dispatch dpms on) never ran.
- Possible culprit: hyprlock holding a DRM/GBM context open that prevents the NVIDIA
driver from properly entering suspend, leading to a hang at resume.
---
**Summary of what I found:**
- **Apr 9 crash:** Hyprland SIGSEGV in `SDRMConnector::disconnect()` → `CLogger::log()` during DRM backend teardown
(libaquamarine bug). xdp-hyprland also crashed on the broken socket. → File against `hyprwm/Hyprland` or `hyprwm/aquamarine`.
- **Apr 10 lockup:** System suspended with hyprlock active and never resumed — hard freeze requiring power cycle. No journal
entries after `PM: suspend entry (deep)`. → File against `hyprwm/hyprlock` (GPU resource holding during suspend) or
`hyprwm/Hyprland`.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 10:05 UTC