Right, what seems to be the case is that the images which are very old and no longer maintained (e.g. balenalib/raspberrypi3-alpine-node:6-3.6-20181025) have an architecture of linux/amd64. This is a problem when you push to a fleet with an arm architecture as the builders then detect a mismatch and fail. These images are in some cases 4 years old and long since deprecated and so we’re not going to go back and update them.
From our side, this is correct behaviour, but I appreciate something that was working yesterday is now failing today which is frustrating. In that case, aside from imploring you to use an updated and maintained image, which I know is not always possible in available timescales, the best way forward may be to just take the base image into your own hands. This means:
- On your local machine (with Docker installed and logged in to your own Docker Hub account - you’ll need to create one), create a new
Dockerfilewith just one line: FROM . Again in the case of the example above the file would just containFROM balenalib/raspberrypi3-alpine-node:6-3.6-20181025. - In the directory where you just made the
Dockerfilerundocker buildx build . --platform linux/arm/v7 --tag <your DH username>/raspberrypi3-alpine-node:6-3.6-20181025. Note that we’re specifying here the exact same repository name and tag as we want to use, but you can rename it to what you want at this point. The platform is important as we’re specifying the architecture of the fleet you want to use. - After the build is complete, run
docker push <your DH username>/raspberrypi3-alpine-node:6-3.6-20181025. - Update your original
Dockerfileto point to the new image in your repository instead of thebalenalibone.
The build should then work. Of course this means that the image wont be updated, but in the case of these very old deprecated images they aren’t being updated anyway.
Let us know if this helps.