How it’s made

This page attempts to document how Fedora Asahi Remix is put together. Useful prerequisites to read before this:

Throughout this document, components hosted outside of Fedora infrastructure will be marked with a ⚠️.


The Fedora Asahi SIG maintains a number of packages that are required for plaform enablement, integration and implementation. As many of these as possible are maintained in Fedora itself under the asahi-sig FAS group. This isn’t an option for some packages ⚠️, and those are maintained in copr instead, under the @asahi group.


Fedora Asahi Remix is installed by the asahi-installer, which runs from macOS and guides the user through the installation process. The installation involves resizing partitions, installing a stripped-down standalone copy of macOS and laying the Remix image on disk; the system is then rebooted into recoveryOS, where the the installer second stage takes over and guides the user to adjusting the security settings for the standalone macOS and replacing its kernel with the bundled m1n1 (which comes from the m1n1-stage1 package), which will later act as a first stage bootloader for the installed system.

The installer is delivered in asahi-installer-package; its build process relies on two prebuilt macOS binary artifacts (Python and libffi), which have received a FESCo exception to the prebuilt policy. The asahi-installer source package also provides python3-asahi_firmware, which is used by asahi-scripts for firmware management in userspace.

Boot process ⚠️

After the installation the system boots into Linux by default. The boot flow starts with m1n1; its stage 1, which was placed by the installer, is responsible for finding and executing the stage 2 from the EFI partition. The main difference between stage 1 and stage 2 is that the former is rarely updated (as the process requires running the installer again and going through recoveryOS), while the latter is distributed by Fedora in the m1n1 binary package and updated together with the distro (via update-m1n1 in asahi-scripts).

Once it’s done with platform initialization, m1n1 will find u-boot ⚠️ and pass control to it. U-Boot acts as the third stage bootloader, performing some more platform initialization and providing a minimal preboot environment. In the default flow, U-Boot is setup to provide an emulated UEFI environment, which is used to load GRUB. From here on the boot flow is the standard Fedora Linux one.


Apple Silicon machines rely on a large number of firmware blobs to work. Firmware collection is implemented in asahi-installer. Firmware is then loaded as needed in the initramfs via dracut-asahi, which is part of asahi-scripts. An asahi-fwupdate package is also provided (also from asahi-scripts) to apply firmware updates on the Linux side in case new firmware becomes available.

The Asahi Linux project has in-depth documentation of the firmare provisioning process, which is meant to be standardized between distributions.

Kernel and userspace drivers ⚠️

The kernel package ⚠️ for Fedora Asahi Remix is maintained as a downstream fork of kernel-ark, including patches from the upstream Asahi Linux tree. Asahi Linux also maintains a detailed tracker of the upstreaming status for every component.

The GPU driver also has a userspace counterpart in the asahi driver in mesa ⚠️. This is tightly coupled with the AGX driver in the kernel.


Apple Silicon machines have a complex speaker setup that requires speaker protection to be safe and a dedicated DSP chain to sound good. This is implemented by asahi-audio, which leverages rust-bankstown-lv2 for bass enhancement and rust-speakersafetyd for speaker protection, plus alsa-ucm-asahi and rust-alsa. PipeWire and WirePlumber have also been enhanced to create the correct virtual audio devices and present them to the user in an understandable way.

Touch Bar

Some Apple Silicon Macbooks have a Touch Bar taking the place of the first row of the keyboard. On Linux this is presented as a regular (albeit odd-sized) display, and it can be driven as such. To make it useful rust-tiny-dfr renders a set of function keys on it, mimicking what would be available on a physical keyboard.

Media playback and codecs

Fedora Asahi Remix ships with out of the box support for H.264-encoded content. This is implemented by having asahi-installer download the RPMs and putting them onto the EFI partition; a systemd unit in fedora-asahi-remix-scripts then installs them on the first boot.

We also provide widevine-installer to automatically enable Widevine playback by downloading and extracting the necessary bits from a ChromeOS image.

NVram and default boot entry

Apple Silicon systems store some low-level system configuration settings in NVram. We provide a set of packages to interact with this, but they are not installed by default as there is currently no safe way to enforce a single writer (concurrent writes can be racy and lead to corruption).

The default boot entry can be changed using rust-asahi-bless (a CLI tool) or rust-startup-disk (a GUI). Two experimental tools are also provided to sync Bluetooth (rust-asahi-btsync) and Wi-Fi (rust-wifisync) settings between macOS and Linux. All of these tools are implemented on top of rust-apple-nvram and rust-asahi-nvram.


We provide the box64 emulator, which is able to run some x86_64 programs.

Apple ecosystem integration

We maintain packages for the libimobiledevice stack, which implements protocols and tools to communicate with Apple devices. Among other things, this includes idevicerestore, which can be used to DFU an Apple Silicon laptop from another Linux system (instead of having to rely on another Mac with Apple Configurator 2). Other components of this stack are libimobiledevice, libimobiledevice-glue, libplist, libusbmuxd, and usbmuxd.

We also maintain a handful of ecosystem-related tools: apfs-fuse is a work-in-progress read-only userspace driver for APFS filesystems, and uxplay is an AirPlay2 implementation.

Remix-specific plumbing ⚠️

We maintain a number of packages that are specific to the implementation of the Remix:

  • asahi-platform-metapackage (source, copr) provides a metapackage that declares all other Asahi platform package dependencies

  • asahi-repos (source, copr) provides Yum repository definitions for our copr-provided packages

  • calamares-firstboot-configs (source, copr) provides the Calamares configuration used for the first-boot installer on the KDE edition

  • fedora-asahi-remix-appstream-metadata (source, copr) provides the Remix-specific AppStream metadata that is required to support updates between major releases via PackageKit

  • fedora-asahi-remix-release (source, copr) provides the distribution branding for the Remix; Fedora Asahi Remix has trademark approval from the Fedora Council to use its current name and branding (which includes the use of the Fedora logo)

  • fedora-asahi-remix-scripts (source, copr) provides various utility scripts and systemd services used in the Remix


Installation images ⚠️

Fedora Asahi Remix installation images are built using Kiwi from our Kiwi descriptions and are outside of Fedora Infrastructure.

We are using AWS EC2 instances to perform builds and upload them to AWS S3, triggered by an AWS Lambda (which runs daily). We use another Lambda to generate the manifest for these daily builds to be consumed by the Asahi Installer.

We host our website on AWS S3, fronted by AWS Cloudfront; we use another Lambda to handle CDN invalidation. The website is automatically deployed from its GitLab repository; this is also where the manually-maintained installer manifest for release images (as opposed to dailies) lives. The Lambdas are also automatically deployed via Gitlab Pipelines using AWS Chalice.


Our documentation site is generated with Antora from its repository, and is integrated into the Fedora Docs Website.

Project and bug tracking

We maintain a project planning tracker and a bugs tracker.