Verdin IMX8MP - Deploying Docker Containers for Debug Using the Torizon IDE: Failing at docker pull

Technical Support
, ,
1

Hello,

I’ve been trying to get a simple “hello world” program to compile and deploy to my IMX8MP using the Torizon IDE VSCode extension. When I try to deploy the container for debugging, it builds and pushes fine, but fails at the pull step, displaying this output:

 Executing task: DOCKER_HOST=172.16.16.107:2375 LOCAL_REGISTRY=172.16.16.57 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose pull test-debug 

WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string. 
[+] Pulling 1/1
 ! test-debug Warning Get "http://172.16.16.57:5002/v2/": net/http: request canceled while waiting for connection (Client.Timeout ex...                    30.0s 
WARNING: Some service image(s) must be built from source by running:
    docker compose build test-debug
1 error occurred:
        * Error response from daemon: Get "http://172.16.16.57:5002/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)



 *  The terminal process "/usr/bin/bash '-c', 'DOCKER_HOST=172.16.16.107:2375 LOCAL_REGISTRY=172.16.16.57 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose pull test-debug'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

I have tried running this on the current version of the Torizon IDE (3.1.0), the pre-release version (3.1.100) and the older version with an older version of docker (3.0.4 and 1.29.6 respectively), as recommended in the other cases that I’ve seen, but have had no luck.

I’ve verified that the IP addresses are correct and that the ports are available.

Here’s the output of tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15230162
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0058 V1.1B
Serial number:            15230162
Processor arch:           aarch64
------------------------------------------------------------

Any help getting this up and running would be appreciated.

Thanks,
Andrew

2

Hi, I’m the Toradex AI Assistant.

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? :+1: :-1:

Hello Andrew,

Thank you for your detailed description and logs.

Based on your output, the key part of the error is:

Get “http://172.16.16.57:5002/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

This indicates that your development environment (or the VSCode IDE extension) is unable to reach the local container registry running at 172.16.16.57:5002. This registry is required for deploying and debugging containers using the Torizon VSCode extension.

Here are some steps you can follow to resolve this issue:

  1. Confirm the Registry Service Is Running
    Make sure the local Docker registry is running on your development PC and is listening on port 5002. You can check this by running on your development machine:
docker ps | grep 5002

You should see a running registry container listening on 0.0.0.0:5002->5000/tcp.

  1. Test the Registry from Your Development Machine
    Try visiting http://172.16.16.57:5002/v2/ from your browser or curl:
curl http://172.16.16.57:5002/v2/

You should get a “{}” response if the registry is up.

  1. Network Connectivity and Firewalls
  • Ensure there is nothing (e.g., firewall, antivirus software, or VPN) on your development machine or network blocking access to port 5002.
  • From the target device (your IMX8MP), try running:
    curl http://172.16.16.57:5002/v2/
    This should also return “{}”. If it times out, the registry is not reachable from the device.

  1. Windows-Specific Notes
    If you are on Windows, make sure your VSCode project workspace and source files are located in the Linux filesystem, not under anything like C:\ or /mnt/c/ (if using WSL). Otherwise, you may encounter similar connectivity issues.
    More info:
    Add Packages, Libraries, Tools and Files | Toradex Developer Center

  2. Restart the Local Registry
    If you suspect the registry may not have started or is stuck, use:

docker container restart <name-of-registry-container>

Or stop and re-start the Torizon extension in VSCode, which should re-initiate the local registry setup.

  1. Docker Version Compatibility
    While you have already tried with different Docker and extension versions, ensure both Docker Desktop/Engine and the extension are up-to-date for your OS.

Summary

  • The problem is not the Torizon device or image, but the accessibility of the local Docker registry from the point where the “pull” happens.
  • Focus troubleshooting on ensuring the registry running at 172.16.16.57:5002 is healthy and reachable from both development PC and the IMX8MP board.

If you need more details on these steps or want to provide output of the curl tests, I can help you narrow it down further.
Resource links for reference:

Best regards, Toradex AI Assistant.

3

In response to the @ToradexAI suggestions,

Running curl http://172.16.16.57:5002/v2/ on my development (Windows) machine and my host (IMX8MP) both return a message that they failed to connect to the server.

Running docker ps | grep 5002 on my development machine returns nothing.

Any advice on where to go from here would be appreciated.

Thanks,
Andrew

4

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Hello Andrew,

Thank you for sharing these test results. Since both your development machine and the IMX8MP device cannot connect to the registry on port 5002, and docker ps | grep 5002 shows no registry running, the root cause is that the local registry required by the Torizon VS Code Extension is not running.

Here’s how to get things back up and running:

  1. Restart VS Code Completely
    Close all VS Code windows, then relaunch VS Code. This usually prompts the Torizon extension to automatically start a local registry container on your development PC.

  2. Ensure You Are Connected to the Device in the Torizon Extension
    Make sure your target device is connected via the Torizon IDE extension and set as default:

  1. Try to Start a Debug Session
    Once connected, initiate a debug session via F5 or the Run and Debug tab in VS Code.
    When you do so, the extension should:
  • Launch the registry container (you should see it via docker ps, usually named like vscode_dev_container_registry)
  • Configure your target to communicate with it

  1. Check that the Registry Is Running
    After performing the steps above, on your development PC, run:
    docker ps | grep registry
    or
    docker ps | findstr 5002
    You should see a container listening on 0.0.0.0:5002->5000/tcp.

  2. Confirm Network Access
    Try running:
    curl http://localhost:5002/v2/
    from your development PC.
    If this works, but you still have issues connecting from your board, ensure that your PC’s firewall allows access to port 5002 on your local network.

  3. If the Registry Does Not Start
    If you still do not see a registry container running, it’s possible your VS Code Torizon extension setup or workspace is misconfigured. Consider:

  • Reinitializing your workspace (close the folder, re-clone it or reinitialize using the Torizon extension)
  • Updating the Torizon extension to the latest version
  • Checking if Docker Desktop/Engine is running and healthy on your PC

Related documentation:

If you try these steps, let me know at which point something goes wrong (e.g., registry still doesn’t show up in docker ps). We can further narrow down the cause from there.

Best regards, Toradex AI Assistant.

5

In response the second set of @ToradexAI suggestions,

There is still no response to any of the docker ps commands.

When I run curl localhost:5002/v2/ or open it in browser, I do see the {} response indicating that there is a container there. However, when I try either from the ip address in the first message in the post, I get no response.

Thanks
Andrew

6

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Thank you for your update, Andrew.

The key detail now is that curl http://localhost:5002/v2/ returns {}, but curl http://172.16.16.57:5002/v2/ does not—this shows the registry is running, but only bound to localhost (127.0.0.1), not all interfaces (0.0.0.0). Therefore, it is not reachable using the machine’s IP, which is required by Torizon IDE and your target device.

To address this, please follow these steps:

  1. Stop the Existing Registry
    First, stop and remove the currently running registry container. You can find its container ID or name using:
docker ps | grep 5002

Then stop and remove it:

docker stop <container-id-or-name>
docker rm <container-id-or-name>
  1. Launch the Registry Bound to All Interfaces
    Now, start a new registry container with explicit binding to 0.0.0.0:
docker run -d -p 5002:5002 --restart always --name registry -e REGISTRY_HTTP_ADDR=0.0.0.0:5002 registry:2

This ensures the registry is accessible from both localhost and your machine’s IP address.

  1. Verify Accessibility
    Check that it’s running with:
docker ps | grep 5002

And check from both your development machine and from your IMX8MP:

curl http://localhost:5002/v2/
curl http://172.16.16.57:5002/v2/

Each should return {}.

  1. Update Docker Daemon (on the Target)
    On your IMX8MP, make sure /etc/docker/daemon.json includes (update IP as needed):
{
  "insecure-registries" : ["172.16.16.57:5002"]
}

See: Store and Share Container Images | Toradex Developer Center

Then, restart the Docker service:

sudo systemctl restart docker
  1. Restart VS Code and Torizon Extension
    Close and reopen VS Code on your development PC, and re-initiate the deployment/debug workflow.

After these steps, both your PC and IMX8MP should be able to reach the registry via http://172.16.16.57:5002/v2/, resolving the deployment issue.

For more, see:

If you encounter further issues, please share which step fails and any console output.

Best regards, Toradex AI Assistant.

7

After going through this set of suggestions (except explicitly binding 5002:5002, because the extension & the IMX8MP expect a binding of 5002:5000), the docker container does show up when I run docker ps | grep 5002, but the pull step still fails.

8

Greetings @aweaver,

Just to confirm and understand. You said all the IP address are correct.

So 172.16.16.107 is the IP address of the Toradex module, and 172.16.16.57 is the IP address of your PC that is running VSCode, correct?

You said earlier that docker ps | grep 5002 did not return anything on your PC. Which means there was no registry container running prior on your PC, correct?

You then manually started your own registry container. What I find odd here is that the extension should create this registry container itself automatically. But it seems like that is not happening in your case.

In VSCode, do you not see any logs about trying to start a registry container or something similar? Maybe there is a warning or error there.

Best Regards,
Jeremias

9

Hi @jeremias.tx,

Yep, those IPs are correct.

When I tried docker ps | grep 5002 the first time, nothing showed up. However, upon restarting VSCode, a container appeared. I think I probably ended up interrupting the startup previously, resulting in the container not being properly created. When I tried building and deploying an application without a container running (I’d manually removed it for testing’s sake due to the same concern that you had raised), it failed far earlier in the process. I think that the missing container was a one-time issue, as it automatically created every time I restarted WSL/VSCode from there on out.

After double checking that, I still faced the same issue that I did in my original message, and curling 172.16.16.57:5200/v2/ still times out.

Regards,
Andrew

10

An update:

After changing around some of my IP settings, I realized I was actually using the wrong address for my development machine (oops). Now, I see the proper output when I curl 172.17.171.158:5002/v2/. However, now I’m faced with a new issue. The output of the pull step of the deployment process is now:

Executing task: DOCKER_HOST=172.16.16.107:2375 LOCAL_REGISTRY=172.17.171.158 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose pull test-debug 

WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string. 
[+] Pulling 1/1
 ! test-debug Warning Get "http://172.17.171.158:5002/v2/": dial tcp 172.17.171.158:5002: connect: no route to host                                         6.2s 
WARNING: Some service image(s) must be built from source by running:
    docker compose build test-debug
1 error occurred:
        * Error response from daemon: Get "http://172.17.171.158:5002/v2/": dial tcp 172.17.171.158:5002: connect: no route to host



 *  The terminal process "/usr/bin/bash '-c', 'DOCKER_HOST=172.16.16.107:2375 LOCAL_REGISTRY=172.17.171.158 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose pull test-debug'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.
11

Pretty sure it’s a firewall issue. The IMX8MP can’t contact the port it’s looking for, so I’ll work on getting that allowed on my device. Will update once I’ve tried that.

12

Pretty sure it’s a firewall issue.

This is what I was beginning to suspect as well. If the IPs are correct then something must be blocking/preventing the connection. Especially since the error you got was a timeout error. This usually means an initial connection was made but could not be completed before the timeout period.

Best Regards,
Jeremias

13

After going through my firewall settings myself and with our security provider, we found no issue with the communication over that network. Having ruled everything else I can think of out, I believe it may be an issue with the bridge between the WSL virtual ethernet address and my computer’s actual IP address. It seems like the port forwarding/listening set up by the IDE extension at system startup is not being properly done, or that WSL/Windows itself is not finding that connection.

In the meantime, I was able to get docker containers up and running without using the Torizon IDE extension by just writing my own Dockerfiles and docker-compose files, then compiling and building it on the IMX8MP itself using docker. I think this will likely be the way that we do it for our project.

Regards,
Andrew

14

It seems like the port forwarding/listening set up by the IDE extension at system startup is not being properly done, or that WSL/Windows itself is not finding that connection.

Interesting, well I don’t believe it’s a default configuration. I’m able to use the IDE extension on my Windows/WSL setup, and I don’t believe I did anything out of the ordinary with my setup. Have you tried maybe reinstalling/resetting your WSL installation?

I believe the installation wizard for our IDE extension installs a specific WSL environment that is designed to be used alongside the VSCode extension. Did you use this or another WSL environment?

I think this will likely be the way that we do it for our project.

This approach is perfectly fine as well. Though I imagine you wanted to use the IDE for a reason. It would be a shame if you couldn’t use it. Unless you’re okay with not using an IDE for development.

Best Regards,
Jeremias

15

Hi @aweaver ,

Are you all set here?

Best,

16

Yes, thank you.

After looking through the startup files on my computer, I found that one of the WSL startup scripts from the previous user was still configuring my WSL IP. I haven’t changed their configuration and gone back to using the IDE extension, because I’m used to writing and deploying my own dockerfiles now. If I do manage to undo their configuration, I may try the extension again, but am fine writing my own for now.

Regards,
Andrew

17

Thank you for reporting back. Glad we were able to help.