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.
Wi-Fi resume fix (fix-wifi-resume.sh) excludes BCM4388 (14e4:4434), but it wedges on real lid-close suspend too
Reported by doomnote · filed Sep 8, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as not planned.
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
Hardware
- MacBook Pro 16" (2023), Apple M2 Pro —
Mac14,10 - Wi-Fi: Broadcom BCM4388, PCI ID
14e4:4434 linux-asahi 7.1.6.asahi1-1
Problem
After lid-close suspend (s2idle) and resume, Wi-Fi does not reconnect and NetworkManager can't bring it back up — it sees networks but association hangs/fails until the brcmfmac driver is reloaded (or the machine is rebooted). This is the same wedge described in AsahiLinux/linux#439.
install/hardware/apple/fix-wifi-resume.sh already ships a fix for exactly this (omarchy-wifi-resume-fix.service, reloading brcmfmac on a detected wedge), but the installer's chip gate only matches 14e4:4425 (BCM4378) and 14e4:4433 (BCM4387):
if [[ $(uname -m) == "aarch64" ]] && lspci -nn | grep -E "14e4:(4425|4433)" >/dev/null; thenThe comment explains BCM4388 (14e4:4434) was deliberately left out because a single manual ~6-minute s2idle test on an M2 Max (PR #255 review) didn't reproduce the wedge. On my M2 Pro with the same chip ID, real lid-close suspend reproduces it reliably.
Evidence
Manually creating/enabling the same unit the installer would create for 4425/4433:
sudo tee /etc/systemd/system/omarchy-wifi-resume-fix.service > /dev/null <<'EOF2'
[Unit]
Description=Reload brcmfmac if Wi-Fi does not return after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
After=NetworkManager.service
[Service]
Type=oneshot
ExecStart=/usr/bin/omarchy-wifi-resume-fix
TimeoutStartSec=120
[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
EOF2
sudo systemctl enable omarchy-wifi-resume-fix.service...then closing/reopening the lid produced a real wedge-and-recover cycle:
Sep 08 11:35:12 systemd[1]: Starting Reload brcmfmac if Wi-Fi does not return after resume...
Sep 08 11:35:24 omarchy-wifi-resume-fix[48818]: wifi not back after 12s (iface=wlan0 state=connecting (configuring)) - reloading brcmfmac
Sep 08 11:35:26 omarchy-wifi-resume-fix[48818]: brcmfmac reloaded, waiting for NetworkManager to reconnect
Sep 08 11:35:34 omarchy-wifi-resume-fix[48818]: reconnected 8s after reload on wlan0
Sep 08 11:35:34 systemd[1]: Finished Reload brcmfmac if Wi-Fi does not return after resume.Confirms: BCM4388 does wedge on real-world lid-close suspend, and the existing recovery service fixes it correctly once enabled.
Suggestion
Add 4434 to the chip match in fix-wifi-resume.sh (or consider dropping the chip gate entirely, since omarchy-wifi-resume-fix already self-limits — it only reloads the driver when it detects the actual wedge signature or a backstop timeout, so it's a no-op on hardware/kernels where the bug doesn't occur):
if [[ $(uname -m) == "aarch64" ]] && lspci -nn | grep -E "14e4:(4425|4433|4434)" >/dev/null; thenHappy to test a fix if useful — new Omarchy install as of 2026-09-07, so this is fresh/reproducible.
View raw text
### Hardware - MacBook Pro 16" (2023), Apple M2 Pro — `Mac14,10` - Wi-Fi: Broadcom BCM4388, PCI ID `14e4:4434` - `linux-asahi 7.1.6.asahi1-1` ### Problem After lid-close suspend (s2idle) and resume, Wi-Fi does not reconnect and NetworkManager can't bring it back up — it sees networks but association hangs/fails until the `brcmfmac` driver is reloaded (or the machine is rebooted). This is the same wedge described in AsahiLinux/linux#439. `install/hardware/apple/fix-wifi-resume.sh` already ships a fix for exactly this (`omarchy-wifi-resume-fix.service`, reloading `brcmfmac` on a detected wedge), but the installer's chip gate only matches `14e4:4425` (BCM4378) and `14e4:4433` (BCM4387): ```sh if [[ $(uname -m) == "aarch64" ]] && lspci -nn | grep -E "14e4:(4425|4433)" >/dev/null; then ``` The comment explains BCM4388 (`14e4:4434`) was deliberately left out because a single manual ~6-minute s2idle test on an M2 Max (PR #255 review) didn't reproduce the wedge. On my M2 Pro with the same chip ID, real lid-close suspend reproduces it reliably. ### Evidence Manually creating/enabling the same unit the installer would create for 4425/4433: ``` sudo tee /etc/systemd/system/omarchy-wifi-resume-fix.service > /dev/null <<'EOF2' [Unit] Description=Reload brcmfmac if Wi-Fi does not return after resume After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target After=NetworkManager.service [Service] Type=oneshot ExecStart=/usr/bin/omarchy-wifi-resume-fix TimeoutStartSec=120 [Install] WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target EOF2 sudo systemctl enable omarchy-wifi-resume-fix.service ``` ...then closing/reopening the lid produced a real wedge-and-recover cycle: ``` Sep 08 11:35:12 systemd[1]: Starting Reload brcmfmac if Wi-Fi does not return after resume... Sep 08 11:35:24 omarchy-wifi-resume-fix[48818]: wifi not back after 12s (iface=wlan0 state=connecting (configuring)) - reloading brcmfmac Sep 08 11:35:26 omarchy-wifi-resume-fix[48818]: brcmfmac reloaded, waiting for NetworkManager to reconnect Sep 08 11:35:34 omarchy-wifi-resume-fix[48818]: reconnected 8s after reload on wlan0 Sep 08 11:35:34 systemd[1]: Finished Reload brcmfmac if Wi-Fi does not return after resume. ``` Confirms: BCM4388 does wedge on real-world lid-close suspend, and the existing recovery service fixes it correctly once enabled. ### Suggestion Add `4434` to the chip match in `fix-wifi-resume.sh` (or consider dropping the chip gate entirely, since `omarchy-wifi-resume-fix` already self-limits — it only reloads the driver when it detects the actual wedge signature or a backstop timeout, so it's a no-op on hardware/kernels where the bug doesn't occur): ```sh if [[ $(uname -m) == "aarch64" ]] && lspci -nn | grep -E "14e4:(4425|4433|4434)" >/dev/null; then ``` Happy to test a fix if useful — new Omarchy install as of 2026-09-07, so this is fresh/reproducible.
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.