Target board pulls mystery docker image

Technical Support
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.