Asahi Linux 7.1: Boot Flags, Firmware ABI Changes, and M3 Enablement

A “missing boot option” moment on Apple Silicon

Picture this: you reboot your Mac, hold the power button, and—where you expected to see Asahi Linux in the boot picker—there’s nothing. The partitions may still be there, your data may be intact, and yet Apple’s boot UI behaves like Asahi never existed. That’s exactly the kind of mystery the Asahi Linux 7.1 progress work set out to solve.

This release narrative is really about interfaces: how Apple decides something counts as a bootable macOS installation, how firmware describes hardware behaviors to the operating system, and how new Apple Silicon generations can become supported without rewriting everything from scratch.

Why the installer creates a tiny “fake” macOS

On Apple Silicon, the boot picker and Startup Disk don’t look for “Linux partitions” in the usual sense. Instead, they rely on Apple’s own expectation of what a valid macOS installation looks like.

At a high level, Asahi Linux uses a strategy that makes Apple tooling cooperate with it. The installer creates a small APFS container—an APFS container is a grouping of storage volumes under Apple’s APFS filesystem—containing just enough macOS-like metadata and components for Apple’s boot tools to accept it. This tiny container is meant to be considered bootable.

There’s another important term here: m1n1. m1n1 is a lightweight firmware/monitor layer Asahi uses to help initialize and bridge hardware bring-up so Linux can run on Apple Silicon. The installer arranges the bootable container so that Apple’s bootloader will hand off in a way that launches the m1n1 kernel.

The key point is that this arrangement worked smoothly from macOS 12 up through macOS 26. But then Apple introduced a developer beta—macOS 27 Golden Gate—that changed the expectations in subtle ways.

The APFS “bootable flag” Apple suddenly started respecting

The investigation started with a comforting observation: upgrading to macOS 27 didn’t delete Asahi’s partitions. Using macOS’s diskutil tool (a command-line utility for managing disks), the team could verify that the Asahi-related storage remained present.

Next, they did an isolation check: the same machine still booted Asahi correctly when using boot tooling from a different macOS install (macOS 26). That strongly suggested the Linux side wasn’t broken; the change lived inside Apple’s macOS 27 boot picker validation.

So what changed? The macOS installer was found to set some APFS metadata right before reboot. In plain terms, APFS can store not just files and directories, but also internal per-volume properties that other system components consult.

Within that metadata, there was a flag that marks the APFS volume as bootable. Before macOS 27, Apple’s boot tooling effectively ignored that flag. After macOS 27, it started honoring it.

The fix, therefore, was not to rewrite the boot chain from scratch, but to make the Asahi APFS container set the same “bootable” marker that macOS installers set.

What the manual fix teaches us

After setting the flag manually on an Asahi APFS container, the boot picker began listing Asahi again on macOS 27. That result is a great lesson for anyone new to low-level platform work: when a system “forgets” a boot target, it’s often a metadata contract mismatch, not a destroyed partition.

Making it reliable: installer updates and “compatibility mode”

Once the cause was understood, Asahi moved to prevent recurrence.

New installs now set the bootable flag automatically as part of the installer process. For existing installs—especially those created when macOS 27 betas were involved—Asahi also added an installer mode designed specifically to patch older setups.

This compatibility mode matters because the problem wasn’t about data loss, but about a missing bit of expected metadata. In other words: your filesystem wasn’t “broken,” but Apple’s boot picker couldn’t be convinced it should treat the target as bootable.

Testing the “fix27” program: changing the system without risking your data

A major theme in this release is careful rollout. There’s mention of a Linux-run program intended to repair existing macOS 27 boot picker compatibility issues. The important engineering tension here is real: modifying APFS metadata incorrectly could endanger filesystems.

So rather than enabling automatic changes immediately, the workflow emphasizes collecting evidence. The safe principle is: build a fix, run it in a controlled way, confirm it behaves correctly on real systems, then widen deployment.

Even experienced engineers get cautious here, because firmware- and filesystem-adjacent changes can fail in surprising ways across different hardware states.

Firmware ABI changes: when “32-bit” becomes “one byte”

The second big story in 7.1 is a firmware interface change introduced alongside macOS 27.

To talk to Apple’s battery management and other sensors, the Linux power supply driver communicates with the SMC. The SMC—System Management Controller—is a microcontroller responsible for things like battery status reporting and charging behavior.

The driver reads battery data (charge state, voltage, time remaining, battery health) and also configures charging thresholds meant to prolong long-term battery health.

Now here’s the complication: Apple’s firmware changed one battery-related interface return type—from returning a 32-bit integer (a number represented in 32 bits of data) to returning a single byte (8 bits).

This kind of change is often summarized as an ABI change. ABI stands for Application Binary Interface: it’s the “data format contract” between compiled code (the kernel driver) and the firmware function it calls.

Why ABI mismatches can become dramatic

A driver expecting a 32-bit return value but receiving an 8-bit value can misinterpret the result. Under certain conditions, the driver may read garbage and conclude the battery has failed.

When that happens, the system can trigger an emergency shutdown—a safety behavior designed to protect the machine if battery readings suggest something is dangerously wrong.

Asahi’s downstream kernel patches address this by teaching the power supply driver to handle both firmware ABIs: the older 32-bit behavior and the newer 8-bit behavior.

The practical outcome is that Linux stays stable across macOS 27 firmware updates.

Developer betas aren’t “just early versions”

A crucial message is that beta operating systems come with risks beyond software bugs.

Two reasons stand out:

1. Global firmware updates: when macOS updates firmware, that firmware lives at the machine level. Unlike many software packages, firmware rollback can be difficult.
2. Hardware interface shifts: as seen in the battery return-size change, the OS update can alter the meaning of the data the kernel receives.

Asahi emphasizes using sacrificial machines for testing—machines set aside specifically so failures don’t compromise personal data or expensive hardware.

M3 progress without starting from zero: design stability pays off

The rest of the 7.1 progress report reads like a story about engineering leverage: not all hardware changes are disruptive.

A few core components involved in audio and CPU management stayed stable across Apple Silicon generations.

Audio: I2S, stable controllers, and fewer changes

Audio support often depends on how data moves between chips. One common pattern in the industry is I2S—a bus (a communication path between chips) optimized for streaming audio data, and built on top of I2C-style signaling conventions.

Asahi’s audio work benefited from the fact that Apple’s I2S controller didn’t change significantly since M1. Additionally, the timing source used for audio—Apple’s Numerically Controlled Oscillator (NCO)—also remained unchanged.

An NCO is a mechanism that generates precise frequencies by using numerical methods, which matters because audio data rates and sample clocks must stay accurate.

With stable audio controller behavior, the work for M3 speaker/headphone support leaned on configuration changes (like device tree additions) rather than deep driver rewrites.

CPU frequency switching and big.LITTLE scheduling

For performance and power efficiency, modern SoCs manage how fast CPUs run. CPU frequency switching adjusts core clock speed based on workload. When done well, it saves energy during idle periods and speeds up under load.

Also, many systems use a design often described as big.LITTLE: a mix of performance-oriented cores (“big”) and efficiency-oriented cores (“LITTLE”). Proper scheduling places tasks on the most appropriate cores.

Asahi reports support for both CPU frequency switching and “proper big.LITTLE task scheduling” on M3 machines, again largely through device tree configuration and existing driver logic.

The implication for you as a reader is reassuring: when platform interfaces stay consistent, enabling new hardware generations can be a configuration-and-validation problem rather than an all-new driver project.

More M3 blocks working in Linux

Beyond audio and CPU management, Asahi’s progress also notes working support for major platform components: PCIe (the high-speed expansion bus), Wi‑Fi and Bluetooth, NVMe (non-volatile memory storage), and input devices like keyboard and trackpad.

This work is attributed in part to community contributions from developers running m1n1 and Linux on M3 series hardware. That matters because early platform bring-up is often accelerated by hands-on experimentation.

Firmware frameworks: RTKit and EPIC layers

Finally, the 7.1 report touches firmware complexity.

Many hardware blocks depend on opaque firmware blobs—prebuilt binary code that runs on a separate controller or bootstrapped environment. Linux can interact with these blocks only through the interfaces they expose.

Apple’s firmware ecosystem includes RTKit, described as an RTOS-like framework. An RTOS (Real-Time Operating System) emphasizes predictable timing. In practice, RTKit provides a standardized-ish interface so the kernel can ask different hardware modules to perform tasks.

But not every subsystem is uniform. Some blocks use RTKit plus additional abstraction layers (for example, EPIC built on top of RTKit). Other components—like certain third-party Wi‑Fi/Bluetooth chipsets—rely on separate firmware supplied by the vendor.

This layered structure is one reason why “supporting hardware” can be both powerful and slow: the kernel may need to speak the right protocol at the right boundary, and changes at any layer can ripple upward.

Conclusion: 7.1 is about contracts, not just code

Asahi Linux 7.1 progress centers on a repeatable theme: the platform is governed by contracts between layers.

Apple’s boot picker depends on APFS metadata flags; firmware depends on ABI-compatible data formats; power management depends on accurate interpretation of sensor returns. Meanwhile, the M3 enablement shows the other side of the coin—when core controllers remain stable, configuration changes and scheduler logic can unlock new hardware without reinventing everything.

In the end, 7.1 isn’t only a release of features. It’s a demonstration of disciplined systems engineering: observe the failure mode, identify the interface mismatch, patch in a compatibility-minded way, and roll forward without risking your filesystem or your hardware.