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.
HIBERNATION AND SUSPEND NOT WORKING.
Reported by Divyanshu-kumar14 · filed Feb 27, 2026Closed upstream on 2026-02-27 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not 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
Intel i5-13450HX, RTX 3050, Omarchy 3.4.0
What's wrong?
System details
Dell-G15 5530
What's wrong?
Hi,
I'm running Omarchy (Linux 6.18.13-arch1-1) on a laptop with an NVIDIA GPU and I've been unable to get suspend or hibernate working.
System:
- Kernel:Linux 6.18.13-arch1-1
- NVIDIA GPU (proprietary drivers)
- External USB hub connected
Issue 1: Suspend (systemctl suspend) fails
The system attempts to suspend but immediately wakes back up with the following errors in journalctl:
usb usb1: PM: dpm_run_callback(): usb_dev_suspend returns -16
usb usb1: PM: failed to suspend async: error -16
usb usb2: PM: dpm_run_callback(): usb_dev_suspend returns -16
usb usb2: PM: failed to suspend async: error -16
PM: Some devices failed to suspend, or early wake event detected
systemd-sleep: Failed to put system to sleep. System resumed again: Device or resource busy
The system only supports s2idle (Low-power S0 idle used by default for system suspend), not S3 deep sleep. The xhci_hcd USB controller fails to suspend, immediately aborting the sleep attempt. Bluetooth also triggers an immediate wake event.
The kernel parameter usbcore.autosuspend=1 and a udev rule disabling USB wakeup did not resolve the issue. The freeze sleep state also fails with 'Device or resource busy'.
Issue 2: Hibernate (systemctl hibernate) fails with invalid resume config
Hibernate is potentially a viable workaround since the system has a 20GB swapfile and resume_offset=67118336 (verified with btrfs inspect-internal map-swapfile). However, hibernate fails with:
Call to Hibernate failed: Invalid resume config: resume= is not populated yet resume_offset= is
The reason is that the auto-generated cmdline in /boot/limine.conf contains a malformed resume= parameter:
resume=UUID=/dev/mapper/root ← broken, mixes UUID= prefix with a device path
The correct value should be:
resume=/dev/mapper/root
This appears to be generated by limine-entry-tool. Manually editing /boot/limine.conf to fix the resume= parameter does allow hibernate to work, but the fix gets overwritten on kernel updates since /boot/limine.conf is auto-generated.
Thanks for all the work on Omarchy — happy to provide any additional logs or testing if helpful.
@dhh please help
View raw text
### System details Intel i5-13450HX, RTX 3050, Omarchy 3.4.0 ### What's wrong? ### System details Dell-G15 5530 ### What's wrong? Hi, I'm running Omarchy (Linux 6.18.13-arch1-1) on a laptop with an NVIDIA GPU and I've been unable to get suspend or hibernate working. --- **System:** - Kernel:Linux 6.18.13-arch1-1 - NVIDIA GPU (proprietary drivers) - External USB hub connected --- **Issue 1: Suspend (systemctl suspend) fails** The system attempts to suspend but immediately wakes back up with the following errors in journalctl: usb usb1: PM: dpm_run_callback(): usb_dev_suspend returns -16 usb usb1: PM: failed to suspend async: error -16 usb usb2: PM: dpm_run_callback(): usb_dev_suspend returns -16 usb usb2: PM: failed to suspend async: error -16 PM: Some devices failed to suspend, or early wake event detected systemd-sleep: Failed to put system to sleep. System resumed again: Device or resource busy The system only supports s2idle (Low-power S0 idle used by default for system suspend), not S3 deep sleep. The xhci_hcd USB controller fails to suspend, immediately aborting the sleep attempt. Bluetooth also triggers an immediate wake event. The kernel parameter usbcore.autosuspend=1 and a udev rule disabling USB wakeup did not resolve the issue. The freeze sleep state also fails with 'Device or resource busy'. --- **Issue 2: Hibernate (systemctl hibernate) fails with invalid resume config** Hibernate is potentially a viable workaround since the system has a 20GB swapfile and resume_offset=67118336 (verified with btrfs inspect-internal map-swapfile). However, hibernate fails with: Call to Hibernate failed: Invalid resume config: resume= is not populated yet resume_offset= is The reason is that the auto-generated cmdline in /boot/limine.conf contains a malformed resume= parameter: resume=UUID=/dev/mapper/root ← broken, mixes UUID= prefix with a device path The correct value should be: resume=/dev/mapper/root This appears to be generated by limine-entry-tool. Manually editing /boot/limine.conf to fix the resume= parameter does allow hibernate to work, but the fix gets overwritten on kernel updates since /boot/limine.conf is auto-generated. --- Thanks for all the work on Omarchy — happy to provide any additional logs or testing if helpful. @dhh please help
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.