Laptop will not resume from suspend on Omarchy

Your laptop goes to sleep, and the only way back is holding the power button. This page splits that one symptom into the three different failures it actually is, because the fixes do not overlap. Checked against Omarchy 4.0.4 source, with notes where 3.x behaved differently.

The fix

1. Find out whether the kernel ever suspended. After a forced reboot, read the previous boot’s kernel log:

journalctl -k -b -1 | grep -E 'PM: suspend (entry|exit)|refusing to freeze|failed to suspend'

Three outcomes, three different problems:

• PM: suspend entry, then Freezing user space processes failed or failed to suspend, then a quick PM: suspend exit: the kernel aborted and the machine never actually slept. Go to step 2.
• PM: suspend entry with no exit, or a log that simply stops after logind’s Suspending...: the kernel or firmware went down and never came up. A hard hang can take the unflushed tail of the journal with it, which is why three of the four hangs in issue #12190 below have no entry line at all. Go to step 4.
• PM: suspend entry with a matching exit and no errors between them: the kernel resumed. Your display or session never came back. Go to step 5.

2. Nothing froze: hunt the stuck process.

journalctl -k -b -1 | grep -i 'refusing to freeze'
mount | grep fuse

FUSE daemons stuck in uninterruptible sleep are the classic cause. In issue #4184, commenter gulp found rclone mounting Google Drive held the freeze for 20 seconds until it timed out, and the machine then sat awake pretending to be asleep, eating battery.

Omarchy ships a pre-sleep hook for this. alansikora’s PR #4940 merged on 2026-03-10 and shipped in v3.5.0. Confirm it is installed and root-owned:

ls -l /usr/lib/systemd/system-sleep/

Read the shipped script before trusting it. In v4.0.4 unmount-fuse only matches the fuse.gvfsd-fuse filesystem type, so it clears Nautilus mounts and leaves rclone, sshfs and other FUSE mounts alone. Unmount those yourself before sleeping, or add your own pre hook next to it.

v4.0.3 added migration 1788662350.sh, which replaces the shipped keyboard-backlight and force-igpu hooks if they are not root-owned and parks the old copy under /var/lib/omarchy/migrations/ for review. It does not touch unmount-fuse or hooks you wrote yourself, so check the ls -l output above for anything not owned by root and fix that by hand.

3. Check what sleep state your firmware offers.

cat /sys/power/mem_sleep

If the only entry is [s2idle], deep sleep does not exist on that machine and no kernel parameter will invent one. That is the case on the Framework 13 with the Ryzen AI 9 HX 370 in issue #394. If both are listed and s2idle is flaky, you can test deep for the current boot only:

echo deep | sudo tee /sys/power/mem_sleep

Omarchy itself only forces mem_sleep_default=deep (with pm_async=off) on T2 Macs, in install/hardware/apple/fix-t2.sh and migration 1785944594.sh. Do not copy that Limine drop-in onto non-Apple hardware without testing the temporary switch first.

4. Kernel went down and never came up.

On NVIDIA, enable the driver’s own sleep services. Omarchy does not do this for you: in v4.0.4, install/hardware/nvidia.sh writes only options nvidia_drm modeset=1 and the early-load MODULES line.

echo 'options nvidia NVreg_PreserveVideoMemoryAllocations=1' | sudo tee /etc/modprobe.d/nvidia-power.conf
sudo systemctl enable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service
sudo limine-mkinitcpio

Reboot before testing. This helps when the NVIDIA card drives your panel. It does nothing on an offload-only hybrid laptop where the iGPU owns the display: in #12041 the reporter enabled all three services and the preserve flag and the corruption on resume was unchanged.

Then suspect the kernel. v4.0.4 ships the bespoke linux-omarchy kernel to everyone, and that is a real regression vector. Issue #12190 counts suspend outcomes per boot on a Dell XPS 13 with Wildcat Lake graphics: 13 of 13 suspends completed and resumed on stock linux 7.2.3, and 0 of 4 came back on linux-omarchy 7.2.5-3 with the same kernel command line (three of those four never even logged PM: suspend entry). Install linux-lts, or plain linux as that report did, boot it from the Limine menu, and suspend twice. If it resumes, you have a kernel bug, not an Omarchy configuration bug.

5. Kernel resumed, screen stayed dark. Get a TTY with Ctrl + Alt + F3. One reporter in #2635 found the monitors lit up the moment they switched VT; others in the same thread got no TTY at all. From a TTY or over SSH as your own user, point hyprctl at the running instance and ask Hyprland to re-enable output:

export HYPRLAND_INSTANCE_SIGNATURE=$(hyprctl instances | awk -F'[ :]' '/^instance / {print $2}')
omarchy system wake
hyprctl dispatch dpms on

If dpms on does nothing, sudo systemctl restart sddm brought the screens back for two people in that thread, at the cost of the whole Hyprland session. If the TTY is dead too, the compositor or the kernel display driver is wedged and only a power cycle will clear it. Issue #5695 shows the i915 form of this, with flip_done timed out and PHY A errors after resume. A commenter there linked an upstream kernel commit, but the one person who applied it found it only covers DisplayPort tunnels and did nothing for the internal panel; what worked for several reporters was booting linux-lts or another 6.x kernel. That is a kernel problem, not a config change.

6. If it never works, take suspend off the menu.

omarchy toggle suspend

That hides Suspend from the System menu (Super + Esc). The 3.x path was different: 3.3.0 removed suspend from the menu by default and offered it back under Setup > System Sleep, and 3.4.0 made it default-on again with the same opt-out. See the manual chapter on system sleep.

Verify it worked

Suspend and resume twice, then check the pairs line up:

journalctl -k -b -1 | grep -E 'PM: suspend (entry|exit)'
journalctl -k -b -1 | grep -iE 'failed to suspend|refusing to freeze|early wake event'

You want one exit for every entry and nothing in the second command. Also confirm the lock path is healthy, since in 4.x the pre-suspend lock runs through Quickshell:

systemctl --user status omarchy-sleep-lock.service
omarchy debug idle
busctl get-property org.freedesktop.login1 /org/freedesktop/login1 \
  org.freedesktop.login1.Manager InhibitDelayMaxUSec

That last value should be 15000000. Omarchy ships a logind drop-in raising InhibitDelayMaxSec to 15 seconds, and migration 1784970000.sh sets the reboot-required flag when the running value does not match.

Why it happens

A suspend is three separate stages, and “it did not wake up” is the same symptom for a failure in any of them.

Freezing userspace comes first. Any task stuck in an uninterruptible kernel call, typically FUSE, blocks the freeze until it times out, and the machine stays on.

Then the kernel hands off to firmware. On s2idle the CPU never fully powers down and the platform is responsible for the low-power state, so a single misbehaving device (a WWAN modem, a Wi-Fi card, an NVMe controller) can keep the system awake or wedge it on the way back. Errors like usb usb1: PM: failed to suspend async: error -16 (a Dell G15 with a USB hub in #4740) and brcmfmac 0000:01:00.0: PM: failed to suspend: error -5 (T2 MacBooks in #8106) show up here, and in both the kernel abandons the suspend and wakes straight back up. deep sleep pushes more of the work onto firmware, which is why swapping states sometimes helps and sometimes makes things worse.

Last, the display has to come back. The NVIDIA driver discards video memory across suspend unless NVreg_PreserveVideoMemoryAllocations is set and the suspend services are enabled. Intel and AMD have their own resume-path bugs; the i915 timeouts in #5695 are a kernel issue, not an Omarchy one, which is why it also reproduces on Fedora for one commenter in that thread.

Quattro adds a fourth wrinkle on the way down. Locking now happens in Quickshell, and omarchy-system-lid-close starts the lock the moment the lid shuts rather than waiting for logind’s PrepareForSleep, precisely so the lock finishes inside the inhibitor window. Issue #12193 describes the remaining race: logind commits to suspend on lid close while Hyprland never sees the lid reopen, because user.slice is already frozen, so a quick close and open leaves a dark screen.

If that did not work

Collect logs before filing anything. omarchy debug uploads a bundle to logs.omarchy.org and prints the link, which is what maintainers ask for. Include your /sys/power/mem_sleep output, the PM: suspend lines from the failed boot, your exact kernel package and version, and whether stock linux behaves differently.

The evidence here is uneven on purpose. The FUSE cause is confirmed and fixed in-tree. The kernel regressions are recent and open; #12190 is the only one A/B tested against stock linux, while #12129 and #12041 sit on the same linux-omarchy 7.2.5-3 build without that comparison. The hybrid-GPU corruption in #12041 has no known fix at all. If your machine is not in one of those buckets, assume it is firmware or device specific and say so when you report it.

Related

• Hibernate fails or hangs: a different code path, shares the FUSE and resume-parameter problems
• Bluetooth stops after resume and Wi-Fi drops after a kernel update: for when only one device fails to come back
• Black screen after login: if the panel is dark at boot, not just after sleep
• Suspend, sleep and resume hardware notes and T2 Macs
• omarchy-toggle-suspend and v4.0.4 release notes