I’m migrating to RPI 4 64 OS and have problems with my 32-bit app. My container relies on balenalib/armv7hf-debian. All is built ok including the correct architecture used (see below).
However, uname -a within the container returns aarch64 and my service won’t start with the following error:
filebeat Failed to initialize: trying to run 32Bit binary on 64Bit system
Why the container built runs on wrong architecture? Everything works well with RPI 3.
container orchestration uses the kernel of the host operating system.
As you’re using an RPi 4 with 64 bit OS, your container will use the 64 bit kernel and work as that, at least that is my understanding. I think the only way to get a 32 bit container running is to use an 32 bit kernel if I am not mistaken.
Actually not @nmaas87 if you run a 64bit balenaOS you can run 32bit containers. You can’t run 64bit containers on 32bit balenaOS
Let me explore this @filemon could you please share more information of the service that you are running? I can see that the problem might be that binary… so not sure if this is an open-source project we can try to replicate!
I was aware that 32 bit software does run on 64 bit hardware/kernel without a hitch, but I was not aware that you could “pressure” the environment to really switch it to 32 bit, including memory region locks, etc. interesting :). Do you need to put a special tag to the container so that it completely switches to 32 bit mode and not “mere emulation”?
Yes. I had an impression if I pick the 32-bit balenalib image (like armv7hf-debian in my case) I would see armv7hl when running ‘uname -a’. This is what happens when I run this container on raspberrypi3 base image.
I see aarch64 instead. This filebeat service is one case, which I might to solve by recompilation. However I have another service, which I can’t change easily to 64-bit, so I would like to better understand this mixed-architecture feature beforehands. I will pack the filebeat service so you can check yourself @mpous.
Just to clarify @filemon@nmaas87 from the ARM CPU side, the ARMv8-A is backwards compatible with AArch32. That means that from the Linux kernel, the 64bits kernel can run 32-bit applications if configured properly. Then running them in containers might just work fine.
I would see armv7hl when running ‘uname -a’.
The kernel is your host’s kernel. This is why you see the 64 bit kernel instead of the 32bit.
@filemon is the application compiled with deprecated compiled flags and things like that? Some instructions have been deprecated were supported in aarch32 but will not work in armv8. Read more here Documentation – Arm Developer
Hi @mpous, initial problem solved by recompilation of the filebeat for aarch64.
I have a question though. My fleet contains now a mix of RPI3 and RPI4. When I issue a ‘balena push’ command, raspberry3 is taken as a device type and used instead of %%BALENA_MACHINE_NAME%%.
Shouldn’t Balena build actually a separate release for each type of device I have in my fleet? Or should I have a separate fleet per device type? This wouldn’t be very handy as you can’t easily copy one fleet settings (variables, configurations) to another fleet as far as I’m aware.
Hello @filemon first of all apologizes for the delay answering this message.
Raspberry Pi 3 and Raspberry Pi 4 are the same Device Type, even they can run on different 32 vs 64 bits. There shouldn’t be a problem if you forced on the Dockerfile that the base image is based on raspberrypi3 instead of %%BALENA_MACHINE_NAME%%. I also do this on specific containers that need to run on 32 bits.
yes, this works well. I use debian bullseye, so I needed to add a new architecture arm64 next to default one armhf (dpkg --add-architecture arm64) and install arm64 version of libc6 to run my program. So all good now.
