Deviations

Apple Silicon Macs have a bespoke boot process that requires special considerations to support alternative operating systems. Currently, Fedora Asahi Remix is installed from macOS via the Asahi Installer, which takes care of preparing the system for the installation, downloading an image for Fedora Asahi Remix and laying it on disk.

The Asahi Installer has also the ability to prepare the system and install the supporting components for a barebone UEFI-enabled system. This could potentially be used in the future to support Anaconda-based installation using regular Fedora Linux install media, but it is not currently supported. The work required is tracked in our issue tracker (Anaconda, disk management tools).

The Asahi Installer does not currently support installing systems using full disk encryption. There is no technical limitation preventing the use of encryption, but it not currently a supported configuration, and the installer does not provide any facility to set it up. A number of approaches to resolve this (including implementing installer suppport) are currently being discussed upstream in the Asahi Linux project.

Fedora Asahi Remix installation images are built using Kiwi from the published Kiwi descriptions.

Because the installation images include additional components that are not part of stock Fedora Linux, they cannot currently be built or hosted on Fedora Infrastructure. We are instead 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.

Fedora Asahi Remix comes out of the box with a 100% Wayland environment. Wayland is required to provide a good experience on this platform, and the legacy Xorg server is not supported. Existing X11 applications are fully supported out of the box thanks to XWayland.

Fedora Asahi Remix includes a number of components that are not part of stock Fedora Linux; these are preinstalled and delivered via our copr repositories.

These components include mesa (source, copr), which is tightly coupled to the kernel AGX driver and in active development, and u-boot (source, copr), which requires patches in the process of being upstreamed.

The kernel is also maintained downstream in a fork of the main kernel-ark repository. The kernel is in active development — while platform enablement for Apple Silicon is in the process of being upstreamed, currently a downstream kernel is required for the best experience.

Finally, a number of packages specific to the Remix implementation are also maintained downstream:

Apple Silicon hardware native page-size is 16K; consequently, this is also the Fedora Asahi Remix default, and we deploy the kernel-16k variant. While a 4K page-size kernel is available in the kernel package, this is completely unsupported and should not be used.

We provide a custom Calamares-based first-boot setup wizard to simplify user onboarding. This only availabe on the Fedora Linux with KDE Plasma edition and is used in place of initial-setup.

Fedora Asahi Remix uses btrfs for all of the deliverables. This matches what Fedora Linux does since Fedora Linux 33, with the exception of Fedora Server, which still defaults to XFS. We use btrfs everywhere because we need the ability to online resize the filesystem, so that it can be expanded to fill the available space on the first boot after the installation, and so that users can shrink it as needed if they want to deploy custom layouts.

Fedora Asahi Remix automatically installs openh264 on the first boot, enabling playback of H.264-encoded content out of the box. This is possible because of the two-step install process — the Asahi Installer downloads the necessary packages from Cisco’s server and makes them available to the deployed system to the perform the installation via a one-off systemd service.