Building balenaOS for RPI4


I’m trying to build I’m trying to accomplish that using resin/yocto-build-env, getting into the container with the following command:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v $SSH_AUTH_SOCK:/tmp/ssh-agent -e SSH_AUTH_SOCK=/tmp/ssh-agent -e BUILDER_UID=$(id -u) -e BUILDER_GID=$(id -g) --privileged -it resin/yocto-build-env /bin/bash

In the container, I clone the repo, checkout the branch, init the submodules and then run ./balena-yocto-scripts/build/barys -m raspberrypi4-64. Unfortunately, the building stops at

ERROR: Nothing PROVIDES 'resin-image'
resin-image was skipped: missing required distro feature 'systemd' (not in DISTRO_FEATURES

Being a complete yocto newbie, I’m not sure how to proceed here.

Appreciate your help,

Hello @wngr unfortunately we don’t support rpi4 yet, but we are working hard have it ready as soon as possible. I forwarded this to the devices team in the hopes they can find some time to take a look and point you in the right direction, but keep in mind we can not guarantee support for this yet.

I see the RPI4 64-bit OS has landed in beta. Great!

  1. Will there be a 32-bit version?
  2. Can I run Pi4 devices (64-bit) alongside Pi3 devices (32-bit) in the same Balena application?



1- We aren’t releasing 32-bit as you can easily use the 64bit image with a 32bit container if needed.
2- We have recently updated our backend and enabled the ability to move aarch64 devices into armv7 fleet. so yes.


Thanks for the quick response … I’ve just confirmed this via my own testing.


Wow – this is awesome! Any plans to allow armv6 devices (the Pi Zero) to be used in the same app as armv7 and aarch64?

Not in the short term, but in the long term this is something that we would like to allow, but there are some things that need to be ironed out first. We’ll keep you posted.

1 Like

Sounds great :slight_smile: Do you happen to have a GitHub issue we can use to track this?

You can track progress on the SDK side of this on this GitHub issue:

Once that’s done, there will be a period of extra internal testing before releasing, but for sure getting this resolved would mean that we are getting close.

1 Like

Hey @wlisac I wanted to let you know that we have finally added mixed fleet support for the PI family. To be clear we do provide backwards Pi model compatibility, in the sense that RPi4 & RPi3-64bit devices can be added in RPi3/2/1/0 apps, RPi3 devices can be added in RPi2/1/0 apps. BUT RPi 1/0 devices can’t be added in RPi 2/3/4 apps because of their CPU architecture.

@nazrhom Thanks for the update :slight_smile:

I think my use case is actually the one that’s not supported – mixing armv6 / armv7 / armv8 devices, but having the devices run containers native to their own architecture.

I understand why this isn’t supported right now, but it would still be nice to allow a single app to build for multiple architectures (especially when using a Dockerfile.template that supports multi-arch).

hey @wlisac, could you share an example of your use case, and the issues you are facing? Thanks!

@mikesimos for sure :slight_smile:

We have an IoT app that works on Raspberry Pi 0/1/2/3/4. It’s written in Swift and uses docker images via Swift on Balena.

We’d like to be able to have a single application on balena that includes all of the different Pi variations, but we still want all of the containers to run against the native architecture of the device.

Right now, it sounds like we either have to drop down to the lowest common denominator (armv6) or use different balena apps for each architecture type.

Currently, we’re using different apps on balena and using a multi-arch Dockerfile.template:

FROM wlisac/%%BALENA_ARCH%%-swift:5.0.1-build

This isn’t great, since we have to manage all of our env vars, releases, etc in different apps.

The alternative of using armv6 containers on all of our devices also isn’t great, since we want to take advantage of armv7 / aarch64 instruction improvements where possible (most of our devices are armv7 / aarch64).

We’d like to have mixed architecture applications, and (ideally) be able to specify the architecture to use for a device type (maybe in some cases folks do want to run armv7 containers on an aarch64 OS / device, for example).

I’m happy to expand on the use case more, but hopefully that helps :slight_smile:

Hi @wlisac, thank you for the explanation of your use case. Appreciated.

I took a note in our internal system that you are interested in having an application with mixed device architectures. We had more users asking for this feature as well. So thanks for the further encouragement to build it : )

We will post an update as we make progress on that front.

1 Like