E2E Testing Results

[skuthus]

Posting here as instructed by @malik-na
REPORT.md

I was also able to make an easier way to report all the needed info for these installs here: https://github.com/skuthus/omarchy-mac-e2e-test-capture - hopefully useful for others who want to gather this info requested consistently.

[hjhayes3]

M2 Macbook Air Results. Also including screenshots and output from commands.
Testing Photos.zip
omarchy-mac-e2e-volunteer-checklist-yamabushi-m2-MacbookAir.md

[hungmi]

iMac21,1 (24" M1, 16 GB) — Asahi Alarm Minimal BTRFS → default encrypted guided install — quattro @ 04862a0 (4.0.3rc4)

Full report (checklist template + timeline + evidence index) and the complete evidence bundle (macOS baseline, Asahi installer log, root-stage session recordings, collector output after first login / second login / reboot / cold boot, photos) are attached.

Result: every installer stage passed — boot-layout reboot, in-place encryption, Omarchy install, three automatic resumes, auto-login, second login, normal reboot, cold boot, security cleanup. On the checklist's terms the run is FAIL because of one item:

1. F1 — no audio on iMac 24". speakersafetyd 2.0.1-1 (asahi-alarm repo) panics on every boot: Globals/visense_pcm: Missing key — its own apple/j456.conf ships without the key (# NO VISENSE! TODO). Upstream issue, but install/hardware/apple/audio.sh checks is-active immediately after enable --now, so the install passed silently and the user gets a Dummy Output with no warning.
2. W1 — keyboard dead on both Thunderbolt ports at the initramfs passphrase prompt (ports 1 and 2 tested on different boots); the two USB 3 ports work. Full system drives all four. Looks exactly like a hang.
3. W10 — /var/log/omarchy-mac-setup.log never exists. LOG= is defined and its directory created, but nothing writes to it and the resume unit logs to tty only, so the guided setup leaves no persistent log. The checklist §8 tells testers to tail it.

Other warnings (excluded packages, mkinitcpio warnings, gum footer mojibake on tty, stale omarchy-mac/omarchy-mac repo name in the plan, keyring/xkb notices) are listed as W0–W14 in the report.

Attachments: REPORT.md, omarchy-e2e-report.zip (2.4 MB; serials, UUIDs and BT MAC redacted).

REPORT.md
omarchy-e2e-report.zip

[tommiley]

M3 Air: installation, tearing fix, and sleep progress

Asahi Alarm installer v0.9.2 successfully installed Minimal (BTRFS) on a 15-inch M3 MacBook Air. Omarchy Mac Quattro setup then completed with disk encryption. Testing used Omarchy 4.0.3rc4-1, kernel 7.1.13-3-2-ARCH and firmware 14.7.

We encountered four problems:

1. Severe horizontal screen tearing after installation. Hyprland misidentified the software renderer behind simpledrm. We backported Hyprland commit 61d0ff6, which detects software rendering from the active GL renderer rather than the DRM driver name, and rebuilt 0.56.2-3 as 0.56.2-3.1. Rebooting fixed the tearing; that package remains installed. This did not add GPU acceleration.

2. USB-C Ethernet did not appear. The kernel had CONFIG_TYPEC_SN201202X disabled. Building and temporarily loading the existing driver restored USB enumeration and working Ethernet. The kernel configuration change still needs packaging; this was not installed as a persistent fix.

3. Sleep diagnostics hung the machine. Wi-Fi disappeared during suspend, so we added direct USB/m1n1 debugging and compared debugger and native boots. We narrowed the hangs to devices-only suspend tests and partial aborts involving the UART. Temporarily keeping UART runtime power on made those tests pass. Crucially, ordinary native suspend and lid-close/open already worked with the original UART setting. A candidate driver patch compiles but remains uninstalled and untested at boot.

4. The screen did not consistently go dark or return on wake. Omarchy released its sleep inhibitor once the lock was secure, before the lock screen's five-second blanking timer fired. Userspace then froze, sometimes leaving a lit lock screen until wake. We installed a reversible user-service override that secures the lock, explicitly blanks the display before allowing suspend, and restores it after resume. It uses the existing Omarchy commands; packaged files and the kernel are unchanged.

With the display workaround, three automatic sleep/wake cycles passed, including 44 minutes asleep. The screen went dark, a power-button tap restored the lock screen, and password unlock returned a working desktop. Logs confirmed suspend/resume and that the sleep handler was ready again afterward.

Power efficiency is still a problem. The 44-minute battery-only test reported 2.83 Wh consumed—about 3.85 W, with charge falling from 94% to 90%. Battery-gauge variability limits precision; we have not demonstrated a power-saving improvement. Reboot persistence, peripherals and long-term reliability also remain unverified.

The live device tree keeps two display power domains always on. That makes display-controller/framebuffer support the next lead, alongside checking for repeated CPU wakeups; neither has yet been proven to account for the drain.

Testing and debugging were AI-assisted; on-device behavior was verified manually.