Set up a frame · ipxe.cloudcompute.com

◈ Sign in

Everything past this point — the card image, the machine list, the boot feed — is answered only to the operator token. It is kept in this browser's local storage, the same place the fleet console keeps it, and sent as a bearer header over HTTPS.

1 Download the card image

Pick the image for the board you have. The download is checked against the published SHA-256 before it is handed to you; keep the file name as it is so the write step's commands match.

Loading the published images…

Raspberry Pi 4 Model B is the board this boot chain has been watched all the way to a picture on — the same firmware release, the same iPXE binary, the same settings, netbooted from a bench Pi. The card image assembles those proven parts; the first boot of a Pi from a written card is what this page exists to make routine, and until one has been observed the image itself counts as assembled rather than proven. Pi 400 and Compute Module 4 share the Pi 4's firmware family and should behave the same, but are unverified. There is no image for the Pi 5 (its community UEFI is unmaintained), and none yet for the Pi 3 or Pi 2. The model matrix records what is proven, documented, or merely plausible for each.

From a terminal instead

Same download, same check. DASHBOARD_TOKEN is the token you signed in with — put it in the environment, never on the command line where a shell history would keep it.

H="Authorization: Bearer $DASHBOARD_TOKEN"
U=https://ipxe.cloudcompute.com/api/cards
curl -fsS -H "$H" -o FILE "$U/FILE"
curl -fsS -H "$H" -o FILE.sha256 "$U/FILE.sha256"
# sha256sum -c on Linux
shasum -a 256 -c FILE.sha256

2 Write it to a card

Any microSD card of 1 GB or more. The image is 256 MB uncompressed; the rest of the card stays unused, and nothing is ever written to it later — the Pi runs from RAM.

Writing an image erases the whole target disk. Identify the card by its size and model, not by guessing the device name, and check it twice. Internal disks and USB drives look the same to dd.

Open Raspberry Pi Imager (1.8 or newer accepts a .img.gz directly).
Choose Device → any Pi 4 entry, or skip it — the device filter only narrows the OS list.
Choose OS → scroll to the bottom → Use custom → pick the downloaded file.
Choose Storage → your card. Compare the size shown with the card in your hand.
Next. When it asks whether to apply OS customisation settings, answer No — there is no operating system on this card to customise, and Imager would otherwise drop its own files onto the boot partition.
Confirm the erase. Imager writes, then verifies what it wrote.

# find the card: external, physical, the right size
diskutil list
diskutil unmountDisk /dev/diskN
# rdiskN (raw) is many times faster than diskN
gzip -dc FILE | sudo dd of=/dev/rdiskN bs=4m
diskutil eject /dev/diskN

Ctrl+T shows dd's progress. If macOS offers to initialise the disk when you reinsert it, decline — but it normally recognises the FAT partition and mounts it as BOOT.

# find the card: usb or mmc transport, the right size
lsblk -d -o NAME,SIZE,MODEL,TRAN
sudo umount /dev/sdX?* 2>/dev/null
gzip -dc FILE | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
sudo eject /dev/sdX

On a built-in reader the device is /dev/mmcblk0 rather than /dev/sdX.

What a written card looks like

Eject it, put it back in, and it mounts as a volume named BOOT holding RPI_EFI.fd, config.txt, start4.elf, an overlays/ folder and EFI/BOOT/BOOTAA64.EFI. That is the entire card. If you see a Linux root filesystem or an ssh file, a different image was written.

3 Boot the Pi

Ethernet cable from the Pi to a switch or router that hands out DHCP addresses and reaches the internet. Wi-Fi is not used at any point.
The card in the slot, contacts facing the board.
The Inky panel seated on the 40-pin header, if this Pi is to be a frame. It is fine to add it later — power the Pi off first.
HDMI monitor, optional but worth it the first time: it shows where a boot stops, which no LED does.
Power (USB-C) last.

What to expect

0–10 s: Red PWR steady, green ACT flickering as the card is read; the Ethernet port lights. On HDMI: the Raspberry Pi logo (UEFI firmware, "Press ESC for setup" — don't).
10–30 s: On HDMI: iPXE initialising devices, then a DHCP line and a boot menu with a 30-second countdown. Leave it — Discovery is the default and the countdown is meant to run out. The first check-in lands here (boot events can take up to a minute to reach this page; a registration shows at once).
30–90 s: On HDMI: Alpine Linux boot text scrolling, then a login prompt. Nothing to type.
≈ 2 min: The machine registers and appears below. Up to five minutes on a slow link.

There is nothing to press or type at any point. A Pi that seems to be waiting for you is a Pi that has stopped — the watch step below says where.

4 Watch it check in

not watching

Nothing after three minutes. Read the ladder above from the left, if any of it lit:

Nothing at all — the Pi never reached iPXE. Check the Ethernet link lights; try another cable or port (some managed switches hold a port for 30 s before forwarding, and iPXE gives up before that on some links — power-cycle once). If HDMI shows the UEFI logo and no more, the card's boot loader did not start: rewrite the card.
Menu but no Alpine — the kernel download failed or the countdown was interrupted. Power-cycle; on HDMI, watch for a red iPXE error.
Alpine but no registration — the node booted but cannot reach the control plane from userspace, or DHCP gave it no DNS. Its heartbeat detail on the fleet console names the service it is stuck in.

Every boot event and every registration since you pressed the button, grouped by MAC. Raspberry Pi MACs are tagged. Boot events (the first three rungs) arrive with up to a minute's lag; a registration is immediate, so a machine can appear as registered before its earlier rungs light. A machine that has registered can be taken on to the frame role.

5 Make it a frame

Choose a registered machine in the previous step.