Anyone dual-booting Asahi Linux on Apple Silicon who installed the macOS 27 Golden Gate beta ran into the same thing: the Linux partition vanished from both Startup Disk and the boot picker, with no way to select it. The Asahi Linux project publicly warned people not to upgrade while the beta was active. Since then, the project has shipped an actual fix, not just a workaround, and it's worth understanding the difference before you do anything to your partitions.
What happened, and why
Apple's boot picker and Startup Disk app on Apple Silicon Macs decide what counts as a "valid" macOS installation by checking for a specific flag inside the APFS container on that volume. Through every macOS version from 12 up to 26, Apple's boot tooling simply ignored whether Asahi's own containers carried that flag or not, and the Asahi partition showed up anyway. With macOS 27, Apple's boot picker started actually checking for it, and Asahi's installer had never been setting it, so previously working Asahi installs suddenly became invisible.
No data was lost at any point. This was consistently confirmed by Asahi Linux's own team and independent coverage: the partition and everything on it remain exactly where they were. The bug is entirely about whether Apple's boot picker recognizes the partition as something it's allowed to boot into, not about the partition's contents.
The real fix: Asahi Installer 0.8.3 and later
Asahi's development team traced the cause to a single, specific, previously unused APFS metadata flag. Once identified, the fix was straightforward: set that flag on the existing Asahi container, and Apple's macOS 27 boot picker recognizes it immediately, with no reinstall of Linux required. This fix shipped in Asahi Installer 0.8.3, released in early July 2026, and is included in every version since.
This is a genuine fix, not the "boot from an older macOS volume instead" workaround that circulated when the bug was first discovered. Applying it restores the partition's visibility directly in macOS 27's own boot picker.
How to apply the fix
- Boot into macOS (using whatever volume you currently can, including the older-macOS workaround below if that's your only option right now).
- Open a Terminal and re-run the Asahi Installer. If you don't have the latest version, download it fresh from the Asahi Linux project's official site rather than reusing an old copy.
- When the installer runs, it should now present an explicit "Fix macOS 27 boot picker compatibility" option specifically for existing installs affected by this issue. Choose it.
- Once it completes, open Startup Disk, or hold the power button to bring up the boot picker, and your Asahi partition should appear again.
This does not touch your existing Linux installation or its data. It only updates the APFS metadata flag that Apple's boot picker checks, which is the entire root cause.
The older workaround, if you need it right now
If you haven't yet updated your Asahi Installer and need access to Linux immediately, the original workaround still applies and remains safe:
- Boot into macOS using any volume running macOS 26 (Tahoe) or earlier that you have available, whether on the same disk or an external drive.
- Open System Settings > General > Startup Disk, or the equivalent Startup Disk app, and set that older macOS volume as the default.
- Restart. Because Apple's boot picker is itself an app that runs inside the recovery environment of whatever the default boot volume is, running it from an older macOS version restores the old, more permissive detection logic, and your Asahi partition becomes selectable again.
This gets you booting into Linux again without touching anything, but it's a workaround, not a fix: it only works for as long as you keep an older macOS volume around and set as default. Applying the actual Asahi Installer fix above is the better long-term move.
What this means for a new Asahi install
If you're setting up Asahi Linux fresh rather than fixing an existing install, this is no longer something you need to think about: current versions of the Asahi Installer set the required APFS flag automatically on every new installation, so new installs are already compatible with macOS 27's boot picker from the start.
Does the public release of Golden Gate still have this problem
The underlying boot-picker behavior that caused this, Apple's stricter APFS flag check, is a change to macOS 27 itself, not a beta-only artifact, and it carried through to the public release on September 14, 2026. The difference now is that Asahi's own fix exists and is mature: anyone running a current Asahi Installer version, or applying the fix to an existing install, is unaffected by the underlying macOS behavior. If you're dual-booting and haven't touched your Asahi Installer since before July 2026, update it before or immediately after installing Golden Gate.
The short version
- macOS 27's boot picker started checking an APFS flag that older Asahi installs never had set, making the Linux partition invisible, with no data loss.
- Asahi Installer 0.8.3 and later includes a direct fix: run it, choose "Fix macOS 27 boot picker compatibility," and the partition reappears in macOS 27's boot picker.
- If you need Linux access before applying the fix, setting an older macOS 26 or earlier volume as the default Startup Disk restores visibility as a temporary workaround.
- New Asahi installs set the required flag automatically and are unaffected from the start.