Component
provider-swift (Swift CLI)
What happened?
install.sh aborts at the staging gate. The bundle downloads and hash-verifies, then:
Staging and verifying the complete app before touching the live install ...
Error: safe R1 was not latched as requested
✗ Packaged paged-kernel runtime smoke failed.
Existing installation was left unchanged.
The failing step is verify_staged_app → "$executable" runtime-smoke. It reproduces standalone
against the extracted bundle, so it is not an installer-environment artifact.
(Credit where due: the gate failed safe and left the previous install untouched.)
What I ruled out, each tested directly
- Not env. Fails with the four vars the installer sets, with none at all, with each alone, and
with both MLX flags set to 0.
- Not config.
gemma-weighted-r1 is default-ON with no config file present. Fails with it
explicitly enabled and explicitly disabled.
- Not a 0.8.10 regression. v0.8.9 fails identically.
- Not missing kernels. The bundled metallib carries the full
affine_qmm_* /
affine_gather_qmm_* family. The binary has a distinct message for that case
(packaged safe R1 AOT kernels are unavailable) and it is not the one firing. This is the
safeR1NotRequested branch, not safeR1AOTUnavailable.
- Not integrity. The app and
darkbloom-fan-helper both satisfy their pinned designated
requirements, and darkbloom + mlx.metallib SHA-256 match the release manifest exactly.
The part that seems wrong
Meanwhile darkbloom doctor passes every check that governs whether this box can serve privately:
Secure Enclave sign test, SIP full protection, authenticated root, hardened runtime,
debugger-not-attached, console session. The only posture warning is macOS 15 vs the recommended
macOS 26.
So a machine that clears the entire security posture is blocked from installing by a Gemma MoE
expert-reduction kernel smoke test.
I did not determine why the route will not latch. Plausibly GPU generation (Apple8 vs the M4 in
your validation set) or macOS 15 vs 26 Metal, but I did not prove either and would rather not guess
in a bug report.
Expected behavior
A machine that cannot latch an optimized expert route should fall back to the legacy path with a
warning, not fail the install.
The gate currently conflates "can this Mac serve securely" with "can it latch one specific
optimization." Either scope the smoke to configurations where the route is expected to latch, or
make non-latching non-fatal.
Workaround used: installed manually past the smoke, after running all of the installer's own
signature checks by hand first (designated requirement on the app and the fan helper, plus both
SHA-256 hashes against the release manifest). The provider installs and links fine that way.
Happy to run whatever diagnostics help — M2 Max on macOS 15 looks like an untested config for you
and the machine is available.
Steps to reproduce
curl -fsSL https://api.darkbloom.dev/install.sh | bash on an M2 Max running macOS 15.4.1
- Observe the abort at step 2/5
- Standalone repro: download and extract the v0.8.10 bundle, then run
./Darkbloom.app/Contents/MacOS/darkbloom runtime-smoke
→ Error: safe R1 was not latched as requested, exit 1
Environment
- provider: 0.8.10 (also reproduced on 0.8.9)
- macOS: 15.4.1 (24E263)
- hardware: MacBook Pro M2 Max, 32 GB, 38 GPU cores
- config: none present at time of failure (~/.config/darkbloom/provider.toml missing, defaults in memory)
Logs
$ darkbloom doctor
[PASS] se key sign test — Secure Enclave key loads and signs correctly.
[PASS] console session — a user is logged in at the console
[PASS] hardware: Apple M2 Max, 32 GB RAM, 38 GPU cores
[PASS] metal gpu: Apple M2 Max, 21 GB working set
[WARN] macos: macOS 15 is below the recommended macOS 26 (Tahoe) posture
[PASS] sip: enabled (full protection)
[PASS] rdma: disabled
[PASS] authenticated root: enabled
[PASS] hardened runtime: enabled
[PASS] debugger: not attached
[PASS] binary hash: b6e60f586ccd288f43e1afade54d8bca81c67fd88cb8e1d27e1f0f7e29c954de
$ ./Darkbloom.app/Contents/MacOS/darkbloom runtime-smoke
Error: safe R1 was not latched as requested
# exit 1
Confirmations
Component
provider-swift (Swift CLI)
What happened?
install.shaborts at the staging gate. The bundle downloads and hash-verifies, then:The failing step is
verify_staged_app→"$executable" runtime-smoke. It reproduces standaloneagainst the extracted bundle, so it is not an installer-environment artifact.
(Credit where due: the gate failed safe and left the previous install untouched.)
What I ruled out, each tested directly
with both MLX flags set to
0.gemma-weighted-r1is default-ON with no config file present. Fails with itexplicitly enabled and explicitly disabled.
affine_qmm_*/affine_gather_qmm_*family. The binary has a distinct message for that case(
packaged safe R1 AOT kernels are unavailable) and it is not the one firing. This is thesafeR1NotRequestedbranch, notsafeR1AOTUnavailable.darkbloom-fan-helperboth satisfy their pinned designatedrequirements, and
darkbloom+mlx.metallibSHA-256 match the release manifest exactly.The part that seems wrong
Meanwhile
darkbloom doctorpasses every check that governs whether this box can serve privately:Secure Enclave sign test, SIP full protection, authenticated root, hardened runtime,
debugger-not-attached, console session. The only posture warning is macOS 15 vs the recommended
macOS 26.
So a machine that clears the entire security posture is blocked from installing by a Gemma MoE
expert-reduction kernel smoke test.
I did not determine why the route will not latch. Plausibly GPU generation (Apple8 vs the M4 in
your validation set) or macOS 15 vs 26 Metal, but I did not prove either and would rather not guess
in a bug report.
Expected behavior
A machine that cannot latch an optimized expert route should fall back to the legacy path with a
warning, not fail the install.
The gate currently conflates "can this Mac serve securely" with "can it latch one specific
optimization." Either scope the smoke to configurations where the route is expected to latch, or
make non-latching non-fatal.
Workaround used: installed manually past the smoke, after running all of the installer's own
signature checks by hand first (designated requirement on the app and the fan helper, plus both
SHA-256 hashes against the release manifest). The provider installs and links fine that way.
Happy to run whatever diagnostics help — M2 Max on macOS 15 looks like an untested config for you
and the machine is available.
Steps to reproduce
curl -fsSL https://api.darkbloom.dev/install.sh | bashon an M2 Max running macOS 15.4.1Error: safe R1 was not latched as requested, exit 1Environment
Logs
Confirmations