Raspberry Pi 5 no longer fills its storage with core dumps, and other fixes

The balena Releases page shows the real Anthias version, the official Raspberry Pi 5 balena fleet gets the memory setting 4K HEVC playback needs, and the docs cover the Raspberry Pi Imager write error on macOS.

May 31, 2026

Fixes

• On a Raspberry Pi 5, the check that reads whether the display is on, which runs every 5 minutes, left a core dump of several megabytes each time. Enough of them could fill the storage and put Anthias services into a restart loop. Neither the check nor the "Turn display on" and "Turn display off" buttons leave core dumps now.
• The balena Releases page shows the real version of each Anthias release, such as 2026.5.2, instead of 0.0.0+revN. That holds for the official fleets and for fleets you deploy to with bin/deploy_to_balena.sh.

Improvements

• Raspberry Pi 5 devices on the official balena fleet get dtoverlay=vc4-kms-v3d,cma-512, the line install.sh has written on a Pi 5 since Anthias 2026.05.1. The project's board notes list it as required for 4K HEVC hardware decoding.
• The installation guide and a new FAQ entry cover the "Error writing to storage device" failure when flashing with Raspberry Pi Imager 2.0.2 through at least 2.0.7 on macOS. Update Raspberry Pi Imager past 2.0.7, or decompress the image with zstd -d and flash the .img.
• The balena fleet guide uses balena env set instead of balena env add for the host configuration commands.

For contributors

• balena-host-config.json declares the config.txt settings for each official balena fleet, and docs/balena-fleet-host-config.md explains each one. On every release, the "Build Balena Disk Images" workflow sets them on the fleets and removes any other host configuration variable there, including legacy RESIN_HOST_CONFIG_* ones. Fleets you run yourself aren't touched.
• A new "Deploy to Balena (manual)" workflow redeploys an existing release to one fleet or all 5 without rebuilding disk images. It and the release workflow share bin/balena_ota_deploy.sh.
• The viewer user has a fixed UID and GID of 1000 and exists in both the server and viewer images, so it resolves to the same owner in every container that shares /data.
• uv.lock was regenerated to match the dev dependency pins in pyproject.toml, which the uv sync --frozen step in the image builds checks.