Alpha/Linux Wiki

This page describes how to install a current Linux distribution on an Alpha system with the SRM console, using aboot 2.0 to boot it. The distribution's own installation guide covers everything that is not specific to Alpha; this page covers what is: the firmware, the disklabel, and the boot loader. Systems that have only the ARC or AlphaBIOS firmware are covered at the end.

In outline:

1. Check that the system is supported, and update its firmware.
2. Set up a serial console.
3. Boot the installation CD from SRM.
4. Partition the disk with a BSD disklabel.
5. Install the system, then write aboot to the disk and create /etc/aboot.conf.
6. Set the SRM variables to boot the new system.

Debian's installer partitions the disk and installs aboot itself, so the Partitioning and Installing aboot sections apply to Gentoo, which is installed by hand, and to other manual installations. Debian's aboot installer only accepts an ext2 partition for the kernel and aboot.conf, and stops with "No ext2 partitions found" if the disk has none, so the partitioning in the installer must include an ext2 file system, normally /boot. ¹⁾

Current kernels need an EV56 (21164A) or later processor. Check the CPU with the SRM show config command; a system with an EV4, EV45, or EV5 processor can run nothing newer than Linux 6.9, and no current distribution. See Current Status and the current kernel column of the Systems and Motherboards tables. Multiprocessor systems must boot from SRM, and every 21264 system has it.

Update the SRM console to the last version released for the system before installing. Older versions cannot boot from some SCSI controllers or initialize some video cards, and some are too old for Linux at all. The last version for each system is listed under Final versions, and where to find the images and how to install them under Firmware: Obtaining and updating firmware. show version at the prompt displays the current version.

If the system starts ARC or AlphaBIOS rather than SRM, switch it to SRM first, as described in Switching to SRM.

The DS15, DS25, ES45, GS80, GS160, GS320, ES47, ES80, and GS1280 run only kernels built without CONFIG_ALPHA_LEGACY_START_ADDRESS; see Kernel: Kernel start address. Debian's installer and installed system use its alpha-generic kernel, which is built without the option and described as supporting the Wildfire, Titan, and Marvel systems. ^{2) 3)} Gentoo's gentoo-kernel package uses Debian's configuration, ⁴⁾ and Gentoo's minimal install CD carries two kernels: gentoo, built with the option, and gentoo_nolsa, built without it. ⁵⁾ The CD boots gentoo by default, which leaves these platforms out and prints LEGACY_START among the "Major Options" in its first messages. ⁶⁾ On these systems, gentoo_nolsa is booted instead, as entry 1 of the CD's aboot.conf, or entry 3 for a serial console on COM1: for example boot dqa0 -flags 1, with the CD drive's device name in place of dqa0. ⁷⁾

Three distributions publish current Alpha install media:

Gentoo's minimal CD boots to a shell, from which the system is installed by hand from a stage3 tarball, following the Gentoo Handbook for Alpha. Debian's netinst CDs boot the Debian installer, which partitions the disk and installs aboot itself. Debian's Alpha porters recommend the CD snapshots over the separate netboot images, which see less testing. ⁸⁾ T2 SDE's ISOs boot its own installer.

The image is written to a CD-R. SRM does not boot from USB storage, so a CD drive, or a network boot, is needed. Current SRM versions boot from SCSI and IDE (ATAPI) CD drives. ⁹⁾ A system without a working CD drive can boot the installer over the network; see aboot: Network booting.

A serial console is strongly recommended for the installation. Many video cards work only partly with the SRM console, and without a serial console, a kernel that fails to boot usually fails silently. It needs set console serial in SRM, and console=ttyS0 in the kernel arguments, both when booting the installer and in /etc/aboot.conf for the installed system. The ES47, ES80, and GS1280 need console=srm instead of console=ttyS0; see Marvel. See Using the SRM Console: Serial console for the settings, cables, and the RMC.

Find the CD drive's SRM name with show device. SCSI drives are named dkan, where n is 100 times the SCSI ID, and IDE drives dqan; see Device names. The examples below use dka500, a SCSI CD-ROM drive at ID 5.

The install CDs carry aboot and an aboot.conf. Boot the first entry, or start aboot's prompt to see the others:

>>> boot dka500 -flags 0
>>> boot dka500 -flags i
aboot> l

Kernel arguments can follow the entry number, for example to add the serial console:

>>> boot dka500 -flags "0 console=ttyS0"

SRM finds aboot through a boot block in the disk's first sector, where a PC partition table would also be. The boot disk must therefore have a BSD disklabel, not an MBR or GPT partition table. ¹⁰⁾ Other disks in the system can use any partition table.

fdisk from util-linux cannot create BSD disklabels, so use parted. ¹¹⁾ Leave free space at the start of the disk for aboot; starting the first partition at 1 MiB leaves plenty. A typical layout, with a separate /boot:

parted /dev/sda mktable bsd
parted /dev/sda mkpart ext2 1MiB 513MiB
parted /dev/sda mkpart linux-swap 513MiB 4609MiB
parted /dev/sda mkpart ext2 4609MiB 100%
parted /dev/sda print

A BSD disklabel holds at most eight partitions, a to h, which aboot and SRM number 1 to 8. Linux names them /dev/sda1 and so on, in the same order. By convention partition c covers the whole disk; a disklabel created by parted has none, but a disk labeled by another tool may, and swriteboot then needs -f3 to write the boot block although partition c overlaps it. ¹²⁾

aboot 2.0 reads /boot from ext2, ext3, ext4, or XFS. It rejects ext4 file systems with some newer features, and cannot load a kernel file split into more than four extents; see aboot: File systems. A small ext2 /boot avoids both limits. Not every distribution installs aboot 2.0. Gentoo packages 2.0, ¹³⁾ although its install CD boots with version 1.0_pre20040408; ¹⁴⁾ Debian installs a snapshot from February 2020, 1.0~pre20200212, ¹⁵⁾ and T2 one from August 2021. ^{16) 17)} Both predate aboot's XFS support and the extension of its ext4 support in 2025, ^{18) 19)} so with them /boot belongs on ext2. Recycled disks with an old PC partition table can confuse installers; erasing the old signatures first, with wipefs -a /dev/sda, avoids this. ²⁰⁾

After the system is installed, and still in the installer or chroot, write aboot to the start of the disk with swriteboot. The target is the whole disk, not a partition, and -c names the partition that holds /etc/aboot.conf, here partition 1, the /boot file system: ²¹⁾

swriteboot -c1 /dev/sda /boot/bootlx

Distributions install bootlx as part of their aboot package; Debian's installer runs swriteboot itself. If swriteboot reports "bootcode overlaps with partition", the first partition starts too early, or the disk has a partition c covering the whole disk; see aboot: swriteboot.

Then create aboot.conf. aboot reads it from the root of the configured partition, so with a separate /boot it is /boot/etc/aboot.conf, and kernel paths are relative to /boot: ²²⁾

0:1/vmlinuz root=/dev/sda3 console=ttyS0
1:1/vmlinuz root=/dev/sda3 console=ttyS0 single
2:1/vmlinuz.old root=/dev/sda3 console=ttyS0
3:1/vmlinuz initrd=/initrd.img root=/dev/sda3 console=ttyS0

Each line is an entry number, a colon, the partition and path of the kernel, and the kernel arguments. aboot has no default entry of its own; the default is chosen with boot_osflags below. Distributions differ in how they name kernels and initrds, so check /boot for the actual names, and use an initrd= argument if the distribution uses one. If /boot is not a separate partition, the file is /etc/aboot.conf on the root file system, kernel paths are e.g. 3/boot/vmlinuz, and swriteboot takes -c3.

Test the new system by booting it by hand from the SRM prompt, where dka0 is the disk that aboot was written to:

>>> boot dka0 -flags 0

Once it works, set it to boot automatically: ²³⁾

>>> set bootdef_dev dka0
>>> set boot_file ""
>>> set boot_osflags 0
>>> set auto_action boot

boot_osflags names the aboot.conf entry; boot_file is left empty because aboot.conf supplies the kernel. bootdef_dev can list more than one device, separated by commas, and SRM tries them in order. ²⁴⁾ Pressing Ctrl+C during startup returns to the SRM prompt, and set auto_action halt stops automatic booting.

If the system returns to the SRM prompt instead of booting, see the checklist under Using the SRM Console: Booting Linux, and the known issues of aboot.

aboot has no configuration step of its own to rerun: it reads aboot.conf and the kernel from the file system at every boot. A kernel update therefore needs no action if the aboot.conf entries name files, or symbolic links, that the distribution's kernel package updates. If they name versioned files instead, such as vmlinuz-6.12.0, the entries must be edited after each update. Keeping an entry for the previous kernel gives a fallback that can be booted from the SRM prompt by its number. A kernel built by hand is installed as described under Kernel: Native builds.

A system can also be installed under QEMU and the disk image written to a real disk afterwards, which is useful for a system without a working CD drive. Debian's installer writes a BSD disklabel and aboot under QEMU as on real hardware; see QEMU: Booting an installer. The image is converted to a raw image and copied to the disk, attached to another computer, with dd:

qemu-img convert -O raw alpha.qcow2 alpha.img
dd if=alpha.img of=/dev/sdX bs=4M conv=fsync

The disk in the Alpha may have a different name from the one under QEMU, and the root= arguments in aboot.conf and the entries in /etc/fstab have to match it. The kernel installed under QEMU must also support the real system's disk controller and network card, which a distribution's generic kernel does.

A few systems have only the ARC, AlphaBIOS, or ARCSBIOS firmware, whose PALcode is designed for Windows NT and cannot run Linux. They boot Linux with MILO, which provides its own PALcode, instead of aboot. Among systems that current kernels still support, these are the Alpha XL 366 and 433 (XLT), the AlphaPC 164UX (Ruffian), and the AlphaPC 164RX. ²⁵⁾

Released versions of MILO cannot load kernels from Linux 2.6.23 onward. A fix was made in 2026, but no current kernel has yet been reported booting on these systems through MILO. ²⁶⁾ No current distribution ships MILO. The disk needs a PC (MBR) partition table with a small FAT partition for MILO and its loader, so it cannot also be booted from SRM; see MILO: From ARC or AlphaBIOS.

Most other systems sold with ARC or AlphaBIOS, among them the AlphaPC 164LX, AlphaPC 164SX, Personal Workstation, and AlphaStation 500 and 600, can run SRM, and should be switched to it; see Switching to SRM. There is no usable MILO for the 21264 systems, ²⁷⁾ all of which have an SRM console.

• Using the SRM Console
• aboot, for everything about the boot loader
• QEMU, to try a distribution before installing it on hardware
• Kernel