Which OS for the uConsole CM5 and how to flash it to a microSD card (2026)

You have a uConsole with a CM5 module, the card with the system came in the box, and everything works. This guide is for the day you want more: a different distro, a bigger card, a clean install after some experiments, or a new card because the old one went missing. We gathered in one place what runs on the CM5 as of October 2026, where to get it, and how to flash it without guesswork.

• Where to get OS images for the CM5
• Which image to pick
• What is on the card from the SAPSAN kit
• How to flash the image: Raspberry Pi Imager
• First boot
• Bigger card and the "FAT read failed" error
• CM5 Lite won't boot from the card: EEPROM
• Frequently asked questions

Where to get OS images for the CM5

The official ClockworkPi repository on GitHub currently lists one current image: uConsole_CM4_v3.1 from April 2026, which is for the CM4. ClockworkPi has not published any image for the CM5. Everything that runs on the CM5 comes from the community, specifically from Rex (ak-rex). He builds images with his own kernel and uConsole drivers, publishes them at images.ak-rex.com and has maintained them for years. We use his images too.

A single Rex image supports the uConsole with CM3+, CM4, CM4S and CM5: the module is detected at boot, and config.txt has a separate section for each one. The list as of October 2026:

One trap: uConsoles shipped since early 2026 have a new display panel and need an image with kernel 6.12.67 or newer. On an older image the backlight turns on, but the screen stays black. Every image in the table is past that update.

Which image to pick

• You want what is on the card from the kit: Debian 12 Bookworm. We know it inside out and test hardware on it, for example in the CM5 thermal test.
• You want newer packages: Debian 13 Trixie. This is the line Rex is developing now.
• Pentesting: Kali 2026.2 from Rex. After apt upgrade the DevTerm printer package sometimes throws an error; Rex's advice is sudo apt remove DevTerm*.
• SDR: DragonOS, especially if you have the AIO V2 with its built-in RTL-SDR.

What not to do: don't flash plain Raspberry Pi OS from the Imager list. It has no drivers for the uConsole screen, keyboard or power management, so you get a black screen. The ClockworkPi CM4 image won't boot on a CM5 either.

What is on the card from the SAPSAN kit

Every uConsole Kit RPI-CM5 8GB ships with a 32 GB microSD card loaded with Rex's Debian 12 Bookworm (kernel 6.12.67), a SAPSAN wallpaper and a welcome message at first login. Beyond that it is a clean image with no modifications of ours, so everything you find on the ClockworkPi forum about Bookworm applies to your card as well.

Lost the card, or want a spare? Download the same image and flash it following the steps below: you get an identical system, just without the wallpaper. The SAPSAN 32 GB U3 microSD card is the same card we pack with the kits, sold blank. Flashing the system onto it takes fifteen minutes.

How to flash the image: Raspberry Pi Imager

You need a computer with a card reader (or a USB reader), a 32-256 GB U3 microSD card and the downloaded .img.xz file. Don't unpack the file, Imager reads .xz directly.

1. Download the image from images.ak-rex.com, ClockworkPi uConsole/DevTerm section. Direct links: Bookworm 6.12.67 (1.1 GB) and Trixie 7.1.4 (1.3 GB).
2. Install Raspberry Pi Imager (Windows, macOS, Linux).
3. In Imager: skip the device or choose "No filtering", OS: "Use custom" and point to the downloaded .img.xz, storage: your card. Double-check that it is the card and not a data drive.
4. When Imager asks about "OS customisation" (username, Wi-Fi, SSH), choose No. Rex repeats this in every thread: an image with Imager's settings applied won't boot. You set up the user and Wi-Fi in the wizard at first boot.
5. Write and wait for verification. Remove the card only after the completion message.

balenaEtcher works instead of Imager, and on Linux and macOS plain xz -dc image.img.xz | sudo dd of=/dev/sdX bs=4M status=progress does the job, provided /dev/sdX really is the card.

First boot

Insert the card into the uConsole and power it on. The first boot takes longer because the system expands the partition to the full card on its own and reboots. A script in /etc/rc.local does this by calling raspi-config --expand-rootfs; we checked it in the Bookworm 6.12.67 and Trixie 7.1.4 images. Nothing to click. After the reboot the wizard starts: country and keyboard layout, username and password, Wi-Fi. From then on the system is yours.

Right after the first login: sudo apt update && sudo apt upgrade. In the Bookworm and Trixie images the kernel and uConsole drivers come from Rex's APT repository, so an update won't replace them with a generic kernel.

Bigger card and the "FAT read failed" error

A classic: you have a working 32 GB card, you buy a 256 GB one, copy the files over, and the uConsole shows "FAT read failed". That is a bootloader message: it cannot read the boot partition. The reason is usually simple. Cards above 32 GB come formatted as exFAT from the factory, while the Raspberry Pi bootloader reads only FAT32 and needs exactly the partition layout the image has. Copying files does not recreate it.

Two ways that work:

1. A fresh image on the new card (steps above). At first boot the system expands to the full 256 GB. You move data and settings by hand.
2. A sector-by-sector clone from the running uConsole: the SD Card Copier tool (Accessories menu in the desktop images) copies the system to a second card in a USB reader and adjusts the partitions to its size right away. A dd clone on a computer works too, but expand the partition by hand afterwards: sudo raspi-config, Advanced Options, Expand Filesystem.

Size: ClockworkPi specifies cards up to 256 GB. Speed matters less than reliability, so pick known brands in the U3 class (A1 or A2).

CM5 Lite won't boot from the card: EEPROM

Some CM5 Lite modules from early batches have a bootloader that reads microSD cards unreliably: the uConsole boots once every few tries or not at all. Rex described the cure on the forum. Prerequisite: a bootloader (EEPROM) dated after 2025-01-06.

1. Boot the uConsole from any working card (if none boots, try a different, slower card, which is usually enough for one successful boot) and check the bootloader date: vcgencmd bootloader_version.
2. If the date is older than 2025-01-06: sudo rpi-eeprom-update -a and reboot.
3. Open the configuration: sudo rpi-eeprom-config -e, keep a copy of what is there, and paste:

[all]
BOOT_UART=1
POWER_OFF_ON_HALT=1
BOOT_ORDER=0xf461
SD_BOOT_MAX_RETRIES=2
SD_QUIRKS=1

What it means: BOOT_ORDER is read from the right. First the SD card (1), then the NVMe drive (6), then USB (4), and f means "start over". SD_BOOT_MAX_RETRIES tells the bootloader to try the card twice, SD_QUIRKS slows down the card read mode in the bootloader. Save and reboot. The same configuration prepares the module for an NVMe drive from the Upgrade Kit, which we cover in a separate guide.

Frequently asked questions

Will a CM4 image work on the CM5?

The official ClockworkPi CM4 image won't. Rex's images will, because their config.txt has sections for CM3+, CM4, CM4S and CM5 and they pick the drivers themselves.

Can I flash a system straight from the Imager list?

No. The Imager list has no uConsole images, and plain Raspberry Pi OS does not support the uConsole screen and keyboard. Always "Use custom" and a file from Rex.

How much space does the system take?

The Bookworm desktop image is 7.4 GB unpacked, Trixie 6.7 GB. After the first boot the partition stretches to the full card, so on 32 GB you have over 20 GB left for tools and data.

What next

System sorted, now the hardware. If you are building a uConsole from scratch, the ClockworkPi collection has kits and modules, and the Raspberry Pi CM5 8 GB Lite is the very module we fit in our kits. Ideas for what to do with the uConsole after the first login are in our article on practical uses of the uConsole. If you would rather boot from a drive than from a card, see the guide: uConsole with an NVMe drive: HackerGadgets Upgrade Kit, assembly and booting from SSD.