Survey the live system
Before touching the disk, confirm five things about the machine you have just logged into. Every command on this page only reads – none of them change anything – and each one prevents a failure that is annoying to diagnose later.
Which architecture is this?
uname -m
x86_64
Either x86_64 or aarch64. This decides which half of the
architecture-specific steps later in the book apply to you, and on
aarch64 it is a reminder that the distribution is Arch Linux ARM
rather than Arch Linux.
Did it boot UEFI?
cat /sys/firmware/efi/fw_platform_size
64
On an x86_64 PC this must print 64. If the file does not exist,
you booted in legacy BIOS mode: go back into the firmware setup,
disable CSM, enable UEFI, and boot again. Installing now would
produce a machine that cannot boot itself.
On a Raspberry Pi 5 the file does not exist and that is correct. The Pi has no UEFI firmware; its own bootloader loads the kernel directly, which is why the bootloader chapter treats it separately.
Is the clock right?
timedatectl
Local time: Sun 2026-10-25 17:55:22 UTC
Universal time: Sun 2026-10-25 17:55:22 UTC
RTC time: Sun 2026-10-25 17:55:22
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
The live system syncs the clock over NTP by itself, so this is normally already true. Check it anyway: pacman verifies package signatures and talks to mirrors over TLS, and both fail in confusing, unrelated-looking ways when the clock is wrong. A Raspberry Pi has no battery-backed clock at all and starts every boot with a nonsense date until NTP fixes it, so this check matters most there.
If it says no, the network is not up yet – check the next step
first and come back.
Is the network up?
ip -brief address ip route
lo UNKNOWN 127.0.0.1/8 ::1/128 enp1s0 DOWN wlan0 UP 192.168.1.140/24 metric 600 fe80::aef2:3cff:fe34:25b7/64 wg0 UNKNOWN 10.13.17.9/24 default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.140 metric 600 10.13.17.0/24 dev wg0 proto kernel scope link src 10.13.17.9 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.140 metric 600
You should see an address on a real interface and a default route. If
you are reading this over SSH then obviously something is working,
but it is worth seeing whether you arrived over wg0 or over the
LAN, and whether the machine has a route to the internet at all –
the install downloads several hundred megabytes of packages.
Confirm that outbound HTTPS actually works, which is what pacman needs:
curl -fsS -o /dev/null -w '%{http_code}\n' https://archlinux.org
200
How much room is there?
free -h df -h /run/archiso/cowspace
total used free shared buff/cache available
Mem: 28Gi 1.7Gi 26Gi 1.0Gi 1.4Gi 26Gi
Filesystem Size Used Avail Use% Mounted on
cowspace 256M 9.1M 247M 4% /run/archiso/cowspace
The live system has no disk of its own: it runs from a read-only image with a writable layer in RAM. That layer – the cowspace – is where every file you create or modify in the live environment actually lands.
Note the size. The cowspace is 256 MiB by default no matter how much memory the machine has: the example above is from a box with 28 GiB of RAM. It is not a share of your memory, it is a fixed cap, and the symptom of exceeding it is a sudden “no space left on device” from a command that looks like it should have had room to spare.
A normal install does not come close, because pacstrap downloads
the new system’s packages onto the target’s disk rather than into
RAM. You run into it when you install extra tools into the live
system itself. The next page shows how to raise the cap.