If you're running Arch Linux ARM (ALARM) on a Raspberry Pi 5 and you've come across ports.archlinux.page/aarch64, you're probably wondering: is it time to switch? I spent a day poking at this — comparing packages, building VM images, and getting into a deeply personal fight with GRUB. Here's what I learned.
So What Actually Is This Port?
First things first: despite living under archlinux.page, this port is not official. The page says so right at the top, in a yellow warning box that I'm sure everyone reads carefully:
⚠️ There is currently no proposed RFC for this architecture. Support is primarily provided by other Arch Linux users (i.e. not Staff).
I went and checked the official Arch mirrors — geo.mirror.pkgbuild.com and friends — and sure enough, there's no aarch64 directory on any of them. Only x86_64. So much for "official."
The whole thing is distributed through the community-run drzee.net infrastructure on AWS S3. One visible contributor here is bschnei, who maintains the linux-rpi5 package. Three repos:
- core — 264 packages
- extra — 13,326 packages
- forge — 25 packages for stuff that doesn't exist upstream (RPi5 kernel, Electron, Kodi, etc.)
The key difference from ALARM: these packages are rebuilt straight from upstream Arch PKGBUILDs — the exact same source as x86_64. ALARM maintains its own fork with ARM-specific patches. That matters, and I'll get to why.
One catch: ARMv8.2+ only. RPi 5 is fine. RPi 4 and older? Out of luck.
Are the Packages Actually Newer?
This is what I really wanted to know. ALARM has a reputation for falling behind on core packages like glibc. I figured the drzee port would be noticeably ahead.
I was wrong.
| Package | x86_64 Arch | ALARM | drzee aarch64 |
|---|---|---|---|
| gcc | 15.2.1+r604 | 15.2.1+r604 | 15.2.1+r785 |
| glibc | 2.43+r5 | 2.43+r5 | 2.43+r5 |
| rust | 1.94.0 | 1.94.0 | 1.94.0 |
| go | 1.26.1 | 1.26.1 | 1.26.1 |
| python | 3.14.3 | 3.14.3 | 3.14.3 |
| systemd | 260.1 | 260 | 260.1 |
| docker | 29.3.0 | 29.3.0 | 29.3.0 |
| git | 2.53.0 | 2.53.0 | 2.53.0 |
They're basically identical. The only real difference: drzee's gcc has a slightly newer git snapshot (r785 vs r604), which at least confirms it rebuilds independently. ALARM's systemd was one point release behind. Riveting stuff.
A broader scan of all ~250 packages on my Pi found just 4 differences: archlinux-keyring, leancrypto, libsysprof-capture, and pacman-mirrorlist. Not exactly the freshness revolution I was expecting.
So the point of this port isn't that it's fresher right now — it's the approach. Since it rebuilds directly from upstream without ARM patches, it shouldn't get stuck when glibc or gcc bumps a major version. ALARM has historically had rough patches during those transitions. Whether that's still a real concern or just old war stories at this point is debatable.
What About RPi 5 Support?
The [forge] repo has the basics:
linux-rpi5— RPi Foundation kernel (it explicitlyReplaces: linux-rpi-16k)linux-firmware-rpi5— WiFi and Bluetooth firmwarerpi5-eeprom— EEPROM bootloader updatesraspberrypi-utils— vcgencmd and other Pi tools
There is no raspberrypi-bootloader package in the drzee repos, which made me assume I'd have to manually provide start4.elf and fixup4.dat. That turned out to be wrong — on my RPi 5, with current EEPROM firmware, the system booted fine without downloading anything extra. So either the firmware path is a little smarter than I expected, or I was just confidently wrong for most of the day.
The good news is still the same: the linux-rpi5 package handles DTBs, overlays, and even auto-generates config.txt and cmdline.txt on first install. Which is nice, because by that point I was done manually creating boot files.
The packaging split is also kind of funny once you look at it side by side:
| Thing | ALARM | drzee |
|---|---|---|
start*.elf, fixup*.dat blobs |
raspberrypi-bootloader |
not packaged anywhere I could find |
| Kernel | linux-rpi-16k |
linux-rpi5 |
| DTBs and overlays | split around ALARM's boot setup | bundled in linux-rpi5 |
config.txt / cmdline.txt |
you deal with it | auto-generated by linux-rpi5.install |
| WiFi / Bluetooth firmware | firmware-raspberrypi |
linux-firmware-rpi5 |
| EEPROM updater | separate tools/packages | rpi5-eeprom |
So ALARM gives you the classic Pi firmware blob bundle, while drzee mostly folds the practical boot bits into the kernel package and just... doesn't package the old firmware files. Which sounds sketchier than it turned out to be.
Also worth noting: ALARM's linux-rpi-16k uses 16KB pages, which is better for RPi 5 performance. The drzee kernel uses 4KB. Progress!
Quick Comparison
| ALARM | drzee aarch64 port | |
|---|---|---|
| Status | Established, been around for years | Unofficial, no RFC, vibes-based |
| Mirrors | ~10 worldwide | One S3 bucket |
| RPi 5 support | First-class | Good — kernel package handles almost everything |
| Package freshness | Same as upstream right now | Same, rebuilt independently |
| Build model | ARM-patched fork of Arch | Straight upstream rebuild |
| Risk | Might lag on big toolchain bumps | One person, one host, one aws s3 rm away from gone |
Testing It in a VM
I didn't want to brick my working Pi setup over curiosity, so I built a VM image and tested it in UTM on my Mac. I wrote up the full procedure as a gist, but here's the highlight reel.
The plan was simple: create a disk image on the Pi, extract the bootstrap tarball, install the kernel, add a bootloader, convert to qcow2, boot in UTM. Should take 20 minutes, right?
I started with GRUB because that's what I know. grub-mkconfig inside a chroot on a loop device produced a config file full of null bytes. Literally all zeros. So I wrote grub.cfg by hand, but then GRUB couldn't find its own modules across partitions. I moved the modules to the EFI partition with --boot-directory. That got further — GRUB loaded! — then refused to boot the kernel with "plain image kernel not supported, rebuild with CONFIG_EFI_STUB enabled." At this point I had rebuilt the image three times and accidentally rm'd a qcow2 while it was still mounted via nbd, corrupting the filesystem. Fun afternoon.
systemd-boot took 30 seconds to set up and just worked. Lesson learned.
The one other gotcha worth mentioning: the bootstrap tarball ships with root locked — there's a * in /etc/shadow. Not an empty password, a locked account. I booted the VM, stared at the login prompt, realized I couldn't get in, and had to mount the image again to set a password. Don't skip passwd.
Installing on a Real Raspberry Pi 5
If you want to try this on actual hardware, I wrote a step-by-step guide. It's actually simpler than the VM — the RPi firmware handles booting, so no GRUB/systemd-boot drama. You install linux-rpi5 from [forge], it auto-generates the boot config, and at least on my Pi 5 I didn't need to download any extra firmware files.
So Should You Switch?
Honestly? No. Not yet. The packages are the same versions, ALARM's RPi 5 support is more complete, and you get real mirrors instead of a community-run single-bucket setup. Swapping would give you zero tangible benefit today and introduce a single point of failure for your package updates.
But I'm keeping an eye on this. The linux-rpi5 package explicitly replaces linux-rpi-16k, the PKGBUILD is well-maintained, and the intent is clearly to be a drop-in ALARM replacement. If an RFC gets approved and this moves onto official Arch infrastructure with proper mirrors and multiple maintainers, it becomes the obvious choice.
We're not there yet. But it's closer than I expected.