exec user process caused "exec format error"

Started getting this error, reverted to old version that was working but still displays the error even when the new build uploads. Reflashed the sd card in the rpi with no resolution.

main  standard_init_linux.go:211: exec user process caused "exec format error"
main  standard_init_linux.go:211: exec user process caused "exec format error"
Service exited 'main sha256:15b3667c4bf513bc3e910d1fbf072b09a995e3a1cb092ba2d637428831a49060'

Dockerfile:

FROM node:8
WORKDIR /app
COPY package*.json  ./
RUN npm install
COPY . .
EXPOSE 3333
CMD ["node", "app.js"]

I have seen similar issues on here but nothing about it suddenly happening. Most day the dockerfile is the issue but the dockerfile was not changed when the issue started.

Hi, I see you’re using the official node:8 base image from docker hub. When you’re pushing that to our cloud builder it won’t understand which device-type to target with the image and defaults to amd64.

In order for it to properly understand what device to build for you can do one of two things:

We’re actively working on supporting the docker base-images properly, so your above Dockerfile should work as-is at some point in the future :slight_smile:

I’m experiencing the same problem. I’ve been running my project on local-mode using balena push, and it’s been working great. Which makes sense as I’m building the images locally using the --emulate flag for the build.

I don’t understand why Balena Cloud can’t work with the official base images which all support the architecture I’m building for. In examples by @klutchell such as balena-pihole and balena-nginx-proxy-manager the Dockerfiles don’t call the Balena machina: balenalib/%%BALENA_MACHINE_NAME%% or a tag especific to arm, such as balenalib/armv7hf-debian.

What’s the catch with my project not building for the correct architecture? Do I need to pass a Dockerfile as build option on the docker-compose?

Hey @luandro, since this was originally posted in 2020 we now support both single arch and multi architecture base images via our CLI and via our cloud builders. I actually use both methods when developing these projects.

Can you describe exactly which commands you ran, and what was the expected result vs the results you got?

Typically when using balena push would you provide a fleet name, and the default device type of that fleet would be used to pull and build images for the correct platform.

Also note that when using balena push with our cloud builders you do not need the --emulated flag as we have native ARM builders that are usually much faster.

Thanks for the quick reponse @klutchell. With push, using local-mode everything is working fine. The problem is when we use deploy and the cloud builders with production images, which are all making our services go: exec format error.

The project is here, are we missing something?

Hey @luandro,

Just to make sure we are on the same page, the balena deploy command does not use the balena builders but is meant to be used with the balena build command or the balena deploy --build flag. These commands will build the images locally on your workstation before deploying them to your fleet, optionally with emulation.

In order to use our cloud builders you need to use balena push <fleet> and you don’t need to use emulation here.

When using balena push <device> the images are built on the device so the target platform matches the build platform.

I suspect that your balena deploy command is pushing x86_64 images to your fleet because they were built locally as x86_64. Even with the emulation flag your workstation Docker daemon will pull whichever images seem appropriate for your workstation, not for your fleet. This is a known issue that our emulation flag does not set the Docker --platform currently.

The easiest workaround for this is to use our cloud builders with balena push <fleet>.

Another workaround to allow you to continue building on your workstation is to go through each of the multiarch images in your compose file and pull them manually for the target platform. Then you can use balena build and balena deploy as expected.

docker pull --platform linux/arm64 jellyfin/jellyfin
docker pull --platform linux/arm64 filebrowser/filebrowser
...
balena deploy --build --emulated --fleet <fleet>

I hope this helps! Cheers!

1 Like

Hey @luandro, just a heads up that CLI releases v12.49.0 or later should attempt to pull the correct target architecture if all the images in the compose file are multi-arch.

However if even one of the images is single-arch it will not set the platform flag during pull, and it will print some warnings to this effect. So mixed compose files are not as well supported and we have to make certain assumptions before quietly injecting the --platform flag to the host Docker daemon.

Also if my workaround of pulling the images manually before running a build/deploy works for you that is still an option.

1 Like

Thanks for all the info @klutchell, I’ve been following what you wrote and it’s been working fine for all projects.