Prepare pacman
The survey only looked. This page makes three small changes to the live system, so that the long package download in the next chapter does not fail halfway through. None of them touch the target’s disk.
Refresh the keyring
pacman -Sy --needed --noconfirm archlinux-keyring
pacman -Sy --needed --noconfirm archlinuxarm-keyring archlinux-keyring
The Pi image ships both keyrings pre-installed and trusted, so that
second command is a refresh rather than a first install. Arch Linux
ARM’s core carries the pair, and updating both costs nothing.
Every package pacman installs is checked against a set of developer signing keys, and the copy of those keys on the stick is as old as the image you built. Keys get added, rotated and revoked; a stick that has been in a drawer for six months will eventually meet a package signed by a key it has never heard of, and refuse to install it.
The error when this happens names a signature rather than a stale keyring, which sends people down the wrong path. Updating the keyring first costs a few seconds and removes the whole category.
On a stick you built last week this is a no-op, and says so – which is the answer you want:
:: Synchronizing package databases... core downloading... extra downloading... warning: archlinux-keyring-20260909-1 is up to date -- skipping there is nothing to do
Early BOOMSTICK Pi images shipped without Arch Linux ARM’s signing keys. On one of those, every ALARM-built package fails – including the kernel, which means the install cannot proceed at all:
error: linux-rpi-16k: signature from "Arch Linux ARM Build System
<builder@archlinuxarm.org>" is unknown trust
Check which kind of stick you have:
pacman-key --list-keys 68B3537F39A313B3E574D06777193F152BDBE6A6 | grep uid
A current stick reports [ full ]. If it says [ unknown ],
rebuild the stick if you can. You cannot install your way out of it
on the spot, because archlinuxarm-keyring is itself signed by the
very key that is not trusted. The escape is to sign it locally:
pacman-key --lsign-key 68B3537F39A313B3E574D06777193F152BDBE6A6
On a stick in that state you must also use plain pacstrap in the
next chapter rather than pacstrap -K, because -K implies -G
(“do not copy the host’s keyring to the target”) and would build the
target without the trust you just added. On a current stick either
form works.
Sort the mirrors
Package downloads are the slowest part of the install, and which mirror you draw them from decides how slow.
The good news is that the default is already sensible, and you can usually skip this page’s second half. The live system ships the full Arch mirrorlist with every HTTPS mirror enabled – around 425 of them – and the first two entries are Arch’s own CDNs:
grep '^Server' /etc/pacman.d/mirrorlist | head -2
Server = https://fastly.mirror.pkgbuild.com/$repo/os/$arch Server = https://geo.mirror.pkgbuild.com/$repo/os/$arch
pacman tries them in order, so unless you have a reason to prefer something else, a geo-routed CDN is a fine first choice anywhere in the world.
reflector is installed on the x86_64 live system, but – contrary
to what you might expect, and to what a lot of install guides imply
– it is not enabled, and it does not run at boot:
# systemctl is-enabled reflector.service
disabled
The only mirror-related unit that is enabled is
choose-mirror.service, and it does nothing unless you booted with a
mirror= kernel parameter. So the order you see is the order the
mirrorlist shipped in, not a measured ranking.
Rank them yourself, if you want to
If you would rather draw from a measured-fastest mirror near you than from the CDN, run reflector yourself and refresh the package databases afterward:
reflector --country US --protocol https --age 12 --sort rate \ --save /etc/pacman.d/mirrorlist pacman -Sy
Replace US with your own country name as reflector spells it
(reflector --list-countries prints them all). The other flags ask
for HTTPS mirrors that synced within the last 12 hours, ordered by
measured download rate.
Skip this on the Pi: reflector is in archiso’s x86_64 package list
only, so it is not installed on the Arch Linux ARM image, and it
knows nothing about ALARM’s mirrors in any case. Leave that
mirrorlist as it is.
Make room, if you need it
The 256 MiB cowspace from the survey is a cap, not a measure of free memory, so on any machine with RAM to spare you can simply raise it:
mount -o remount,size=4G /run/archiso/cowspace
Filesystem Size Used Avail Use% Mounted on cowspace 4.0G 9.7M 4.0G 1% /run/archiso/cowspace
This is still RAM, so you cannot conjure space that does not exist; it only raises the cap, and you should stay well under the physical limit. On a machine with very little memory, the real fix is to get the target’s disk mounted early and put swap on it, which the disk chapter does.
With the keyring current, the mirrors settled, and the clock correct, the live system is ready. The next chapter writes to the disk.