Asahi Linux, the open source project that ports Linux to Apple Silicon (Apple's custom Mac chips), traced the silent regression to one disk volume marker Apple's installer now sets, and shipped both an automatic fix and a repair installer that restores the boot entry without…
Apple's macOS 27 "Golden Gate" developer beta has an unwelcome surprise for anyone running Linux on a Mac: the Linux installation simply vanishes from the Mac boot picker after the upgrade, with no warning and no data loss. Asahi Linux, the community project that ports Linux to Apple Silicon Macs, documented the regression in its June 2026 7.1 Progress Report and shipped a fix within days.
The cause, the project found, is a single, undocumented behavior change inside Apple's own installer. The 7.1 report walks through the chain: Asahi relies on a small stub macOS partition (technically an APFS container shim, a tiny fake macOS install whose only job is to satisfy Apple's boot tooling) to let the Mac's boot picker accept the project's m1n1 bootloader. That trick had worked unchanged from macOS 12 through macOS 26 because Apple previously tolerated raw non-Apple binaries in the boot path and even fixed bugs it encountered while doing so. macOS 27's installer now writes a "this volume is allowed to boot" marker (Apple's term is the volume-bootable flag on the APFS filesystem) onto every partition it creates, and the boot picker has started checking for that marker before listing a volume. The shim, which Asahi created years before that marker became mandatory, suddenly stopped qualifying. Hacker News users on the report's discussion thread reported finding, after upgrading to the Golden Gate beta, that their Linux boot entry was simply gone.
The fix shipped in two parts. For anyone running the macOS 27 beta alongside Asahi 7.1, a new repository, asahi-fix27, provides a repair installer that re-creates the boot entry in place; existing data, the Linux install, and the macOS partition are all left untouched. New Asahi installs on the beta set the required marker automatically, so the broken state only reappears if a user wipes and reinstalls Apple's beta on top of a working Asahi setup. m1n1, the bootloader Asahi uses to talk to Apple's silicon, also moved to v1.6.0 alongside the report, carrying the support needed for the repair flow. The 7.1 release is also the milestone the report flags as M3 Macs moving materially closer to full support, with progress on GPU and display bring-up (items that have been the long pole of M3 work) listed as small rather than structural.
Users broken by the beta do not need to reinstall. The Asahi installer now ships a repair mode; running it against an existing Asahi install re-creates the boot-volume marker Apple's installer now requires and puts Linux back in the Mac boot picker. The only known way users end up stuck again is by re-running Apple's macOS 27 beta installer over the top of a working Asahi setup, which strips the marker back out.
Beyond the incident, the report offers a wider lens on how Asahi has to ship Apple-Silicon Linux at all. On the Hacker News thread, project lead Hector "marcan" Martin reiterated a position he has staked out before: that Apple's silicon Macs are unusually open by hardware standards, with resident supervisor firmware and tooling the project has been able to read and rebuild against, while some of the Intel and AMD laptops the Free Software Foundation currently endorses ship with secret DMA blobs that resist the same inspection. That argument does not change the impact of the macOS 27 break, but it explains why a community project can ship boot-path fixes for unreleased Apple operating systems in the first place.
Independent trade-press coverage of the 7.1 release has framed the cycle primarily as an M3-progress story, in line with the wire-level headline. The boot-picker regression and the asahi-fix27 repair installer are the part that hits existing users today, and the part most likely to be missed by readers who only see the version-bump framing.
What's next: watch the macOS 27 beta cycle. If Apple ships a release build of Golden Gate to the public without either documenting the new disk-volume marker requirement or relaxing the check, every Asahi user who installs it without first running the repair installer will hit the same vanished-boot-entry state. New Asahi installs and the repair flow both expect to handle that case, but the longer-term question is whether Apple treats the new marker as a permanent contract for third-party boot volumes or quietly reverses course before release.