Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-854GitHub issuePublicReceived

Stable installer (master) still writes apple-bce, breaking every T2 Mac install

Reported by joelgranik · filed Sep 7, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as not planned.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

Stable installer (master) still writes apple-bce, breaking every T2 Mac installrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

MacBookPro16,1 (16-inch 2019), T2 Security Chip, linux-t2 7.1.8.arch1-3

What's wrong?

omarchy.org/install installs from `master`, and master's fix-t2.sh still writes the pre-7.1.4 module name apple-bce. The fix from #6559 landed on quattro only. The result is that the default, documented install path fails on every T2 Mac.

The chain, verified end to end:

  1. https://omarchy.org/install serves exactly:
   eval "$(curl -fsSL https://raw.githubusercontent.com/basecamp/omarchy/refs/heads/master/boot.sh)"

and that boot.sh does OMARCHY_REF="${OMARCHY_REF:-master}" → git clone --branch master → source install.sh.

  1. master (f4378f0de, "Omarchy 3.8.5", 2026-08-14) still has install/config/hardware/apple/fix-t2.sh writing:
   echo "apple-bce" | sudo tee /etc/modules-load.d/t2.conf >/dev/null
   echo "MODULES+=(apple-bce usbhid hid_apple hid_generic xhci_pci xhci_hcd)" | sudo tee /etc/mkinitcpio.conf.d/apple-t2.conf >/dev/null
  1. linux-t2 7.1.4 renamed that driver. On 7.1.8 there is no apple-bce at all — the tree contains only t2bce_core, t2bce_dma, t2bce_vhci, t2bce_audio under kernel/drivers/staging/t2bce/.
  1. So mkinitcpio cannot resolve the module. Every initramfs/UKI rebuild hard-fails → no UKI on the ESP → no boot entries → the install does not complete.
  1. The stable channel does not pin the T2 kernel, so this cannot self-resolve. linux-t2 is not in stable-mirror.omarchy.org at all (checked core, extra, multilib; extra has 14,914 packages and none of them is linux-t2). It always resolves current from arch-mact2, which is well past 7.1.4.

quattro has been correct since 38c1352f6 (2026-07-29) and also ships migrations/1785273276.sh for already-installed machines. Neither reached master. #6559 was explicitly titled "[quattro only]", so I think this is scope rather than an oversight — but the one-line installer on the website still defaults to master, so that scoping leaves the advertised path broken for this hardware.

What I observed

I hit this installing on a MacBookPro16,1. My route was Arch + linux-t2 first, then the Omarchy script, so I saw the mkinitcpio failure directly and patched the clone to t2bce_vhci before re-running install.sh. I have not run the pure Omarchy-ISO path end to end, so I'm reporting the mechanism and the code, not a second reproduction — but since apple-bce does not exist in any current linux-t2, I don't see how that path resolves it either.

Suggested fix

Backport 38c1352f6's two lines to master — or, if master is intentionally frozen, point omarchy.org/install at the branch that carries the fix. The ?-suffixed form used in the quattro migration is the safest single change, since it keeps working on both sides of the rename:

MODULES+=(t2bce_vhci? apple-bce? usbhid hid_apple hid_generic xhci_pci xhci_hcd)
View raw text
### System details

MacBookPro16,1 (16-inch 2019), T2 Security Chip, `linux-t2 7.1.8.arch1-3`

### What's wrong?

`omarchy.org/install` installs from **`master`**, and `master`'s `fix-t2.sh` still writes the pre-7.1.4 module name `apple-bce`. The fix from #6559 landed on `quattro` only. The result is that the default, documented install path fails on every T2 Mac.

**The chain, verified end to end:**

1. `https://omarchy.org/install` serves exactly:
   ```
   eval "$(curl -fsSL https://raw.githubusercontent.com/basecamp/omarchy/refs/heads/master/boot.sh)"
   ```
   and that `boot.sh` does `OMARCHY_REF="${OMARCHY_REF:-master}"` → `git clone --branch master` → `source install.sh`.

2. `master` (`f4378f0de`, "Omarchy 3.8.5", 2026-08-14) still has `install/config/hardware/apple/fix-t2.sh` writing:
   ```sh
   echo "apple-bce" | sudo tee /etc/modules-load.d/t2.conf >/dev/null
   echo "MODULES+=(apple-bce usbhid hid_apple hid_generic xhci_pci xhci_hcd)" | sudo tee /etc/mkinitcpio.conf.d/apple-t2.conf >/dev/null
   ```

3. `linux-t2` 7.1.4 renamed that driver. On 7.1.8 there is no `apple-bce` at all — the tree contains only `t2bce_core`, `t2bce_dma`, `t2bce_vhci`, `t2bce_audio` under `kernel/drivers/staging/t2bce/`.

4. So `mkinitcpio` cannot resolve the module. Every initramfs/UKI rebuild hard-fails → no UKI on the ESP → no boot entries → the install does not complete.

5. **The stable channel does not pin the T2 kernel, so this cannot self-resolve.** `linux-t2` is not in `stable-mirror.omarchy.org` at all (checked `core`, `extra`, `multilib`; `extra` has 14,914 packages and none of them is `linux-t2`). It always resolves current from `arch-mact2`, which is well past 7.1.4.

`quattro` has been correct since `38c1352f6` (2026-07-29) and also ships `migrations/1785273276.sh` for already-installed machines. Neither reached `master`. #6559 was explicitly titled "[quattro only]", so I think this is scope rather than an oversight — but the one-line installer on the website still defaults to `master`, so that scoping leaves the advertised path broken for this hardware.

### What I observed

I hit this installing on a MacBookPro16,1. My route was Arch + `linux-t2` first, then the Omarchy script, so I saw the `mkinitcpio` failure directly and patched the clone to `t2bce_vhci` before re-running `install.sh`. I have not run the pure Omarchy-ISO path end to end, so I'm reporting the mechanism and the code, not a second reproduction — but since `apple-bce` does not exist in any current `linux-t2`, I don't see how that path resolves it either.

### Suggested fix

Backport `38c1352f6`'s two lines to `master` — or, if `master` is intentionally frozen, point `omarchy.org/install` at the branch that carries the fix. The `?`-suffixed form used in the quattro migration is the safest single change, since it keeps working on both sides of the rename:

```sh
MODULES+=(t2bce_vhci? apple-bce? usbhid hid_apple hid_generic xhci_pci xhci_hcd)
```

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.