Running Linux on Alpha Hardware Today: Distributions, Kernels and Pitfalls
Linux on Alpha never died; it just moved from the front of the distribution catalogue to a small, stubborn corner of it. In 2026 you can still install a current kernel and userland on a UP1000 or UP2000, provided you know which distributions are alive, which firmware path your board needs, and where the sharp edges are.
Where Alpha Linux stands in 2026
Alpha was one of the first non-x86 ports of Linux, and for a while in the late 1990s it was the platform of choice for serious 64-bit Linux work. Boards like the UP1000 and UP2000 were sold with Linux explicitly in mind. Broad distribution support faded through the 2000s, and Debian dropped Alpha as an official release architecture after the Lenny cycle, roughly 2009.
What remains is community maintenance. The kernel port is still in mainline, the toolchain still builds, and a few distributions keep producing installable images. The user base is small, but it is technical and persistent, and bugs do get fixed.
Distributions worth your time
The realistic options fall into two groups: binary distributions maintained as unofficial ports, and source-based distributions where you build most things yourself.
- Debian ports: Alpha lives on in the debian-ports archive as an unofficial architecture tracking unstable. Installer images are produced periodically. Expect some packages to be missing or out of date, and expect the occasional broken dependency after a large transition.
- Gentoo: Gentoo has kept an Alpha keyword and stage tarballs for a long time. Because you compile locally, it copes better with packages that were never built for Alpha, but a full desktop build on a 600 MHz EV6 takes days, not hours.
- Legacy distributions: old releases of Red Hat, SuSE and Debian for Alpha still turn up on archived media. They are useful for period-correct restorations and for testing hardware, but they are unsuitable for anything network-facing.
For most people restoring a board today, Debian ports is the fastest route to a working system, with Gentoo as the choice if you enjoy tuning and have patience or a cross-compile setup.
Kernel status
The Alpha architecture code remains in the mainline kernel. It is not glamorous and it receives far less testing than x86 or ARM, but it is maintained. The most notable recent change was the removal of support for the oldest pre-BWX processors, the EV4 and EV5 families, during 2024. Those chips lacked byte and word load/store instructions, which forced awkward workarounds in core kernel code. EV56 and later, including every 21264-based board this archive covers, are unaffected.
For API hardware, the relevant kernel platform options are:
| Board | Chipset family | Kernel system type | Typical firmware |
|---|---|---|---|
| UP1000 | AMD-751 (Irongate) | Nautilus | AlphaBIOS, Linux via MILO |
| UP1100 | AMD-751 variant | Nautilus | AlphaBIOS or SRM depending on revision |
| UP2000 / UP2000+ | 21272 (Tsunami) | DP264 family | SRM, Linux via aboot |
| CS20 | 21272 (Tsunami) | DP264 family | SRM, Linux via aboot |
A generic Alpha kernel (CONFIG_ALPHA_GENERIC) boots on all of them and is what distribution installers ship. If you build your own, selecting the specific system type trims size and occasionally avoids quirks in the generic probing code.
Installing on UP1000/UP2000-class boards
The single biggest factor is firmware. SRM boards use the aboot loader from a small reserved area at the start of the disk; AlphaBIOS boards need MILO, loaded from a FAT partition. Our explainer on SRM, AlphaBIOS and MILO covers the differences in depth. Here is a practical procedure for an SRM-based UP2000 with a SCSI or IDE disk and a CD drive.
- Connect a serial terminal at 9600 8N1 to the first serial port. SRM output is far easier to capture and debug over serial than on a graphics card.
- At the
>>>prompt, runshow devand note the device names for your CD drive and target disk, for exampledqa0for IDE ordka0for SCSI. - Set the console to serial and disable automatic booting while you work:
set console serialandset auto_action halt, theninit. - Boot the installer CD with
boot dqa1 -flags 0, adjusting the device name. The flag selects entry 0 from the CD's aboot configuration. - Partition the disk with a BSD disklabel, leaving the first few megabytes unallocated. aboot and its bootstrap live there. The Debian installer handles this if you accept its Alpha defaults.
- Complete the install and let the installer write aboot. On a manual install,
swritebootplaces the loader andabootconfselects the partition holding/etc/aboot.conf. - Back at SRM, set
bootdef_devto your disk andboot_osflagsto0, thenset auto_action bootonce you have confirmed a clean boot.
>>> set bootdef_dev dka0
>>> set boot_osflags 0
>>> boot
# /etc/aboot.conf
0:2/vmlinuz ro root=/dev/sda3 console=ttyS0
1:2/vmlinuz.old ro root=/dev/sda3 console=ttyS0On a UP1000 running AlphaBIOS, the flow is different. You create a small FAT partition, place MILO and its configuration there, and add a boot entry in AlphaBIOS that loads MILO, which in turn loads the kernel from an ext2 or ext4 partition. It works, but it has more moving parts, and MILO's filesystem support is frozen in time, so keep /boot on plain ext2.
Common pitfalls
Toolchain gaps
GCC, binutils and glibc still support Alpha. LLVM does not; its Alpha backend was removed more than a decade ago. That means anything written in Rust, or requiring LLVM-based compilation, simply cannot be built. As more core packages adopt Rust, the set of available software shrinks. Graphics libraries, some Python packages and modern browsers are the usual casualties.
Page size and alignment
Alpha uses 8 KB pages, and some software still hardcodes 4 KB assumptions. Unaligned memory accesses trap to the kernel for fix-up, which works but is slow; if a program runs mysteriously badly, check dmesg for unaligned trap messages.
Memory and hardware quirks
These boards are fussy about memory. Mismatched or marginal DIMMs cause random crashes that look like software bugs. Read our Alpha memory configuration guide before blaming the kernel. Aging capacitors and weak power supplies produce similar symptoms.
Graphics
Older Matrox and ATI Radeon cards are the safest bets. Framebuffer console works on many of them, but X can be temperamental, and the firmware may not initialise a card that it does not recognise. Serial console avoids all of this.
Is it worth it?
If you want a fast general-purpose computer, no. A single modern core outperforms a dual 21264 UP2000 by a wide margin. If you want a working example of a clean 64-bit RISC platform, a machine to test portability of your own code, or a faithful restoration of late-1990s Linux workstation computing, then yes. Running a current kernel on hardware designed in the last century is still one of the more satisfying things you can do with a soldering iron and a serial cable.
If you do not have hardware yet, start in emulation. Our guide to emulating Alpha with QEMU and ES40 gets you a working system in an afternoon.
Further reading on this archive
- Restoring a UP1000 motherboard: capacitors, firmware recovery and first boot.
- UP2000 board: API's original product page for the dual-processor board.
- Support: archived API support pages, firmware notes and documentation.