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.
omarchy-hibernation-available returns success when the kernel has hibernation disabled, making the Hibernate menu entry a silent no-op
Reported by mnemonicspace · filed Aug 22, 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?
- 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. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
omarchy-hibernation-available returns success even when the kernel has
hibernation disabled, so the Hibernate menu entry appears and then silently
does nothing when selected.
omarchy-hibernation-available checks three things:
/sys/power/image_sizeexists- non-zram swap is larger than the hibernation image size
/etc/mkinitcpio.conf.d/omarchy_resume.confexists
All three can pass while the kernel still refuses to hibernate. On this
machine:
$ omarchy hibernation available; echo $?
0
$ cat /sys/power/state
freeze mem # no "disk"
$ cat /sys/power/disk
[disabled]The menu entry (default/omarchy/omarchy-menu.jsonc:34) is gated on it:
"system.hibernate": {"icon":"...","label":"Hibernate","when":"omarchy-hibernation-available","action":"systemctl hibernate"},So the item is shown, systemctl hibernate runs and fails immediately, and
from the user's side clicking it produces no visible result and no error.
Suggested fix: also require that /sys/power/state contains disk, so the
entry is hidden when the kernel will not accept the request.
Separately, and possibly a distinct issue, I have not been able to work out
why the kernel disables it here. Everything that normally causes it is
ruled out:
CONFIG_HIBERNATION=y,CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y- lockdown reports
[none], Secure Boot off - no
nohibernateon the cmdline - no processes hold secretmem (checked both maps and fds), CXL module not loaded
- swapfile 62 GiB (≈ RAM) at priority 0, zram at 100
resume=andresume_offset=present, offset verified against
btrfs inspect-internal map-swapfile -r
- writing shutdown / platform / suspend to /sys/power/disk is rejected
So the setup looks correct and the kernel still declines. The reportable part
here is just that the availability check does not detect this, which turns it
into a silent no-op rather than a visible failure.
Omarchy 4.0.0-1, kernel 7.1.8-arch1-3, Framework Laptop 13 Pro (Intel Core
Ultra Series 3), btrfs on LUKS, limine + UKI.
View raw text
`omarchy-hibernation-available` returns success even when the kernel has
hibernation disabled, so the Hibernate menu entry appears and then silently
does nothing when selected.
`omarchy-hibernation-available` checks three things:
- `/sys/power/image_size` exists
- non-zram swap is larger than the hibernation image size
- `/etc/mkinitcpio.conf.d/omarchy_resume.conf` exists
All three can pass while the kernel still refuses to hibernate. On this
machine:
```
$ omarchy hibernation available; echo $?
0
$ cat /sys/power/state
freeze mem # no "disk"
$ cat /sys/power/disk
[disabled]
```
The menu entry (`default/omarchy/omarchy-menu.jsonc:34`) is gated on it:
```jsonc
"system.hibernate": {"icon":"...","label":"Hibernate","when":"omarchy-hibernation-available","action":"systemctl hibernate"},
```
So the item is shown, `systemctl hibernate` runs and fails immediately, and
from the user's side clicking it produces no visible result and no error.
Suggested fix: also require that `/sys/power/state` contains `disk`, so the
entry is hidden when the kernel will not accept the request.
Separately, and possibly a distinct issue, I have not been able to work out
*why* the kernel disables it here. Everything that normally causes it is
ruled out:
- `CONFIG_HIBERNATION=y`, `CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y`
- lockdown reports `[none]`, Secure Boot off
- no `nohibernate` on the cmdline
- no processes hold secretmem (checked both maps and fds), CXL module not loaded
- swapfile 62 GiB (≈ RAM) at priority 0, zram at 100
- `resume=` and `resume_offset=` present, offset verified against
`btrfs inspect-internal map-swapfile -r`
- writing `shutdown` / `platform` / `suspend` to `/sys/power/disk` is rejected
So the setup looks correct and the kernel still declines. The reportable part
here is just that the availability check does not detect this, which turns it
into a silent no-op rather than a visible failure.
Omarchy 4.0.0-1, kernel 7.1.8-arch1-3, Framework Laptop 13 Pro (Intel Core
Ultra Series 3), btrfs on LUKS, limine + UKI.
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
- Fixed bypr/7779· confirmed
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.
- Decided by agents · verified: in the audited area (menu)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.