Asahi Linux users who installed the macOS 27 "Golden Gate" developer beta now have a direct path to restoring their Linux dual-boot — and the same progress report that announced that fix also disclosed two breakthroughs that would have been technically improbable just months ago: a working custom replacement for Apple's proprietary video decoder firmware, and rapid M3 chip bring-up that includes audio, CPU frequency scaling, and proper efficiency-core scheduling. Linux 7.1 progress report

The project's Linux 7.1 report, published June 30, 2026, confirmed that the macOS 27 boot breakage was caused by a single previously ignored APFS metadata flag. Every version of macOS from 12 through 26 had silently skipped that flag when deciding which volumes to surface in the boot picker. macOS 27 began enforcing it. Because the Asahi Installer had never set that flag on its stub APFS container — the minimal 2.5 GB macOS installation it creates to satisfy Apple's bootloader — the entire Asahi partition vanished from Startup Disk and the boot picker after a macOS 27 upgrade, without any data being destroyed and without any change to the underlying partition layout.

The diagnosis was completed by contributor "chaos_princess," who traced the problem through Apple's macOS Installer code and old recordings from the project's early bootloader research. Setting the flag manually on a test Asahi container immediately made it visible in the macOS 27 boot picker. The fix is now deployed in Asahi Installer version 0.8.3: all new installations set the flag automatically, and affected users can restore access by re-running the installer and selecting the "Fix macOS 27 boot picker compatibility" option. Chaos_princess also developed a repair program that can apply the fix from within a running Linux session, though that tool remains in testing while the team gathers data to confirm it cannot damage filesystems in edge cases.

The regression extended beyond Linux. AppleInsider's early testing confirmed that users running older macOS versions on separate partitions hit the same boot-picker failures, suggesting macOS 27 Beta 1 introduced a broader multi-OS regression rather than a change aimed at Linux. The Asahi team filed a bug report with Apple under reference number FB22994760.

macOS 27 also shipped firmware updates for the System Management Controller, and those updates introduced a second problem. Apple changed a battery management interface from returning a 32-bit integer to returning a single byte. Asahi's Linux power supply driver, which talks to the SMC to read charge state, voltage, and time-until-empty, interpreted the new format incorrectly and in some conditions concluded the battery had failed — triggering an emergency shutdown. A patch backported to Asahi's downstream kernel in version 7.0.12 allows the driver to handle both the old and new SMC firmware interfaces. Users who installed macOS 27 beta before applying that kernel update may have experienced unexpected shutdowns; upgrading to kernel 7.0.12 or later resolves the issue.

The project used the occasion to reiterate that developer betas should not be installed on production machines. Global firmware updates pushed through macOS betas are effectively permanent: reversing them requires a full Device Firmware Update restore of the hardware, which overwrites the Secure Enclave's stored state. The team has sacrificial machines it uses for beta testing specifically to catch this class of breakage before it reaches production users.

macOS 27 Is Now Apple Silicon-Only — Which Makes Asahi Linux's Role Larger

macOS 27 is the first version of macOS to run exclusively on Apple Silicon, dropping support for all remaining Intel Macs. As the Intel fallback disappears, Asahi Linux is now the sole path to native Linux on Apple hardware. The project feeds directly into Fedora Asahi Remix and, through an ongoing upstreaming effort, into the mainline Linux kernel — meaning that every driver Asahi lands upstream becomes part of the Linux distribution every user on every architecture gets.

That structural position makes the macOS 27 boot breakage — quickly diagnosed, patched within weeks, and resolved — more consequential than it could have been. Apple controls the boot chain end to end: the iBoot bootloader, the APFS container-detection logic in the boot picker, and the firmware that runs on every peripheral in the machine. The ABI specification for every aspect of boot and firmware interaction is, as the Asahi documentation puts it, "whatever macOS does." The team has no advance documentation from Apple describing which aspects of the APFS container layout or boot picker detection logic will remain stable between major releases. Each new macOS version is a compatibility audit the project must run on its own.

The fact that the macOS 27 regression turned out to be a single missing metadata flag — rather than a deliberate lockout or an architectural change — is a better outcome than it could have been. The fix is clean, the repair path is straightforward, and the affected users did not lose data.

How macOS 27 Killed Asahi Dual Boot: The APFS Bootable Volume Flag

Apple's boot tooling requires a "valid" macOS installation inside an APFS container before it will surface that container in the boot picker. The Asahi Installer satisfies this requirement by creating a minimal 2.5 GB APFS container with just enough of macOS to convince Apple's tools that a bootable macOS installation exists, with m1n1 as its kernel instead of XNU.

This arrangement worked without modification from macOS 12 through macOS 26 — Apple even fixed several bugs in its boot tools during that period that were only triggered by non-XNU boot objects. The macOS 27 change was subtle: the macOS Installer began writing an APFS container metadata flag marking the volume as bootable before rebooting. Prior macOS versions wrote that flag but the boot picker never checked for it. macOS 27 began checking, and any container that had never had the flag set simply did not appear.

The repair is correspondingly minimal. The Asahi Installer now writes the flag during installation. For existing installations, re-running the installer and choosing the repair option writes the flag to the existing container. Chaos_princess also developed a Linux-native program available in the asahi-fix27 repository that can apply the fix from within a running Linux session, though that tool remains in testing while the team gathers data to confirm it cannot damage filesystems in edge cases.

M3 Bring-Up Accelerates as Apple Keeps Its Hardware Consistent

Apple Silicon's M3 series has been the next target for Asahi Linux's hardware bringup, with multiple contributors driving that work across m1n1 and the Linux kernel. The M3 device support tracker now shows working PCIe, Wi-Fi, Bluetooth, NVMe, keyboard, trackpad, CPU frequency switching, big.LITTLE task scheduling, SMC hardware sensors, and high-quality speaker and headphone jack output in the M3 downstream kernel.

Most of that progress arrived with minimal new code, for a reason that illustrates a foundational Asahi strategy. Apple has not changed how CPU frequency switching works since the base M2 — the same cpufreq driver that handles M1 and M2 machines handles M3 after only Device Tree additions describing the new chip's topology. The audio subsystem is similarly stable: the I2S bus controller, the Numerically Controlled Oscillator, and the speaker and headphone amplifier chips that Apple uses are all unchanged from M1. Adding audio output to M3 required only Device Tree entries and configuration files for Asahi's audio and speaker-safety daemons.

The practical effect of CPU frequency switching and proper big.LITTLE scheduling is significant for battery life. Without working scheduler integration, Linux places all tasks on performance cores regardless of their computational weight; efficiency cores sit idle. With the scheduler now placing background and lightweight tasks on efficiency cores and allowing performance cores to clock down under light load, M3 Linux machines can approach the power efficiency of macOS — a gap that previously made Apple Silicon Macs a less attractive Linux target despite their raw performance.

M3 GPU acceleration remains unavailable, and the Asahi Installer does not yet support M3 machines for general-user installation. The team describes M3 progress as "rapid" and comparable to where M1 support stood at the time of the original Asahi Linux alpha.

Why Asahi Built Its Own Video Decoder Firmware Instead of Using Apple's

The Apple Video Decoder is a dedicated fixed-function hardware block on every Apple Silicon chip. It handles AVC (H.264), HEVC (H.265), VP9, and AV1 video streams in hardware, offloading that work entirely from the CPU — which matters for battery life, thermal performance, and media playback quality at 4K and above.

AVD's firmware architecture is unlike any other block on the Apple Silicon SoC. Most Apple hardware uses RTKit, an RTOS-like framework that presents a standardized interface to the kernel. Some blocks layer a second abstraction called EPIC on top of RTKit. AVD uses neither: the hardware is controlled by a bare ARM Cortex-M3 microcontroller running a proprietary firmware blob that Apple ships inside the AVD kernel extension, bundled with per-SoC configuration data at different offsets for each chip variant.

That bundling created a logistical problem. An upstreamable Linux driver cannot depend on the Asahi Installer knowing the current firmware offset for every AVD variant in every version of Apple's kext. Each macOS update could move those offsets, requiring a corresponding Asahi update. The maintenance burden would be perpetual, and it would make the driver fragile in exactly the way an upstream kernel driver cannot be.

The Asahi team discovered a more elegant solution: the Cortex-M3 on the AVD block executes whatever code it is given from its reset vector, with no signature verification of the firmware blob. Contributor "sofus" — a new project member — wrote a minimal custom firmware blob from scratch. It installs interrupt handlers for the AVD hardware blocks and replays the per-variant hardware tuning values that Apple's firmware applies during initialization. The underlying decoder registers are then programmed entirely by the Linux kernel driver and userspace, keeping the custom firmware stateless and simple.

On top of that firmware, sofus built a working V4L2 driver using the V4L2 Request API — the kernel's stateless codec interface standard. The driver can decode 10-bit AVC/H.264 video at up to 4K resolution and works with any software that implements the V4L2 Request API.

The significance of the stateless design extends beyond what it decodes today. VA-API — the open-source interface that Firefox, Chromium, and media players use to request hardware video acceleration — can be implemented as a layer on top of V4L2. Vulkan Video, the Khronos standard for GPU-accelerated codec operations, can be layered on top as well. Neither VP9, HEVC, nor AV1 decoding is implemented yet, and device-specific hardware quirks require further testing before AVD support ships to general users. But the architectural groundwork, which required reverse-engineering the AVD hardware block using a Cortex-M3 QEMU emulator and prior work by contributors Jamie, R, and Eileen on decoder instruction formats, is now complete.

This approach — writing replacement firmware rather than extracting or wrapping Apple's — is also the pattern the project intends to apply to future Apple hardware blocks whose firmware is embedded in kexts rather than shipped as standalone binaries. The full firmware and driver source is available in the avd-fw firmware repository.

How Do I Tell Whether macOS 27 Beta Broke My Asahi Linux Installation?

If you installed the macOS 27 developer beta before approximately June 20, 2026, and you cannot see your Asahi Linux partition in Startup Disk or the boot picker, your partition is intact — no data was lost. Open a macOS terminal and re-run the Asahi Installer; choose the "Fix macOS 27 boot picker compatibility" option when it appears. After the installer completes, Asahi should appear in the boot picker again.

If you are running a kernel version earlier than 7.0.12, also check whether you have experienced unexpected shutdowns. The SMC battery interface change in macOS 27 beta can cause the power supply driver to misread battery status and trigger emergency shutdowns. Upgrading to kernel 7.0.12 or later resolves that separately.

Frequently Asked Questions

How do I fix my Asahi Linux installation after installing macOS 27 beta?

Re-run the Asahi Installer from within macOS and select the "Fix macOS 27 boot picker compatibility" option. This writes the APFS bootable volume flag that macOS 27 began requiring but that older Asahi installations never set. The fix does not delete or reformat any data. If you also experienced unexpected shutdowns, upgrade to Asahi kernel version 7.0.12 or later, which handles both the old and new SMC battery firmware interfaces.

Why did macOS 27 break Asahi Linux but not erase my data?

The breakage was not a partition deletion — it was a boot-picker visibility failure. macOS 27's boot picker began requiring a specific APFS container metadata flag to surface volumes in the OS selection list. Asahi's installer had never written that flag, because no prior macOS version checked for it. The partition, the m1n1 bootloader, and the Linux filesystem all remained intact on disk; macOS 27 simply stopped listing the container as a valid boot target. Setting the flag in place is a metadata-only operation that does not touch the Linux data.

What does Asahi Linux's custom AVD firmware mean for video playback on Apple Silicon?

The working V4L2 driver for AVC/H.264 decoding is the first step toward hardware-accelerated video playback on Apple Silicon Linux through an upstreamable, open-source path. Once the driver is ready for general users and extended to HEVC and AV1, applications that use VA-API — including Firefox, Chromium, and GStreamer-based media players — can request hardware video acceleration from the chip rather than decoding in software on the CPU. The immediate practical benefit is reduced CPU usage and power draw during video playback, which matters most on MacBook models where the fan and battery are most constrained.

Will macOS 27's final release in autumn 2026 break Asahi Linux again?

Asahi Installer v0.8.3 and later now set the APFS bootable volume flag on all new and repaired installations, so the specific flag-enforcement change in macOS 27 should not re-create the same problem at final release. Whether the final macOS 27 release introduces new boot-chain changes that affect Asahi is unknown — the Asahi team has no advance documentation from Apple describing which aspects of the boot stack will remain stable. The project's practice is to run compatibility checks against each new major macOS release before recommending upgrades to users.