Where it runs

Nine targets and four architectures, from a Pi Zero with 512 MB to a virtual machine on a Mac — and a plain account of what has been tested on each.

01The targets

A target is a pair: what the system is written to, and what loads its kernel. That second half is the only real difference between a Raspberry Pi and everything else. On a Pi the GPU's firmware is the bootloader and reads the kernel from a FAT partition by itself, so writing a card is a file copy. Everywhere else a UEFI firmware loads GRUB from an EFI partition.

Target	Arch	Machine	Levels	How we know
vm	aarch64	UTM on Apple Silicon	all three	the daily bench: every screenshot on this site comes from it
vmx86	x86_64	UTM emulating a PC on Apple Silicon	all three	the README's quick start, on full automatic
pi4, pi5	aarch64	Pi 4, Pi 400, CM4, Pi 5	all three	written as cards from a Mac; the boards for the full monty
zero2	aarch64	Pi Zero 2 W, Pi 3, CM3	all three; medium advised	written as cards from a Mac
pi2b	armv7	Pi 2 B v1.1	server, medium	written as cards from a Mac
zero	armhf	Pi Zero, Zero W, Pi 1, CM1	server, medium	the board Copal was written for
pc	x86_64	any UEFI PC or laptop, Intel Mac	all three	built the same way as vmx86, for real hardware
pc32	x86	32-bit UEFI machines	server, medium	built the same way; rare hardware, least tested

The full monty needs aarch64 or x86_64: Alpine packages no Hyprland for 32-bit ARM or x86, and a Pi Zero's VideoCore has no graphics driver worth asking. On those machines the full level declines itself and installs the medium desktop instead — X and i3, drawn by the CPU, which is exactly what 512 MB can carry.

What "tested" means here. The aarch64 virtual machine is where Copal is built and used every day, and where every program in Copal Apps was compiled and launched before it was listed. The Pi boards are where Copal began; this release has not been re-run on each of them. Copal Apps' compiled programs are admitted on x86_64 on the strength of every dependency being in Alpine's index there, but have not yet been built on it.

02Raspberry Pi

The Pi is Copal's native ground. Copal writes the SD card from a Mac: it downloads Alpine for the board's architecture, verifies it, lays out a FAT boot partition with room behind it, and puts Alpine and the installer on the card. The Pi boots Alpine from RAM; the installer formats the root as ext4, moves the system onto it, and from then on the card is a normal disk.

Pi 4, Pi 400 and Pi 5 have the memory and the GPU for Hyprland — the boards to choose for the full monty.
Pi Zero 2 W and Pi 3 are aarch64 with 512 MB to 1 GB: the medium desktop is the comfortable one.
Pi Zero, Zero W and Pi 1, one 1 GHz core and 512 MB, are the design constraint everything else answers to: a tiling window manager so nothing is drawn twice, swap compressed in RAM because the card is the slowest and most fragile part of the machine, and nothing running that you did not ask for.

Stage 15 is about the card itself: what wears one out, a log policy that spares it, and a read-only root for a Pi that should never change.

03Apple Silicon, in UTM

UTM is a virtual-machine app for the Mac, built on QEMU. On Apple Silicon it runs an aarch64 guest on Apple's own hypervisor, at native speed, and draws its display with the Mac's GPU. It can also run an x86_64 guest, by emulating a whole PC: slower, but the same image a PC would boot.

Copal builds both from the Mac and registers them with UTM itself, with a shared folder, a serial console, and a clipboard joined to the Mac's:

$ ./copal build vm                                   # aarch64: build/copal-vm.img
$ ./copal vm create --target aarch64 --image build/copal-vm.img
$ make utm-x86                                       # x86_64: build, register, start
$ make utm-grow SIZE=256g                            # a full VM's disk, made bigger

A virtual machine is also how Copal is tested: change the installer, boot a fresh image, and see what it built — without a card, a Pi, or a reboot cycle. The images are sparse, so a 128 GB disk costs the Mac only what the guest has written.

04PCs, x86_64 and x86

The pc target is a UEFI disk image for any 64-bit PC or laptop from about 2012 on, and for Intel Macs; pc32 is the same for the rare 32-bit UEFI machines. Both are written to a USB stick or an image file from the Mac.

UEFI only. That is a limit of the machine doing the writing, not a preference: a legacy BIOS boot needs a boot sector written by Linux tools that do not exist on macOS, while UEFI reads a FAT partition and runs a file on it, which is a copy. So Copal supports UEFI, and says so, rather than writing a stick that will not boot.