During a build of my project, after an update from VSCode, I get the following during the build:
failed to solve: DeadlineExceeded: torizon/debian:4: failed to resolve source metadata for docker.io/torizon/debian:4: failed to do request: Head “https://registry-1.docker.io/v2/torizon/debian/manifests/4”: dial tcp: lookup registry-1.docker.io: i/o timeout
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
The timeout error you’re experiencing when trying to download torizon/debian:4 is a network connectivity issue between your development environment and Docker Hub’s registry(1)(2). This is typically caused by DNS resolution problems, network instability, or firewall restrictions.
First, verify that your system can reach Docker Hub:
nslookup registry-1.docker.ioping registry-1.docker.io(1)If you’re using WSL2 with VS Code, ensure Docker is properly configured(2)(3):
For network instability issues, you can configure Aktualizr for low-bandwidth connections or use a pull-through cache to overcome network issues when downloading container images(4).
You can work around registry connectivity issues by:
docker save and docker load commands to handle docker images as portable tar archive files(4)If you’re using VS Code with WSL2, try running the same command from a regular command prompt outside of VS Code, as there can be differences in Docker configuration between these environments(3).
Try pulling the image manually from the command line to isolate whether this is a VS Code-specific issue or a broader network problem:
docker pull torizon/debian:4
If the manual pull works but VS Code fails, this suggests an environment configuration issue between VS Code and your Docker setup(2)(3).
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Greetings @EvetsMostel1,
This error has nothing to do with VSCode specifically. It seems like you’re PC couldn’t connect with the public Docker hub registry, for whatever network-related reason. On my side I can docker pull that container image just fine, so it doesn’t seem to be an issue with Docker hub, at least at this moment.
Is this issue reproducible? Maybe it was just a momentary network hiccup?
Best Regards,
Jeremias
@jeremias.tx
And I can pull that container just fine from my pc. I got it working, although, I don’t know what the specific fix was. I made these changes:
I added both my pc’s IP address and the Verdin’s IP address in the "insecure-registries list for both my pc and the Verdin’s docker.conf file, and restarted both.
I also changed my WSL’s and the Verdin’s nameserver from 1.1.1.1 to 8.8.8.8. After those changes, everything started working.
Can you explain this particular command? Is this using the Verdin to fetch the torizon/debian:4 image or my PC? After a VSC update, I often get this error and I would like to understand the mechanics better.
Thanks,
Steve
I don’t really understand how those changes would fix the issue that you reported.
Adding those IP addresses to the insecure-registries list would mean that Docker is authorized to perform insecure operations on registries with those IP addresses. But, torizon/debian:4 is stored on Docker hub, a publicly accessible (not insecure) registry. Why would IP addresses local to your network influence this operation?
As for the nameserver, this just changes whether you’re using the Cloudflare (1.1.1.1) or the Google (8.8.8.8) servers for dns resolution. Either should result in the same networking behavior in nearly every case.
So I can’t really explain why either of these fixed the issue for you, because neither of these should have had any effect on this issue.
Given your multiple threads related to strange network behavior. This all seems to be related to your specific setup, as no one else has reported anything similar to what you experience. Which makes it difficult to say what is going on unless a network expert was sitting beside you on the same network to debug this.
Best Regards,
Jeremias
@jeremias.tx
Well, when I did nslookup with both, I was getting a different set of IP addresses. There were some the same but usually it just uses the first one it gets. The first one was different for both.
The main thing I was asking is this done by the verdin board, or my PC. I always thought this was a local PC thing, but there were cases where I didn’t have a nameserver listed for the verdin and I got the same behavior, so I have been assuming that this request is from the device and not my PC. That is why I changed both, WSL and the verdin. The other thing is that since I did a pull and got the image, why didn’t it just use the one in the repository?
Steve
Well if you’re working in VSCode, it should be your PC that is trying to pull torizon/debian:4. Why the Verdin module would have any influence on whether your PC can access this container image would not make a whole lot of sense.
Genuinely the way this whole scenario is described sounds very illogical to me. Your “fixes” should not have had any effect on what the issue was. So either the issue was not what you think it was, or the description of this scenario is missing details that would make it make sense.
Best Regards,
Jeremias
@jeremias.tx
Well, here’s my explanation. Since I was getting different first addresses via nslookup between 1.1.1.1 and 8.8.8.8, I figured the first address was being blocked by our network. Our network is very picky and every address change to a “name” IP is picked up and the old name IP is blocked. Since I didn’t know what was causing the issue, by switching to a different nameserver, I got different results and it worked. It is the only thing that makes sense to me.
I have had issues with docker.io in the past with our network. In WSL, it has a different named server than what windows does,
I just wasn’t sure which device was doing the pull. You have clarified that for me and I do appreciate that!
Thank you,
Steve
Glad I was able to help clarify.
Best Regards,
Jeremias