But if i try to debug from my host pc it always fails with:
WARNING: Some service image(s) must be built from source by running:
docker compose build mycobot-toradex-debug
1 error occurred:
* Error response from daemon: manifest for 10.131.90.37:5002/mycobot-toradex-debug:arm64 not found: manifest unknown: manifest unknown
If I run the failing step from the board:
torizon@verdin-imx8mp-07174496:~$ LOCAL_REGISTRY=10.131.90.37 TAG=arm64 docker-compose pull mycobot-toradex-debug
WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string.
[+] Running 1/1
! mycobot-toradex-debug Warning 0.1s
WARNING: Some service image(s) must be built from source by running:
docker compose build mycobot-toradex-debug
1 error occurred:
* Error response from daemon: manifest for 10.131.90.37:5002/mycobot-toradex-debug:arm64 not found: manifest unknown: manifest unknown
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
The issue you’re encountering seems to be related to the mismatch between where the container image is being pushed and where it’s being pulled from. Here are a few steps to troubleshoot and potentially resolve the issue:
Check Image Tagging: Ensure that the image is tagged correctly with the IP address of your host PC (10.131.90.37:5002) before pushing it to the local registry. You can do this by using the docker tag command:
docker tag mycobot-toradex-debug:latest 10.131.90.37:5002/mycobot-toradex-debug:arm64
Push to the Correct Registry: After tagging, push the image to the local registry:
Verify Local Registry Configuration: Ensure that your local registry is set up correctly and is accessible from the Verdin board. You might need to configure Docker to allow communication with an insecure registry if TLS is not set up:
Modify the Docker daemon configuration on the Verdin board to allow the insecure registry by editing /etc/docker/daemon.json:
{
"insecure-registries" : ["10.131.90.37:5002"]
}
Restart the Docker service after making changes.
Check Docker Compose Configuration: Ensure that your docker-compose.yml file is correctly referencing the image with the full registry path:
Rebuild and Push the Image: If the image was initially built with a different tag, you might need to rebuild it with the correct tag and push it again.
By ensuring that the image is correctly tagged and pushed to the local registry, and that the Verdin board is configured to pull from this registry, you should be able to resolve the issue. If the problem persists, double-check network connectivity between the host PC and the Verdin board, and ensure there are no firewall rules blocking access.
Please, also check if these links can help you solve your problem:
Interesting, glad you were able to resolve this on your end. Sometimes Docker Desktop updates can cause such strange behaviors. It’s why some prefer to just have the Docker engine installed and work with that instead of having the entire Docker Desktop stack installed.
