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.
Intermittent s2idle resume failure on HP EliteBook 845 G10, more frequent with Linux 7.2.3
Reported by mrelph · filed Sep 11, 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
HP EliteBook 845 14-inch G10, AMD Ryzen 5 PRO 7545U / Radeon 740M (Phoenix2), MediaTek MT7922 Wi-Fi, Omarchy 4.0.3-1, Hyprland 0.56.2, Linux 7.2.3-arch1-3, systemd 261.2-1, HP BIOS V82 01.12.03 dated 2026-05-18. The BIOS is reported current by fwupd. The system exposes only [s2idle] in /sys/power/mem_sleep.
What's wrong?
Closing the lid intermittently leaves the laptop unable to resume. Opening the lid has no effect, and a short power-button press has no visible effect. Recovery requires holding the power button for a hardware reset.
Most recent occurrence:
- Close the lid and leave the laptop suspended overnight.
- Open the lid.
- Observe that the display remains off and the machine does not respond.
- Press the power button briefly; there is no visible response.
- Hold the power button to force a reset.
The previous boot journal ends at the suspend entry:
2026-09-11T01:19:29-07:00 systemd-logind: Lid closed.
2026-09-11T01:19:29-07:00 systemd-logind: Suspending...
2026-09-11T01:19:30-07:00 systemd: Starting System Suspend...
2026-09-11T01:19:30-07:00 systemd-sleep: Performing sleep operation 'suspend'...
2026-09-11T01:19:30-07:00 kernel: PM: suspend entry (s2idle)There is no matching PM: suspend exit, lid-open event, panic, or orderly shutdown. The next boot reports that the system and user journals were corrupted or uncleanly shut down.
This is intermittent rather than a universal failure. Reviewing the retained journal history gives:
- Linux 7.1.9-arch1-2: 33 suspend entries, 31 exits, 2 boots ending during suspend (~6% unmatched).
- Linux 7.2.3-arch1-3: 13 suspend entries, 9 exits, 4 boots ending during suspend (~31% unmatched).
Linux was upgraded from 7.1.9 to 7.2.3 on 2026-09-08. The first boot on 7.2.3 ended on its first PM: suspend entry, about 32 seconds after boot. This suggests an existing intermittent AMD s2idle problem became substantially more frequent with the kernel shipped by the current Omarchy update.
No preceding amdgpu, NVMe, machine-check, watchdog, or explicit device-suspend failure appears in the retained journal. Earlier suspend/resume cycles on the same boots often complete normally, including amdgpu ... SMU is resumed successfully!.
Omarchy installs /etc/systemd/logind.conf.d/10-ignore-power-button.conf with HandlePowerKey=ignore. That is probably not the cause of the s2idle failure, because logind is frozen during suspend, but it prevents a normal short press from requesting shutdown if the machine partially resumes. For diagnosis I added a later local override setting HandlePowerKey=poweroff; the suspend failure predates that change.
Expected behavior: every lid-open or power-button wake should return from s2idle, or at minimum allow a graceful poweroff instead of requiring a hard reset.
The sanitized output of /usr/bin/omarchy-debug --no-sudo --print was captured immediately after the failed boot and can be provided if useful. The documented routed command omarchy debug --no-sudo --print returns Unknown Omarchy command on Omarchy 4.0.3-1, although /usr/bin/omarchy-debug works directly.
View raw text
## System details HP EliteBook 845 14-inch G10, AMD Ryzen 5 PRO 7545U / Radeon 740M (Phoenix2), MediaTek MT7922 Wi-Fi, Omarchy 4.0.3-1, Hyprland 0.56.2, Linux 7.2.3-arch1-3, systemd 261.2-1, HP BIOS V82 01.12.03 dated 2026-05-18. The BIOS is reported current by fwupd. The system exposes only `[s2idle]` in `/sys/power/mem_sleep`. ## What's wrong? Closing the lid intermittently leaves the laptop unable to resume. Opening the lid has no effect, and a short power-button press has no visible effect. Recovery requires holding the power button for a hardware reset. Most recent occurrence: 1. Close the lid and leave the laptop suspended overnight. 2. Open the lid. 3. Observe that the display remains off and the machine does not respond. 4. Press the power button briefly; there is no visible response. 5. Hold the power button to force a reset. The previous boot journal ends at the suspend entry: ```text 2026-09-11T01:19:29-07:00 systemd-logind: Lid closed. 2026-09-11T01:19:29-07:00 systemd-logind: Suspending... 2026-09-11T01:19:30-07:00 systemd: Starting System Suspend... 2026-09-11T01:19:30-07:00 systemd-sleep: Performing sleep operation 'suspend'... 2026-09-11T01:19:30-07:00 kernel: PM: suspend entry (s2idle) ``` There is no matching `PM: suspend exit`, lid-open event, panic, or orderly shutdown. The next boot reports that the system and user journals were corrupted or uncleanly shut down. This is intermittent rather than a universal failure. Reviewing the retained journal history gives: - Linux 7.1.9-arch1-2: 33 suspend entries, 31 exits, 2 boots ending during suspend (~6% unmatched). - Linux 7.2.3-arch1-3: 13 suspend entries, 9 exits, 4 boots ending during suspend (~31% unmatched). Linux was upgraded from 7.1.9 to 7.2.3 on 2026-09-08. The first boot on 7.2.3 ended on its first `PM: suspend entry`, about 32 seconds after boot. This suggests an existing intermittent AMD s2idle problem became substantially more frequent with the kernel shipped by the current Omarchy update. No preceding amdgpu, NVMe, machine-check, watchdog, or explicit device-suspend failure appears in the retained journal. Earlier suspend/resume cycles on the same boots often complete normally, including `amdgpu ... SMU is resumed successfully!`. Omarchy installs `/etc/systemd/logind.conf.d/10-ignore-power-button.conf` with `HandlePowerKey=ignore`. That is probably not the cause of the s2idle failure, because logind is frozen during suspend, but it prevents a normal short press from requesting shutdown if the machine partially resumes. For diagnosis I added a later local override setting `HandlePowerKey=poweroff`; the suspend failure predates that change. Expected behavior: every lid-open or power-button wake should return from s2idle, or at minimum allow a graceful poweroff instead of requiring a hard reset. The sanitized output of `/usr/bin/omarchy-debug --no-sudo --print` was captured immediately after the failed boot and can be provided if useful. The documented routed command `omarchy debug --no-sudo --print` returns `Unknown Omarchy command` on Omarchy 4.0.3-1, although `/usr/bin/omarchy-debug` works directly.
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 11:51 UTC