Target board pulls mystery docker image

Technical Support
1

Environment: Windows 11, WSL2 Torizon distro, VSCode, Torizon Extension installed using the Wizard

I am trying to debug on my Ivy board. For sanity, I start fresh by deleting the Docker images on my PC and also all images on the Ivy. Then I compile/run by using the “Torizon ARMv8” target on VSCode’s “Debug” tab. After everything builds and deploys to the Ivy, the docker image now appears in Docker Desktop with the name “localhost:5002/dbpt-debug” and the tag “arm64”, and a similar image with that same name and tag also appears on my Ivy board. I can view the running container on the “containers” tab in VSCode so I know a container is now running on the Ivy. So far so good.

However, the image that is on the Ivy board is not the same image that I just built! It has a different hash than the image I see in Docker Desktop, and the date on the image (found using docker image ls) is a day old. (I can prove this to myself by adding a dummy file to the image using the dockerfile, then seeing that the file does not appear in the container running on Ivy, but does appear when I exec into the docker image I have in Docker Desktop.)

I cannot figure out where this old docker image is coming from. It does not appear in Docker Desktop as an image. I do not have any other instances of Docker running on my host PC. It is a brand new PC and I just installed WSL2 and Torizon distro yesterday, using the Wizard, so everything should be set up as expected. I looked to see if there were any other devices with this IP on my network (unplugged my PC and tried pinging it from another PC). For sanity, I can block the Ivy’s ability to pull the image by blocking port 5002 in my PC’s firewall, so I know the image is coming from the PC somehow, even though it is not in Docker Desktop. There are no other Docker daemons running on my PC – Docker daemon is not running in WSL and like I said it is a new PC with nothing on it except Docker Desktop, WSL2, and VSCode (I am using a fresh install of Torizon WSL distro).

What gives? I am pulling my hair out over this.

Steps to reproduce:

  1. Install VSCode and Torizon Extension on a brand new computer using the Wizard.
  2. Delete all images from Ivy board
  3. Delete all images from Docker Desktop
  4. Open my project in VSCode/WSL2
  5. Check “host_ip” matches my own PC’s DHCP IP and there are no conflicting IPs on my network
  6. Run “Torizon ARMv8” task on Debug tab in VSCode
  7. Observe a new docker image appears in Docker Desktop, and a new docker image appears on Ivy board.
  8. Compare the hashes/timestamps of these two images – they are not the same. They have different files inside of them as well. Where did the Ivy get its image from?
  9. Change firewall rules to block port 5002 on my PC (observe that Ivy can no longer pull the image). So, I know Ivy is getting image from somewhere on my PC, but WHERE?

I would attach my .json files and my compose.yml but Toradex.com says I can’t upload files as a new user.

Software summary

Bootloader: U-Boot
Kernel version: 6.6.84-7.3.0-devel-g7f1a54427635 #1-Torizon SMP PREEMPT Thu May 22 14:33:31 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/5d89b97dff421189a2784325484e8d39e7cef333cb07be9fd8ded11795186e1a/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-devel-20250525-build.228
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15140174

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1A
Serial number: 15140174
Processor arch: aarch64

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! Thank you for the thorough and clear description of your debugging environment and the steps you’ve taken. I understand how confusing it can be when the deployed image on your Ivy board doesn’t match what you expect.

Let’s clarify what’s happening in your described scenario.

Key Points & Diagnosis

  1. Torizon IDE Extension “Engineering Mode”
    When you’re using the Torizon IDE Extension for VS Code, it sets up “Engineering Mode” on your board and development machine. In this mode:

    • The extension builds the image inside your Torizon WSL2 distro, not in Windows or Docker Desktop directly.
    • The local Docker registry is set up within your WSL2 environment, typically broadcasting to your board.
    • Your board is instructed to pull images from the Docker registry served from inside WSL2, not from Docker Desktop on Windows.

  2. Why Your Image Hashes Differ

    • The Docker image you see in Docker Desktop comes from builds run with Docker Desktop (Windows host).
    • The image deployed to the Ivy board is being built and published by Docker running in your Torizon WSL2 instance (Linux). These are two independent Docker environments and do not share the same image cache or hash space.
    • So, even if the image names are the same, the actual images may differ, especially if there is a leftover cache or difference in build context in WSL.

  3. Where Does the Board Pull Its Image?

    • The Ivy board is configured (by the extension) to pull from the registry hosted at your WSL2 distro’s IP and port (typically localhost:5002 seen from the WSL side, which may appear as a different local IP to the Ivy).
    • The registry is the one spun up inside WSL2 by the Torizon IDE extension during debug/development.
    • You noticed the Ivy cannot pull if you block port 5002, confirming this is the correct source.

  4. Age/Content Mismatch

    • Usually this means your WSL2 Torizon Docker engine still has an older image cached (under the same name and tag), or the build inside WSL2 is not actually updating/rebuilding the image as you expect.
    • The deletion of images in Docker Desktop does not affect the images in your WSL2 Torizon environment.
    • You must also docker image ls, docker image rm, and prune images inside your Torizon WSL2 shell to completely clear out old artifacts.

What To Do Next

  1. Clear Docker Images Inside WSL2

    1. Open a shell to your Torizon WSL2 instance.
    2. Run docker image ls and docker image rm <imageid> for any relevant images.
    3. Optionally, run docker system prune -a to remove all unused images, containers, and caches.

  2. Always Build and Debug from Torizon WSL2

    • Check in VS Code: lower left corner status bar should show “WSL: Torizon” as the environment.
    • Make sure that the Docker context in VS Code is pointing to the Torizon WSL2 engine, not Windows/host Docker Desktop.
    • You can confirm this from the Docker extension “CONTEXTS” tab:
      Docker Contexts in VS Code

  3. Force a Clean Build

    • Sometimes cached layers may persist. In your project’s root (inside WSL2), run:
      docker build --no-cache -t <your_image_name>:<tag> .
    • Or use the VS Code “Clean” option if available in your build tasks.

  4. Reset the Default Device in VS Code

  5. Restart Everything for a Clean Slate

    • Close and reopen VS Code, restart your WSL2 Torizon instance (wsl.exe --shutdown in Windows), and optionally reboot your Ivy board.
    • Confirm your Docker registries and contexts are as expected.

Key Docs for Reference

Summary:
Your Ivy board is pulling the image from the Docker registry running inside your Torizon WSL2 distro (not Windows Docker Desktop). The images present in WSL2 Docker and Windows Docker Desktop are separate. To ensure no old images are used, clear images inside WSL2 and always use the WSL2 environment for building/debugging with Torizon.

If you have followed these steps and still see the wrong content, please check (inside WSL2) that the Docker build context and files are up to date at build time.

Best regards,
Toradex AI Assistant.

3

Thanks this is helpful but I am still confused. Why does Docker Desktop show a log of the build after each build, if the build is actually done in WSL2? Why does an image show up in Docker desktop after each build? Why does ps -a in WSL2 not show a docker daemon running?

This is my “default” docker context. I have two of them, and the one that is selected for use looks like this:
{
“Name”: “default”,
“Metadata”: {},
“Endpoints”: {
“docker”: {
“Host”: “tcp://192.168.11.149:2375”,
“SkipTLSVerify”: false
}
},
“TLSMaterial”: {},
“Storage”: {
“MetadataPath”: “”,
“TLSPath”: “”
}
}

This 192.168.11.149 is my Ivy board. Is Ivy doing my docker build?

The other docker context (not selected) has a very confusing name which is “docker-linux Docker Desktop”. Where in your documentation is any of this explained? Why does it not work out of the box?

4

So, there really are two different docker engines running on my PC. There is one running on the WSL2 Torizon distro (shown in ps -A) and I find it has a different set of images on it. I am running WSL2 using the networkingMode=mirrored option, which means the WSL2 instance has the same IP address as my PC, which means the docker engine there is able to serve the requests for 192.168.11.159:5002/dbpt-debug.

If I do not have Docker Desktop running when I open VSCode, I get an error from Torizon Extension complaining that Docker is not running… If I kill the dockerd process in WSL2 I get an error about Error scanning devices: Not possible to get docker network gateway. So, I am not sure how I am supposed to run this Extension with only one docker engine running on my PC, and apparently Torizon has a hard time distinguishing between the two when it comes to docker compose push vs. docker compose pull. (Somehow it pushes to one and pulls from the other??).

Meanwhile the “Docker Context” tab is utterly confusing. It does not show the WSL2 docker instance at all, and the docker context that is selected points “host” to my Ivy board’s IP address, not my PC. Please help me make sense of what this docker context tab does. Why would I want the host to be the Ivy board?

Please help me make sense of all this. What is the relationship supposed to be between Docker Desktop, Docker on the Ivy board, and Torizon WSL’s docker engine?