Building an Arch Linux aarch64 port for Holo Core
-->
-->
-->
About
Who we are
Our expertise
Our work
Open Source
Our ecosystem
Services
Guide
Train
Build
Integrate
Optimize
Maintain
Industries
Automotive
Digital TV
Silicon
OEM
VR/AR
News & Blog
Careers
Contact
About
Services
Industries
News & Blog
Careers
Contact
-->
+44 (0)1223 362967
+1 514 667 2499
contact@collabora.com
-->
Home "
News & Blog "<br>News & Events "
-->
Home<br>News & Blog<br>News
Building an Arch Linux aarch64 port for Holo Core
-->
17/07/2026<br>-->
Posted on 17/07/2026 by Denis Pynkin
-->
Building an Arch Linux aarch64 port for Holo Core
Posted on 17/07/2026 by Denis Pynkin<br>--><br>Denis Pynkin<br>July 17, 2026
Share this post:
-->
Reading time:
Valve uses an adapted version of the Arch Linux distribution in its products. At Collabora we have been working with Valve on Holo Core, a pure aarch64 port of Arch Linux to be used as the basis for the OS running on the Steam Frame, which uses an aarch64 CPU. Since Arch Linux does not officially support the aarch64 architecture, we have needed to work on the tooling and CI infrastructure to make this possible.
In this first step toward opening up the work on the aarch64 port, we are publishing prepared binaries, their sources, and the development containers we've built from them, allowing anyone to begin to explore the port and experiment with Arch Linux on aarch64:
Sources: https://gitlab.steamos.cloud/holo/holo-core-aarch64-preview
Binary packages: https://holo-packages.steamos.cloud/holo-core-aarch64-preview/mash-20251118
Docker container: registry.gitlab.steamos.cloud/holo/holo-core-aarch64-preview/base-devel
These published artifacts correspond to a subset of packages from a snapshot of the Arch Linux “state” repository with commit 97c0a0b47d15 with any modifications needed to build for the aarch64 architecture.
Behind the scenes
At this stage, we have not rebuilt the entire world (all the packages available in the Arch Linux repositories). Our initial goal is to provide the set of packages required for development and image creation for the Steam Frame. Even when limiting ourselves to this subset of Arch Linux packages, including these packages along with their runtime and build dependencies still results in several thousand packages.
The idea behind this port is much more complex than simply recompiling and installing selected packages for the aarch64 architecture. We are trying to solve two main problems:
Build binaries from recent Arch package versions for a foreign architecture.
Create a CI system capable of building binaries for a distribution that currently has no CI infrastructure of its own. As Arch Linux is a rolling-release distribution, enable this CI system to determine the correct dependencies to use as the distribution updates
Challenges
It is more or less known how to create a port: initial cross-compilation, bootstrap preparation, package rebuilds, and so on. However, it becomes much less obvious when you want the entire process to be reproducible from scratch in CI.
We also have to calculate the correct build order for the dependency tree. Here we encounter the first caveat: we cannot rely entirely on the state Git repository, which tracks the history of the Arch Linux package repositories. In many cases, batches of packages are pushed into the repository in an order that is not suitable for rebuilding, meaning that we have to correct the ordering ourselves to construct a valid build sequence.
Another major challenge comes from the nature of Arch Linux's rolling-release model. While we are preparing the initial port, the packages and their dependency chains keep moving forward, often several steps ahead of the state we had been working on. During the development process, we have already stepped forward to newer snapshots a few times; however, we cannot simply skip intermediate versions because of package interdependencies. Intermediate package versions are often required to build later versions, which in turn are needed for other packages' versions. For example, if you need to rebuild rust 1.91, you must first have 1.90 available, which itself requires 1.89, and so on, all the way back to the version used during bootstrapping. The CI tooling that we have been creating must take this into account.
A similar issue arises with SONAME transitions, especially for libraries that are part of the build infrastructure itself, such as icu or gpgme, both of which are required by pacman. In this instance, the package manager used to perform the build depends on the old library version, while the package manager being produced by the build must depend on the new one; thus, both must be available when the build is performed.
Time is the biggest enemy when trying to replay a historical build sequence. If you try to catch up with Arch Linux by rebuilding packages from months or years ago, you will inevitably discover that the...