Seemingly out of nothing (meaning that it still worked just today), at one point the build-container-torizon-release-arm64 task stopped building without any significant changes to the build:
Executing task: DOCKER_HOST= docker compose build --pull --build-arg SSHUSERNAME=torizon --build-arg APP_ROOT=/home/torizon/app --build-arg IMAGE_ARCH=arm64 --build-arg GPU=-am62 my-torizon-builder
WARN[0000] The "LOCAL_REGISTRY" variable is not set. Defaulting to a blank string.
Compose can now delegate builds to bake for better performance.
To do so, set COMPOSE_BAKE=true.
[+] Building 1.2s (5/5) FINISHED docker:default
=> [my-torizon-builder internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 4.33kB 0.0s
=> ERROR [my-torizon-builder internal] load metadata for docker.io/library/base:latest 1.0s
=> [my-torizon-builder internal] load metadata for docker.io/torizon/debian:next-rc 0.8s
=> [my-torizon-builder internal] load metadata for docker.io/torizon/cross-toolchain-arm64:next-rc 0.6s
=> [my-torizon-builder auth] library/base:pull token for registry-1.docker.io 0.0s
------
> [my-torizon-builder internal] load metadata for docker.io/library/base:latest:
------
failed to solve: base: failed to resolve source metadata for docker.io/library/base:latest: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
What is that image? Is this some “internal” layer? How could I debug this?
What I tried:
created a dockerhub account and ran docker login successfully
tried pulling the docker.io/library/base:latest image manually in terminal: same error message
added --no-cache to docker build compose
ran docker prune --all --force locally to remove all containers
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello! I see you’re encountering an issue where your Torizon container build is failing due to this error:
failed to solve: base: failed to resolve source metadata for docker.io/library/base:latest: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
This error occurs because docker.io/library/base:latest is not a valid image on Docker Hub and is not intended as a base image for Torizon containers. The Dockerfile is attempting to use a non-existent image, which explains why manual pulls also fail.
What should the base image be?
For Torizon applications, you should use the official Toradex Debian-based images designed for TorizonCore. For ARM64 targets, update your Dockerfile’s base image to:
FROM --platform=linux/arm64 torizon/debian:3-bookworm
Steps to resolve the error:
Edit your Dockerfile:
Replace any line that starts with FROM base or FROM docker.io/library/base:latest with the recommended Toradex image above.
Check your environment settings:
The warning:
The "LOCAL_REGISTRY" variable is not set. Defaulting to a blank string.
suggests your LOCAL_REGISTRY environment variable is not set. While this usually does not stop the build, it’s good practice to set it if you use a local container registry (source).
Clean up build cache and re-run the build:
After editing the Dockerfile, you can use docker compose build --no-cache again to ensure old cache does not interfere.
Verify your Dockerfile:
If you’re still experiencing problems, please post the relevant section of your Dockerfile for additional review.
Summary:
This issue likely surfaced now because you previously had the incorrect base image cached locally, and only now did this problem appear due to a cache clear or other change. Using the correct Toradex base image should resolve the error.
For more details, you can refer to the Torizon OS architecture documentation:
As noted by the AI, perhaps the issue surfaced after I added the --no-cache to docker compose build. However, I am able to pull cross-toolchain and debian images just fine…
To help investigate the issue could you share the following information:
What template is your project based upon?
What version of the Torizon IDE extension do you have installed currently?
Does this issue happen when you try to execute build-container-torizon-release-arm64 on a fresh project using the same template, or does it only happen when executing this task on your project with your code?
Are you on a Windows or Linux PC with VSCode?
Just want to make sure we have all the details before we try to investigate or reproduce this ourselves.
Torizon IDE Extension 3.1.100 (I am using a pre-release version, because release did not work for me initially a few weeks ago)
Docker Engine (docker-ce) 28.2.2
I also installed apt and dpkg-related utilities, which (I assume) are wrappers around dnf on Fedora, just for the xonsh scripts not to hard fail when the command is not found.
When starting afresh (creating a new project from a template), the CMake C/C++ “hello world” template builds and deploys successfully (via build-container-torizon-release-arm64):
I also noticed that the log doesn’t contain any mention of docker.io/library/base:latest. I then also added the --no-cache argument to the task and again, docker compose built just fine. Weird…
I guess the only choice is starting from a fresh template. I will get back to you with an update.
Thank you for your time, it was an error on my side. I accidentally wrote COPY --from=base instead of COPY --from=build, but obviously I had no base layer.
But the Docker error was quite confusing and it could have also pointed me to a particular line…
