Never quite sure where best to report issues. Bottom line there appears to be a bunch of image variations missing from balenalib which is making multi arch builds fail. The effect of course is that I can’t use %%BALENA_MACHINE_NAME%% in my Dockerfiles as the file is only available for some architectures.
Available:
balenalib/aarch64-alpine-node:14.16-3.13-build
balenalib/armv7hf-alpine-node:14.16-3.13-build
Not available:
balenalib/armv6hf-alpine-node:14.16-3.13-build
balenalib/amd64-alpine-node:14.16-3.13-build
Great catch! Something like this particular issue would probably be best reported directly in the GitHub repo, but, this works too.
I’ll go ahead and open up an Issue for it, and ping the maintainer. 
1 Like
Another one.
Available:
balenalib/amd64-alpine-python:3.8.10-3.13
Not available:
balenalib/raspberrypi4-64-alpine-python:3.8.10-3.13
balenalib/raspberrypi4-64-alpine-python:3.8.10
Yet there is a build for it => base-images/balena-base-images/python/raspberrypi4-64/alpine/3.13 at master · balena-io-library/base-images · GitHub
There is a 3.8.10-buster-build (balenalib/raspberrypi4-64-python:3.8.10-buster-build) → Docker Hub
But no python:3.8.10-buster or python:3.8.10-buster-run → Docker Hub
Same when pulling from arch instead. Available:
balenalib/aarch64-alpine-python:3.8
Not available:
balenalib/aarch64-alpine-python:3.8.10
Doesn’t appear to be any Python for aarch64 above 3.8.6 (Docker Hub).
Weird how some are being built and not others. Perhaps a build issue? It’s becoming quite a problem.
This has also stimulated a question. Why is %%BALENA_MACHINE_NAME%% suggested by default instead of %%BALENA_ARCH%%? It seems a pull of raspberrypi4-64-alpine is roughly the same as `aarch64-alpine’ (except 40mb difference)? Except I would need to pull a different image for each aarch64 device types if I use the device name, but with the aarch I only need to pull one that works across multiple device types?
I see a few extra packages installed in the RPI4 image, what do we lose feature wise by using the Arch image instead (base-images/Dockerfile at master · balena-io-library/base-images · GitHub)?
I also can’t seem to find any Alpine containers for arm5 or 6 at all. So the multi arch builds keep failing when I use %%BALENA_ARCH%%. Assuming they all follow the same naming convention, I can’t find any balenalib/armv6 at all but there seems to be a Dockerfile for it: base-images/balena-base-images/device-base/raspberry-pi/alpine/3.13 at master · balena-io-library/base-images · GitHub
https://hub.docker.com/layers/balenalib/aarch64-alpine-python/3.8.10-3.13-20210603/images/sha256-148f845281820a677b3d6590369f0ccfa105245ea8bb5536d1306c728fe9443c?context=explore
There is balenalib/aarch64-alpine-python:3.8.10-3.13-20210603. But for armv7hf it is balenalib/armvfhf-alpine-python:3.8.10-3.13-20210506. For some reason there are no images that have a matching date across the two architectures, again preventing building on multiple devices.
It seems there are a bunch of things here which I imagine are a work in progress. In hindsight, it seems now I may be better providing a little more specific detail on the issue I am experiencing. I am looking to use the following images:
balenalib/%%BALENA_ARCH%%-alpine-python:3.8.10-3.13-20210506
balenalib/%%BALENA_ARCH%%-debian-python:3.8.10-buster-20210506
balenalib/%%BALENA_ARCH%%-debian-python:3.8.10-buster-build-20210506
At the moment though, they exist on some architectures and not others.
Do you this is something that will fall on the radar sometime soon, or should I be looking for a workaround in the meantime?
Hey @maggie0002 ,
Just want to let you know that all the images you mentioned are now available, sorry for the inconvenience since we’re having some changes in the build servers so some tags are not built as expected.
Please let us know if you need further support
Thanks @nghiant2710. I’m struggling to find the Raspberry Pi Zero images though. Do they come under balenalib/armv5e? It doesn’t seem like there is an Alpine one. Nor can I find some of the date stamped images (such as balenalib/aarch64-alpine-python:3.8.10-3.13-20210506). I am looking to use each of the following architectures:
armv5/armv6 (raspberry pi zero)
armv7hf
aarch64
And these images:
balenalib/%%BALENA_ARCH%%-alpine-python:3.8.10-3.13-20210506
balenalib/%%BALENA_ARCH%%-debian-python:3.8.10-buster-20210506
balenalib/%%BALENA_ARCH%%-debian-python:3.8.10-buster-build-20210506
Hey @maggie0002,
You can use balenalib/rpi-alpine-python:3.8.10-3.13-20210506 for armv6 (raspberry pi zero). armv5 is no longer supported so we don’t have any base images for that architecture.
Will %%BALENA_ARCH%% resolve to RPI automatically? I am trying to deploy to multiple devices through one Docker-compose file.
And there doesn’t appear to be matching date tag on the RPI images. It is set to 20210506 as you mentioned in the example in your post, but the aarch64 and armv7hf are 20210603.
I ran a deploy and can confirm that %%BALENA_ARCH%% does resolve to ‘rpi’ when deploying to that architecture which is good news.
It seems then the only issue left is that there isn’t a corresponding image for RPI with the same date as aarch64 and armv7fh. This one fails:
balenalib/rpi-alpine-python:3.8.10-3.13-20210603
Or balenalib/aarch64-alpine-python:3.8.10-3.13-20210506 is missing if the goal is to have the dates as 20210506
@nghiant2710 would this be possible today? I was hoping to get this deploy done before the weekend.
Hey @maggie0002, sorry I wasn’t around last week so couldn’t make this sooner, just want to let you know that balenalib/rpi-alpine-python:3.8.10-3.13-20210603 and balenalib/aarch64-alpine-python:3.8.10-3.13-20210506 are now available
1 Like
@nghiant2710 I have moved one of my containers to Alpine and missing the following container:
balenalib/rpi-alpine-python:3.8.10-3.13-build-20210603
Could you add it?
@nghiant2710 any chance it could be this week?
hey @maggie0002, just want to let you know the image you requested is available.
1 Like