MacBook Neo developer builds and preview catalog - #48

M3 MacBook Air 13" (J613): dev4 preview installed and booted

I installed the developer preview from neo-preview-dev4-20261007 on a 13-inch M3 MacBook Air, and it booted into Omarchy.

• Mac: MacBook Air 13" M3, Mac15,12 / J613, 24 GB, 2 TB
• macOS: 27.0 (26A428), FileVault off
• Installer: Omarchy-Installer-Developer-2.1.0.zip from this pre-release
• Catalog: developer catalog sequence 1791382094, payload digest sha256:e4588ecc…6a61
• Image and engine: developer-preview-20261007-aurora12 with engine v0.9.2-omarchy.30. The app staged the M1–M3 installer_data.json, not installer_data-m3air.json.
• Result: the install and the Recovery step completed, and the Mac boots into Omarchy. The macOS 27 "system firmware is too old" failure from System Firmware too old when installing omarchy on M3 Pro with MacOS 27 omarchy-mac#440 didn't happen here, although this staged installer_data.json lists supported_fw only up to 26.6.
• Disk layout after install: EFI 524 MB, Boot 2.1 GB, Root 566.7 GB, stub APFS container 2.5 GB

I haven't checked individual hardware yet (Wi-Fi, Bluetooth, audio, backlight and brightness keys, sleep, USB-C, external display, camera). I'll add those results here.

Follow-up: testing dev5 on the J613 hit a recovery-image prerequisite after disk mutation. Could you advise on a supported recovery path and check this requirement before resizing?

• Hardware: 13-inch M3 MacBook Air, J613 / Mac15,12, 8 GB RAM, 251 GB internal disk.
• Host: macOS 27.0.1, build 26A434.
• Candidate: source 43ddbf274474419b189f51f1dd46c9f9f8d90e55, engine v0.9.2-omarchy.32 (SHA-256 12ba2f04ebdf01854cc791d89d5e577763d97453a88cc521f2092b42d30ea82c), dev5 sealed catalog. The app was locally built with ad-hoc signing using the installed macOS 26.5 SDK; its app/helper trust was pinned to exact cdhashes. Engine, metadata, payload and signed catalog were not modified. This is not a published/notarized dev5 app.
• Earlier space checks were resolved before this attempt. Installation approved about 50.6 GB.

The UI reached:

Started preparing disk space
Disk space reserved for Omarchy ✓ · verification 1cbdb168…f9259629
Started writing boot files

Then failed:

omarchy_asahi.AsahiAdapterError: the 25G83 recovery image is encrypted; run the installer from macOS 25G83, not 26A434, to use its decrypted copy

The journal records apfs-target-prepared, then stub_and_esp_started, with no stub-and-esp-installed checkpoint. The observed layout afterward is macOS APFS resized to about 194.6 GB, a partial 6 GB Omarchy APFS firmware container, and about 44.6 GB unallocated. EFI/Linux partitions have not been created. The original macOS remains running. No retry or cleanup has been attempted.

Read-only investigation found that ipsw fw aea can decrypt a copy of this recovery image using Apple's public FCS key; hdiutil verify passed and its mounted SystemVersion.plist reports 25G83. The copy was unmounted afterward. Nothing was replaced in the partial stub. Exclave images, signed root hashes and a supported continuation procedure still need validation; this observation alone is not a proposed safe resume.

Could dev5 preflight reject the incompatible host build before prepare_target, or support verified decryption of the exact restore images? What is the supported recovery procedure for this interrupted stub_and_esp stage? We have not cleared the journal or bypassed AmbiguousMutationState.

Drafted with an AI assistant from the local execution journal and disk inspection.

Drafted with an AI assistant (Claude Code); I reviewed it before posting.

@mrobs11 thanks, that's the first M3 Air install of the preview by someone other than us. Both things you noticed are expected for dev4:

• installer_data.json and engine .30: the notarized dev4 app is signed with catalog 1791382094, which predates the M3 Air group. installer_data-m3air.json and engine .31 on that release page are left over from a later test that never shipped in an app, so the app ignores them.
• macOS 27: supported_fw lists the OS firmware the installer puts in the boot stub, not the macOS version. With that catalog an Air gets 14.8.3, and your system firmware (27.0) can boot it. To confirm, in Omarchy: tr -d '\0' < /proc/device-tree/chosen/asahi,os-fw-version; echo

neo-preview-dev5-20261011 (Aurora 11.14) gives the M3 Airs their own catalog entry with 26.6.2 OS firmware, and a notarized app for it should follow soon; we're setting up the Omacom Apple Developer account. Please don't try dev5 on an M3 Air running macOS 27 yet, though: as @garymeyerca found above, it stops after resizing the disk because the 26.6.2 recovery image is encrypted. We're looking into that now.

Touch ID is also starting to work on the M3 Air: on our J613 a finger enrols and matches, and the enrolment survives a reboot. It isn't in the preview yet. The kernel side is in omacom/linux-aurora#82.

Hardware results would be very welcome when you have them (Wi-Fi, Bluetooth, audio, brightness, sleep, USB-C, external display, camera), along with the output of uname -r.

Drafted with an AI assistant (Claude Code); I reviewed it before posting.

@garymeyerca thanks for the careful report, and for stopping without clearing anything.

Cause. dev5 gives the M3 Airs only the 26.6.2 (25G83) OS firmware. macOS 26 restore images ship the recoveryOS and Exclave images AEA-encrypted, and the stub's recoveryOS can't mount them. Engine .32 doesn't decrypt them. It copies the decrypted images the running macOS keeps in its own Recovery and Preboot volumes, so it only works when the host is running exactly 25G83 (_use_decrypted_images in Engine/overlay/src/omarchy_asahi.py). Our J613 was installed from 26.6.2 and updated to 27 afterwards. On 26A434 there is no supported way to finish a dev5 install on an M3 Air today.

The bug is ours. That build check runs in install_stub_and_esp, after the resize and the stub container. preflight already loads the chosen IPSW, so the same check belongs there, before prepare_target touches the disk. That's going into the next engine. Supporting verified decryption of the exact restore images is a bigger change, with the open questions you listed (Exclave images and the signed root hashes), so it isn't in that fix.

Recovering this Mac. Nothing was blessed or added to the boot policy, so the partial stub is inert, and macOS is unaffected. The app's Remove can't help yet: it only recognises a whole installation (stub, EFI, Linux), and it would refuse this layout. From macOS:

1. Confirm the layout and identifiers:

   diskutil list
   diskutil apfs list
   

   You should see disk0s2 (macOS, about 194.6 GB), then the 6 GB APFS partition with the partial stub, then the free space, then the Recovery partition. In the commands below, diskN is the stub's synthesized container disk and disk0sM is its physical partition. If the layout isn't exactly that, stop and post the output here.
2. Delete the partial stub container and turn its partition into free space. This is what Remove does to a stub:

   sudo diskutil apfs deleteContainer diskN
   sudo diskutil eraseVolume free none disk0sM
   

3. Give the space back to macOS:

   sudo diskutil apfs resizeContainer disk0s2 0
   

Leave the app's execution journal alone. If the app reports the interrupted install afterwards, post its message here.

Two ways forward on that Mac for now: wait for the fixed engine, or use the notarized dev4 app from neo-preview-dev4-20261007. Its catalog gives the Air 14.8.3 OS firmware, which @mrobs11 installed from macOS 27 and which boots (comment above). Note that dev4 is the older Aurora 12.0 image, and the M3 GPU path we test uses the 25G83 firmware.

Thanks @scottjones, appreciate the explanation and recovery steps. This J613 / Mac15,12 is available for whatever testing you need, including candidate engines, recovery fixes and hardware checks. Let me know what would be most useful and what state you want the machine in before testing.

The partial installation and execution journal are still intact. I haven’t retried or cleaned anything up.

Drafted with an AI assistant; I reviewed the details before posting.

@scottjones thanks for the explanation. I checked the firmware reading and gathered hardware observations on my 13-inch M3 MacBook Air (J613 / Mac15,12).

Firmware and current system

$ tr -d '\0' < /proc/device-tree/chosen/asahi,os-fw-version; echo
14.7
$ tr -d '\0' < /proc/device-tree/chosen/asahi,system-fw-version; echo
27.0
$ uname -r
7.1.12-2-20261009.8-sep-ARCH

The OS firmware reading is 14.7, rather than the 14.8.3 you expected. My original installation used the notarized app from neo-preview-dev4-20261007, catalog 1791382094 and payload sha256:e4588ecc…6a61. Is 14.7 expected for that installation?

The current m1n1 versions are stage1 v1.6.1-dirty and stage2 v1.6.1-omarchy.aurora15. These and the kernel version describe the machine now; I haven’t established that the bootloader and kernel are unchanged from the original dev4 install.

Hardware observations

Camera detail

The FaceTime HD camera enumerates at /dev/video1 and advertises NV12 at up to 1920×1080/30 fps. In a direct capture test, buffer setup and VIDIOC_STREAMON succeeded, but v4l2-ctl --stream-mmap --stream-count=1 --stream-poll reported select timeout. A polling test at 1280×720 also timed out. Although v4l2-ctl exited with status 0, I haven’t verified a successfully captured frame.

At the time of the CLI test, no process was holding /dev/video1 or /dev/media1, and PipeWire’s camera node was suspended. My user has read/write access to /dev/video1. The kernel log contains ISP request/opcode timeouts and repeated messages:

apple-isp 2a4000000.isp: [isp_stop_command_processor] never received magic number from firmware
apple-isp 2a4000000.isp: firmware did not suspend, stopping it

The green indicator turning on is what I observed in the web apps; I didn’t verify its state during the CLI test. Because capture also times out without a browser or an apparent competing device holder, this appears broader than a Zoom/Meet configuration issue. I don’t yet know the exact cause.

Please let me know which additional tests would be most useful, particularly for the camera and the 14.7 firmware reading.

Then failed:

omarchy_asahi.AsahiAdapterError: the 25G83 recovery image is encrypted; run the installer from macOS 25G83, not 26A434, to use its decrypted copy

Claude on @satchlj's behalf:

The "25G83 recovery image is encrypted; run the installer from macOS 25G83" failure on macOS 27 hosts can be fixed without the host copy. Each AEA in the 25G83 IPSW carries Apple's public key URL (wkms-public.apple.com/fcs-keys/…, no auth), with the archive key HPKE-sealed to it. Unwrapping it is a few lines of CryptoKit or a small stdlib-only Python module, and /usr/bin/aea decrypt -key-value does the rest. On a macOS 27.2 Mac we decrypted 022-22048-093.dmg.aea (BaseSystem) and 094-96734-093.dmg.aea (Neo ExclaveOS) from the IPSW, and both SHA-384s match the BuildManifest digests exactly; the recovery image mounts as sealed 25G83. The stub already downloads those files, so the only new fetch is a 241-byte key. Suggested change: in _use_decrypted_images, decrypt each AEA file in place (via the host temp dir) and require SHA-384 == the identity's manifest digest, keeping the host-copy path as fallback. That also lets collect_firmware read the 25G83 recovery's firmware instead of the host's. I have a small stdlib module and a patch sketch if useful.