Balena cloud/cli builder is still not able to interpret image manifests

[matthewcroughan]

"Bind mounts are not allowed" how to define volumes and pass templates via docker compose?

Sorry for the delay, but thanks for your advice that permitted it to build! It’s exciting seeing the interface for all the different services building and deploying independently. Sadly I’m getting an error on all of my services that I was running into in a prior attempt also: 17.06.19 18:29:27 (-0700) redis standard_init_linux.go:207: exec user process caused "exec format error" 17.06.19 18:29:27 (-0700) celeryworker standard_init_linux.go:207: exec user process caused "exec format error"…

@CameronDiver

the issue here is that the balena cloud builder doesn’t yet understand image manifests. If it did, the builder could first see which images exist for the architecture that it runs on, but instead it just downloads the default, which is usually x64.

I’ve just confirmed this for myself, with the same issue as this topic. I thought things would be smooth sailing from here, but since bind mounts are not allowed I’m stuck doing this. Any advice?

It’s worth noting that this wouldn’t be an issue if bind mounts were simply allowed. I’m a bit frustrated.

It’s also worth noting that since this is a problem with the cloud builder, there’s no utility in the platform commercially for this simple task and I’m stuck using local mode/incentivised to use OpenBalena. Am I correct in assuming that this issue wouldn’t exist if I were to set up a builder myself?

Running balena build --application MyApp claimed it built it for the arch of the device target, but in fact this did not resolve this issue. So it is not a problem with the Balena cloud builder, it’s a problem with the Balena builder generally.

[matthewcroughan]

The only solution I can come up with for this is to have

3 dockerfiles for my targets
3 differences in those dockerfiles (specific architecture)

I have 4 containers.

So that’s 3 * 3 * 4 effort.

This is a problem that needs to be fixed.

[matthewcroughan]

I’ve discovered that there is no solution to this problem, and I cannot continue until it is fixed in Balena or Docker.

It’s a shame, considering this all works locally.

No way to specify arch in docker {run,pull,build}

[matthewcroughan]

Alright, I couldn’t sleep til I figured this out. This isn’t documented anywhere in Balena and it should be. It’s barely documented in Docker.

The aforementioned issue has discussion of FROM --platform which is an experimental feature. I tried this in my Balena dockerfiles and is has worked. However, this still leaves me with the X * Y * Z problem.

X = Amount of containers
Y = Amount of targets
Z = Amount of architectures

Especially when docker-compose and moby already figured this out and implemented the manifests. I would really love to see this be automatic as it already is in moby.

It is not stated anywhere in the dockerfile documentation that it is possible to use --platform in the FROM directive. But you can.

[matthewcroughan]

I’ve just discovered that the on-device builder does not know what --platform is whereas balena build and-or the cloud builder do know what --platform is when put in a FROM directive.

This is true at least on BalenaOS Ver 2.35+rev1

This means I must sacrifice local development for the ability to use the cloud builder/local builder.

[nghiant2710]

Hi @matthewcroughan,

I’m sorry for the inconvenience, this is a known issue to us however we don’t have a specific date when can we have a feature to support it yet. We will let you know when we release it.

For now, I think the best workaround should be having a Dockerfile for each target architecture for your targets as you mentioned above.

[ntzovanis]

Hi there,

We’ve just merged support for multiarch on the builder. Nothing to do on your end, but we just wanted to let you know.

Cheers!