How it’s made

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.

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.

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, rust-speakersafetyd for speaker protection and rust-triforce-lv2 for microphone support, 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.

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.

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.

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 a full emulation stack which allows running x86/x86-64 applications, including Steam. As of Fedora Linux 42, some of this has been integrated into Fedora Linux proper. As part of this work, we also include rust-binfmt-dispatcher, which provides a simple dispatcher for binfmt_misc that dynamically picks the best interpreter to use at runtime, and prompts the user to install any necessary dependencies if required.

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, libtatsu, 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.

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

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.

We maintain a project planning tracker and a bugs tracker.