Anthias 2026.05.2 | Screenly

Anthias 2026.05.2: Raspberry Pi 4 and balena x86 players no longer get stuck on the boot splash

Sun, 31 May 2026 00:00:00 +0000

If your Raspberry Pi 4, or an x86 PC set up from the balena image, started up to the Anthias splash screen and never got as far as your content, Anthias 2026.05.2 fixes it. You only need to do something if you run your own balena fleet; the settings to check are below.

The 2 boards had different causes.

x86 on balena

On an x86 PC running the balena image, the screen stayed on the splash while the viewer's logs filled with lines like Could not make device fd drm master and Swapchain for output 'DP-1' failed test. balenaOS leaves the boot splash (Plymouth) running, and on x86 it kept hold of the display. The viewer now closes the splash before it starts. Installs on Debian aren't affected, since the splash has already closed there by the time the viewer starts.

If you deploy to your own balena fleet from a compose file you maintain, the anthias-viewer service needs 2 additions for this: the environment variable DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket and the label io.balena.features.dbus: '1'. docker-compose.balena.yml.tmpl in the repository has both.

Raspberry Pi 4

In Anthias 2026.05.1, a Raspberry Pi 4 could stay on the splash for 2 reasons.

On some boots, the viewer opened the graphics device that has no display attached (/dev/dri/card1 when the display was on card0), found no screen, and never started. This happened on Raspberry Pi OS installs as well as on balena. The viewer now looks for the device with the display connector every time it starts, and logs its choice, for example start_viewer: eglfs DRM device = /dev/dri/card0.

On the official Pi 4 balena fleet, the setting that loads the full KMS graphics driver was stored with literal quotes, as "vc4-kms-v3d". The firmware couldn't read it, so the driver didn't load and the viewer couldn't start. The fleet setting is now vc4-kms-v3d, without quotes, and devices on the fleet restart once to pick it up. If you run your own Pi 4 fleet, check that BALENA_HOST_CONFIG_dtoverlay (or the older RESIN_HOST_CONFIG_dtoverlay) is vc4-kms-v3d with no quotes around it.

Anthias 2026.05.2: Upgraded devices no longer crash-loop on a permission error in anthias.conf

Sun, 31 May 2026 00:00:00 +0000

From Anthias 2026.05.2, a device upgraded from an older release starts the viewer normally. Before, some upgraded devices restarted the viewer in a loop, with this line in the logs:

PermissionError: [Errno 13] Permission denied: '/data/.anthias/anthias.conf'

The viewer runs as an unprivileged viewer user, and on those devices the configuration folder belonged to root. Now, every time the viewer container starts, it gives the viewer user ownership of /data/.anthias and everything in it. On a Raspberry Pi OS or Debian install, that folder is ~/.anthias on the device.

You don't need to do anything. The fix applies the first time the new release starts.

Anthias 2026.05.2: Raspberry Pi 2 and Pi 3 wait for a display instead of crash-looping

Sun, 31 May 2026 00:00:00 +0000

From Anthias 2026.05.2, a Raspberry Pi 2 or Pi 3 that boots without a working display waits for one, and starts the viewer by itself once a screen is connected or switched on, with no restart. That covers a panel that's powered off, a TV switched on after the Pi, and a TV that's slow to bring up HDMI.

Before, the viewer couldn't start in that situation. It logged Unable to figure out framebuffer device and no screens available, crashed with malloc(): unaligned tcache chunk detected, and the container restarted in a loop.

While it waits, the viewer logs no framebuffer (/dev/fb0) yet once, then a reminder every minute.

Anthias 2026.05.2: Devices installed from a disk image now get updates over the air

Sun, 31 May 2026 00:00:00 +0000

From Anthias 2026.05.2, a device flashed from a disk image gets new stable releases over the air, the same way a device added through balenaHub does. Before, it stayed on the version you downloaded, even after new releases came out, and the installation guide said so.

The image still comes with the release it was built from already on it, so the device doesn't have to download Anthias before it starts. Once it's online, it follows the balena fleet for its board and installs each stable release as it's published.

The first boot needs a network connection. The image doesn't carry the fleet's boot settings, such as the graphics driver, so a new device starts on balenaOS defaults, fetches the fleet's settings and restarts once into them.

This applies to devices flashed from a 2026.05.2 image or newer. Devices on the official fleets that were flashed from an older image catch up too, from Anthias 2026.06.3, when an hourly job started clearing their pin. The answer to "How do I update Anthias?" in the FAQ and the disk image section of the installation guide now describe it.

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

Sun, 31 May 2026 00:00:00 +0000

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.