Sleep and wake
How it tests
Checks the network first (10 s, or 30 s when the run was online), sets the RTC alarm 20 s ahead and writes “mem” to /sys/power/state; on Macs whose NVMe drive needs it, d3cold_allowed is set to 0 first, as Omarchy's installer does. It records the wake sources and ACPI events, then waits up to 30 s for every network interface, USB device, input device and connected display, and for the network as the status line has it, held 3 s. Woken early by the lid's own wake with the lid open, it naps again with OmaBoot?'s lid wake fix. Then a 3-digit code shows large and the tester types it.
How it decides
Failed: the kernel refused, or it slept under 1 s. Partial: woke early by something else, woke long after the alarm, or something didn't come back. Woken early by the lid, then on time with the fix: supported with the lid wake fix (FIX tag). Supported: slept at least 75 % of the 20 s and everything came back. The code: typed right keeps the verdict; no answer in 60 s, or a wrong code twice, turns supported into partial; a skip turns it into not tested (uncertain).
How sure it is
A black screen can't show the code, so a Mac that never really came back can't pass.
On a real Mac
- On a MacBook Air (13-inch, Mid 2012): woken early by the lid, then 19.5 s of 20 on the RTC alarm with the lid wake fix, everything back, the code typed.
What could mislead it
- Could pass when it shouldn'tSleeping through /sys/power/state works where systemd's suspend path wouldn't. To narrow this, the test applies the installed path's own fixes (the lid wake, the NVMe setting) itself.
- Could fail when it shouldn'tSomething plugged in (an adapter, a phone) wakes it early: the cause is recorded, but only the lid gets a second nap.
- Could end without a verdictNo RTC alarm: not tested.