Resin Build Variable Inconsistency

Product support
,
1

I was trying to update this documentation with information for the Raspberry Pi 3. When running commands to get the appropriate variable values, I noticed that the build machine gives uname -m to be armv8l although the final image running on the device gives uname -m to be armv7hf.

This actually has impact on a docker install script I’m trying to use to run the docker-in-docker hack, the script is here. It reports that armv8l is not supported, although the final image can run the installation because it is actually armv7hf.

It makes sense that the builder can use the architecture it desires separate from the device, but I should also be able to build to the architecture I expect to be running in the final image. Is this intentional?

2

Hey @dagrooms52, builders maintainer here;

The RESIN_ARCH variable should always be the same architecture as the device that you are installing onto. The uname binary on the other hand makes a syscall to the builder kernel, which stays the same across builds. That would explain why your install script is not working, as there is the line:

architecture = $(uname -m)

which gives armv8l, and I guess docker does not have an entry for that exact arch string.

I see three ways of solving this in the short term, and I’m going to implement a fix which should be available in the next week or so.

  1. You could trick your system into getting the correct value for your device type. If you added this RUN step before the docker install script runs it should work:
RUN cp `which uname` /bin/uname-orig && echo '#!/bin/bash\nif [[ $1 == "-m" ]]; then echo "armv7l"; else /bin/uname-orig $@; fi;' > `which uname`
  1. You could pull down the docker source in your build process, and build that. I’ve done this before, and IIRC the output binary can be ran on the raspberry pi, but if I’m remembering incorrectly you can control the output architecture by setting GOOS=linux GOARCH=arm before building.
  1. You could run the docker install step at runtime, rather than buildtime. This method would definitely work, but it would delay the startup of your application by quite a hefty amount. This would be my “last resort” suggestion.

I’ve tested method number 1 and can confirm that docker gets installed.

Let me know if you run into any issue or you want some further clarification :slight_smile:

Cameron

2 Likes
3

Hey @dagrooms52 , just dropping into this thread to update you that the balena Native ARM builders now correctly identify their architecture as armv7l when building for the RPI3(release announcement), so you should now be able to build your project with out issue now.