Asahi Linux After 7.2: Pilot M1/M2, Wait on Newer Macs

Linux 7.2 is a meaningful Asahi Linux milestone, but it does not make every Apple-silicon Mac ready for Linux. The August 26 project report describes a new upstream path for CPU idle management, restores critical m1n1 hypervisor capabilities on M4-class security hardware, moves M3 support close to an official release, and records early M4/M5 storage and PCIe progress. Most of those gains are platform-enablement work, not a new end-user support promise.

OpenSourceChoice verdict: Fedora Asahi Remix 44 is worth a reversible pilot on a supported M1 or M2 Mac when its exact hardware matrix and ARM64 application stack satisfy the job. M3 owners should wait for the project's official installer release. M4 and M5 owners should not treat early boot, NVMe or hypervisor progress as desktop support. Keep macOS, a verified backup and an independent recovery path until the Linux installation passes sustained real work.

This is a researched technical analysis of Linux 7.2, Fedora Asahi Remix 44, current Asahi documentation, m1n1 and installer activity, package state, security boundaries and community interest. OpenSourceChoice did not install the Remix, benchmark a Mac, test the experimental M3/M4 work or reproduce the project's hardware results.

Executive verdict

Why this matters now

The timing is unusually strong. Linux 7.2 was released on August 16 and 7.2.1 followed on August 27. Asahi published its platform report on August 26, tying current kernel work to practical Apple-silicon progress rather than merely celebrating a kernel version.

Interest also extends beyond one announcement. The Hacker News discussion reached 395 points and 227 comments, the linked r/AsahiLinux discussion reached 236 votes, and the same report appeared on the Lobsters front page when checked on August 28. These are attention signals, not compatibility evidence, but they establish independent interest across three technical communities.

GitHub daily Trending, Product Hunt, XDA and indexed X searches did not produce a comparable Asahi-specific signal during this run. That does not weaken the event: the primary report, current kernel release, active repositories and several independent discussions make the interest broader than a single viral post.

Duplicate screening found no OpenSourceChoice article about Asahi Linux, Fedora Asahi Remix, m1n1, Linux on Apple silicon or the M1-to-M5 support decision. Existing Apple-silicon articles concern local AI inference, not replacing or dual-booting the host operating system.

The crucial distinction: platform project, distribution and kernel

Asahi Linux is the reverse-engineering and platform-enablement project. It develops and documents the pieces required to boot and operate open systems on Apple silicon: the m1n1 bootloader and developer hypervisor, device trees, kernel drivers, firmware extraction, U-Boot integration, graphics and audio work, plus the installer plumbing.

Fedora Asahi Remix is the recommended end-user distribution. Version 44 combines Fedora Linux 44 with the Asahi-specific kernel, boot, firmware, graphics and audio packages. KDE Plasma 6.6 is the flagship desktop, with GNOME 50, Server and Minimal variants also offered. The official product page currently supports the M1 and M2 families, not every Mac carrying an M-series chip.

Linux 7.2 is the upstream kernel release. Some Asahi support is merged upstream; other pieces remain in linux-asahi, in review or in development. Installing the newest generic kernel does not turn an unsupported Mac into a supported Fedora Asahi system. The distribution must ship a compatible set of kernel, device tree, m1n1, U-Boot, firmware and userspace packages for that exact machine.

That layered ownership explains why a technically impressive report should change a pilot plan without automatically changing the production verdict.

What changed with the Linux 7.2 cycle

A credible route away from the downstream CPU-idle workaround

Apple silicon does not provide the conventional EL3 firmware path that upstream arm64 Linux expects for PSCI power-management calls. Asahi has therefore used a downstream CPU-idle driver that saves state and invokes Apple's deep WFI behavior directly. It works, but the project says that design cannot be upstreamed.

The new proposal keeps Linux at EL2 and lets m1n1 expose PSCI through a UEFI Runtime Service. This preserves the virtualization-capable execution level while giving the kernel a standards-shaped interface for CPU sleep. The m1n1 work exists and the kernel patches were posted as an RFC; this is a promising upstreaming route, not a shipped replacement that operators can count on today.

For M1/M2 users, the immediate implication is continuity rather than a dramatic feature switch: current Fedora Asahi systems retain their existing downstream power-management path. For platform maintainers, the proposal could reduce one long-term divergence from upstream Linux.

M4 hypervisor work survived Apple's newer security architecture

Apple's Secure Page Table Monitor, or SPTM, became mandatory for XNU on M4 and later hardware. That broke the m1n1 development hypervisor's previous method of tracing macOS because m1n1 and SPTM both need control over protected memory behavior.

The Asahi report says m1n1 can now emulate the required GXF and SPRR behavior, load Apple's SPTM and run XNU under observation again. This matters because the hypervisor is a reverse-engineering instrument used to discover how undocumented devices behave. Preserving it keeps future hardware enablement possible.

It is not an end-user virtualization feature. It does not mean an M4 Mac can install Fedora Asahi Remix, run ordinary Linux guests safely or expose a stable production hypervisor. The current M4 feature matrix still marks the normal installer as unavailable and major desktop blocks as not ready.

M3 is close, but “close” is not a release

The report describes working webcams across M3 laptops, microphone work, ACE3 USB-C controller support, stronger display-controller parity and other bring-up progress. The installer repository has also merged M3 device definitions and macOS firmware selection work.

The current public feature matrix remains the decisive gate. It still lists the M3 installer, main display, brightness, USB and GPU work as WIP for important models, with Thunderbolt and several accelerators not ready. The project says it is almost ready to cut an official M3 release, but gives no date.

Do not build an adoption plan around “almost.” Wait until the normal official installer offers the exact machine, Fedora Asahi publishes support, and the feature matrix marks every required device appropriately. Automated daily builds are explicitly untested and are not a substitute for that release.

M4 and M5 progress is bring-up evidence

The project now reports working NVMe on M4 and early M5 systems, PCIe enumeration, an M4 idle-loop workaround and a fix for a multi-core boot crash. Those are foundational achievements. They prove that new Apple generations are not a dead end for the project.

They do not provide display, GPU, keyboard, touchpad, networking, audio, suspend, battery or installer readiness. The M4 documentation still lists no normal installer and mostly TBA device blocks. The report explicitly says M4 and M5 are not ready to enable in the Asahi installer.

For a user choosing an operating system, this is the cleanest possible wait signal.

What a supported M1/M2 system can do—and still cannot promise

Fedora Asahi Remix 44 supports the M1 and M2 MacBook, Mac mini, Mac Studio, iMac and Mac Pro families listed on its current product page. The detailed matrices show mature display, GPU, Wi-Fi, Bluetooth, storage, keyboard, touchpad, camera and audio paths on many models, with important differences by exact chassis and SoC.

The remaining gaps are not cosmetic:

• Thunderbolt remains WIP across M1 and M2 families;
• DisplayPort Alt Mode remains WIP in the platform tables even though specific display paths vary by device;
• Touch ID is still TBA on machines that have it;
• the Neural Engine is not part of the normal supported stack;
• video encoding and ProRes acceleration are not broadly available;
• HDMI output and HDMI audio vary by model and firmware, with audio still described as a preview on supported ports;
• some Mac Pro and Ultra configurations have narrower installer or peripheral coverage.

The August report adds mostly reliable hardware decode for common codecs and describes a VA-API translation path, but says this desktop integration is not shipped by default and does not work with Firefox's decode sandbox. Direct scanout is also blocked by current multi-GPU handling in KWin. Treat both as future efficiency work, not current battery-life guarantees.

The only responsible qualification method is to open the exact M1 or M2 model's feature table and map every required port and peripheral. “M2 supported” is too broad for a desk that depends on a particular dock, display route, HDMI audio path or biometric login.

Installation, updates and rollback

The supported path starts in the Mac's internal macOS installation and uses the official installer. The normal design preserves macOS and configures dual boot. The project FAQ says an internal macOS installation remains necessary to install Asahi, repair or update m1n1 stage 1 and resize an active installation.

The boot chain is intentionally layered:

1. Apple's boot environment selects an OS-specific policy and starts m1n1 stage 1;
2. stage 1 loads the updateable m1n1 stage 2 and device trees from the internal EFI System Partition;
3. U-Boot provides the UEFI-compatible handoff;
4. GRUB loads the Fedora kernel and initramfs;
5. Linux initializes the Asahi drivers and extracted Apple firmware needed by the hardware.

This is not an image that can live only on a USB drive, and it is not container-deployable. The host boot chain, internal storage and machine-specific Apple firmware are part of the product. Official Fedora packages and updates are the operational channel; manually combining upstream m1n1, a generic kernel and random images creates an untested platform.

Uninstalling is still a manual partition operation. A normal installation creates an APFS stub container, an EFI System Partition and the Linux partition. The project warns never to delete the Apple recovery partition and advises against using the graphical Disk Utility for non-trivial cleanup. A team must document the exact reversal before resizing a production Mac.

Security, privacy and trust boundaries

Installing Linux places that OS container in Apple's Permissive Security mode, but Apple silicon maintains policy per OS. The existing macOS container can retain Full Security and FileVault. That isolation is materially better than a machine-wide bootloader unlock, but it does not make the Linux chain equivalent to macOS.

Current Asahi security documentation says the Linux boot path does not yet have an end-to-end Secure Boot or Measured Boot analogue protecting the kernel and initramfs. LUKS can encrypt Linux data, but clear boot components remain a trust boundary. Touch ID and the Secure Enclave are also not available as general Linux authentication and key-protection services.

The installer downloads Apple-provided boot and device firmware that the project cannot freely redistribute, then the running distribution receives normal Fedora and Asahi package updates. There is no Asahi cloud account required for ordinary desktop use, but installation and updates are not offline-only by default.

The main m1n1 and installer repositories showed no published GitHub security advisories and no dedicated SECURITY.md when checked on August 28. Fedora provides a formal security-bug process for packaged components, including private reporting and Bodhi-tracked fixes. An organization should still define who owns Asahi-specific vulnerability monitoring, firmware updates and recovery testing rather than assuming Fedora's package process covers every boot-chain component automatically.

For sensitive use, require:

• LUKS design and recovery keys tested before real data arrives;
• a written explanation of which boot components remain unverified;
• FileVault retained for macOS and recovery access protected;
• no dependency on Touch ID for Linux authentication;
• timely Fedora updates plus monitoring of Asahi, kernel and m1n1 announcements;
• a verified macOS and Linux restore path from separate media and storage.

License, portability and operational ownership

There is no license fee. Linux is GPL-2.0-only, m1n1 uses MIT for its own code with several bundled components under compatible permissive or dual licenses, and the installer is MIT. Fedora packages retain their upstream licenses. Commercial redistribution still requires a component inventory and compliance with each package's notices and source obligations.

Source availability does not remove hardware coupling. The system depends on Apple firmware, boot policies, internal storage layout and Asahi-specific enablement. User documents, Git repositories and standard Fedora application data remain portable; the installed boot environment and hardware integration do not move cleanly to another ARM computer.

Maintainer activity is current: m1n1 1.6.1 shipped August 8, m1n1 received new hardware commits through August 21, the installer merged M3 and m1n1 work in August, and the August 26 report credits several contributors across power, display, audio and new-SoC work. A precise bus-factor number would be speculation, but the specialized reverse-engineering knowledge is clearly concentrated. Organizations should budget for upstream participation or paid engineering help instead of expecting enterprise support terms from a volunteer platform project.

Alternatives to evaluate in parallel

If the requirement is “use Linux tools,” start with a VM. If the requirement is “own the complete host stack and exercise the hardware directly,” a supported M1/M2 pilot can justify repartitioning. Those are different goals and should not be collapsed into one enthusiasm-driven install.

A measurable ten-day pilot

1. Freeze the hardware decision

Record the exact Mac model identifier and SoC. Reject the pilot immediately if the official installer and device matrix do not support that model. Do not substitute a daily build for a missing release.

2. Prove recovery before resizing

Update macOS and its firmware, enable FileVault, complete a verified backup, confirm recoveryOS access and record the current partition map. Keep another device available with the official documentation. Write the uninstall sequence without copying example disk identifiers.

3. Install only through the official path

Use the installer linked by the current Asahi/Fedora site. Select Fedora Asahi Remix 44, not an untested build. Apply all stable updates before adding applications. Record kernel, m1n1, firmware and distribution versions.

4. Test the physical workflow

Exercise cold boot, OS selection, suspend, resume, Wi-Fi roaming, Bluetooth, webcam, microphone, speakers, headphone jack, every display path, every dock, storage hot-plug and sustained battery use. Test both AC and battery operation.

5. Test the application boundary

Inventory every required application as native ARM64, web, Flatpak or emulated. Validate browsers, password managers, VPNs, conferencing, development containers, security keys, printer/scanner paths and proprietary workplace agents. Reject the pilot if a critical x86-only application depends on an unsupported workaround.

6. Exercise failure and restore

Interrupt an update only in a disposable test state, boot the previous kernel, fill a test filesystem, restore representative encrypted data and verify that macOS still boots normally. Rehearse access to recoveryOS and confirm the backup is readable from another machine.

Adopt the Remix for that machine only if:

• every required device works after cold boot and suspend;
• all critical applications have supported ARM64 or proven emulation paths;
• encrypted data and recovery keys work as designed;
• updates and a previous-kernel boot succeed;
• macOS and Linux backups restore independently;
• ten working days finish without data loss, unexplained lockups or a blocking peripheral gap;
• maintenance remains inside an explicit monthly time budget.

Final assessment

Asahi's Linux 7.2 report is important because it addresses the project's hardest long-term problem: keeping an open operating system viable as Apple changes undocumented silicon, firmware and security mechanisms. The PSCI proposal could reduce downstream power-management debt, the restored M4 hypervisor preserves a critical reverse-engineering tool, M3 support is converging, and M4/M5 bring-up has crossed meaningful storage and CPU milestones.

The same evidence demands restraint. The normal Fedora Asahi product still targets M1/M2. M3 is awaiting a real release, while M4/M5 remain development platforms. Hardware enablement, distribution packaging and end-user support are separate gates.

On a supported M1/M2 Mac, Fedora Asahi Remix 44 has earned a serious pilot. On newer Apple silicon, the best adoption decision is to wait for the installer, exact-device matrix and stable packages to catch up—then evaluate the released system, not the promise implied by a boot log.

Sources and verification notes

Project, release, package, repository, security and community state were checked on August 28, 2026. Dynamic discussion and package-channel values are dated observations, not quality guarantees. Technical claims from the Asahi report were not independently reproduced by OpenSourceChoice.

Primary and official sources

• Progress Report: Linux 7.2 — Asahi Linux; James Calligeros; published August 26, 2026; PSCI proposal, M4 hypervisor work, M3 progress, M4/M5 bring-up, video decode and direct-scanout status.
• Linux Kernel Archives — Linux Kernel Organization; Linux 7.2 released August 16 and stable 7.2.1 published August 27, as observed August 28, 2026.
• Fedora Asahi Remix product and device support — Asahi Linux and Fedora Asahi SIG; current Fedora 44 release, install path, supported M1/M2 families, desktop variants and summarized device coverage.
• Fedora Asahi Remix 44 announcement — Fedora Magazine; Davide Cavalca and Neal Gompa; published April 28, 2026; general availability, Fedora 44 base, desktop variants and supported upgrade paths.
• M1 feature support and M2 feature support — Asahi Linux documentation; exact device and subsystem state checked August 28, 2026.
• M3 feature support and M4 feature support — Asahi Linux documentation; installer, display, GPU, peripheral and upstreaming state checked August 28, 2026.
• m1n1 1.6.1 release — Asahi Linux; released August 8, 2026; current upstream bootloader release and M3/M4-era changes.
• m1n1 repository and activity — Asahi Linux; source, license, issues, pull requests and commits checked August 28, 2026.
• Asahi installer M3 support pull request — Asahi Linux; merged August 5, 2026; M3-family device definitions and firmware selection work.
• Fedora m1n1 package state — Fedora Project; Fedora 44 stable/testing versions and package license inventory checked August 28, 2026.
• Asahi boot process — Asahi Linux documentation; m1n1, U-Boot, device-tree and GRUB ownership in the boot chain.
• Apple-silicon platform security — Asahi Linux documentation; boot policies, Linux boot-integrity boundary and LUKS considerations.
• Asahi FAQ and partitioning cheatsheet — Asahi Linux documentation; internal macOS requirement, dual boot, USB limits, manual removal and recovery-partition warnings.
• Asahi distribution guidelines — Asahi Linux documentation; Fedora Asahi as the flagship distribution and requirements for alternative distributions.
• Fedora security bug process — Fedora Project; official vulnerability reporting, tracking and update process for packaged components.

Independent trend context

• Hacker News discussion — submitted August 26, 2026; independent technical-community attention signal.
• r/AsahiLinux discussion — submitted August 26, 2026; independent user and adopter interest signal.
• Lobsters discussion — submitted August 26, 2026; independent Linux, macOS and reverse-engineering community signal.