Possible bug? Pulling TorizonCore Builder in VS code vs in command prompt

srzm · March 10, 2025, 2:28pm

Took me couple days to figure this out…

TorizonCore Builder was not working and wouldn’t pull due to “linux/arm64/v8” - not sure how that was detected. This is frustrating, because I know I’ve used the TorizonCore builder before.

I’m on my host PC, using WSL2.

~/tcbdir$ source tcb-env-setup.sh 
Warning: If you intend to use torizoncore-builder as a server (listening to ports), then you should pass extra parameters to "docker run" (via the -- switch).
TorizonCore Builder is not installed. Pulling the latest version from Docker Hub...
Setting up TorizonCore Builder with version 3.

Pulling TorizonCore Builder...
3: Pulling from torizon/torizoncore-builder
no matching manifest for linux/arm64/v8 in the manifest list entries

I was using VS code, connected to WSL remotely, and tried to pull from there, so it wouldn’t work. However, if I use the command prompt, outside of VS code, it works just fine.

~/tcbdir$ source tcb-env-setup.sh
Warning: If you intend to use torizoncore-builder as a server (listening to ports), then you should pass extra parameters to "docker run" (via the -- switch).
You may have an outdated version installed. Would you like to check for updates online? [y/n] y
Setting up TorizonCore Builder with version 3.

Pulling TorizonCore Builder...
3: Pulling from torizon/torizoncore-builder
Digest: sha256:0ede18c22ea1cdc8b679064a024db3c744b9b5bcef27c5334bc6b37fcbc12e47
Status: Image is up to date for torizon/torizoncore-builder:3
docker.io/torizon/torizoncore-builder:3
Done!

Setup complete! TorizonCore Builder is now ready to use.
TorizonCore Builder internal status and image customizations will be stored in Docker volume named 'storage'.
********************
Important: When you run TorizonCore Builder, the tool can only access the files inside the current working directory. Files and directories outside of the current working directory, or links to files and directories outside of the current working directory, won't be visible to TorizonCore Builder. So please make sure that, when running TorizonCore Builder, all files and directories passed as parameters are within the current working directory.
Your current working directory is: /home/srzm/tcbdir
********************
For more information, run 'torizoncore-builder -h' or go to https://developer.toradex.com/knowledge-base/torizoncore-builder-tool

Thought I should post it out here in case others have same issue.

ToradexAI · March 10, 2025, 2:30pm

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello,

It seems you’re encountering an issue with pulling the TorizonCore Builder tool in VS Code due to an architecture mismatch error (“no matching manifest for linux/arm64/v8”). This discrepancy between VS Code and the command prompt is likely due to differences in Docker configuration.

Here are some steps to help resolve this:

Check Docker Architecture Settings: Ensure that Docker in VS Code is configured to use the correct architecture. This can be done by reviewing the Docker settings in VS Code to match your host system’s architecture.
Verify WSL2 Configuration: Make sure your WSL2 environment is properly set up to work with Docker. Sometimes, VS Code might have different environment variables or settings that affect Docker’s behavior.
Docker Context in VS Code: Confirm that the Docker context in VS Code is set to the correct WSL2 instance. This can be checked in the Docker extension settings within VS Code.
Update VS Code and Extensions: Ensure that both VS Code and the Docker extension are up to date, as updates can resolve compatibility issues.
Compare Environment Variables: Look for any differences in environment variables and Docker settings between your command prompt and VS Code that might be causing the issue.

By following these steps, you should be able to align the Docker behavior in VS Code with that of the command prompt, resolving the architecture mismatch error.

I hope this helps! If you have any more questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Docker error when deploying to device from Torizon Visual Studio plug-in.

jeremias.tx · March 10, 2025, 5:22pm

Greetings @srzm,

This doesn’t seem like a bug related to TorizonCore Builder specifically. It’s Docker that is doing the pulling of the TorizonCore Builder container image. For whatever reason in the first case Docker thinks it’s on an arm64-based system and is trying to pull that architecture, which we don’t have an arm64-based container image for this tool. The question then is, why does Docker think it’s an arm64-based system in your first case?

Here’s some tests to try:

In the same environment as your first case could you try running docker info and provide the output.
If you try to docker pull some other container image, does it also try to get the arm64 version?
Could you share the environment variables set if any.

Best Regards,
Jeremias

srzm · March 10, 2025, 5:28pm

FYI - I’ve removed some lines to maintain privacy, but I may have overdone it.

~/tcbdir$ docker info
Client: Docker Engine - Community
 Version:    28.0.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.21.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.33.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 3
  Running: 2
  Paused: 0
  Stopped: 1
 Images: 6
 Server Version: 20.10.25-ce
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1e1ea6e986c6c86565bc33d52e34b81b3e2bc71f.m
 runc version: v1.1.4-8-g974efd2d-dirty
 init version: b9f42a0-dirty
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.15.148-6.8.1+git.1cbf48124747
 Operating System: TorizonCore 6.8.1+build.25 (kirkstone)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 3.83GiB
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  xxxxxxxx
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: API is accessible on http://0.0.0.0:2375 without encryption.
         Access to the remote API is equivalent to root access on the host. Refer
         to the 'Docker daemon attack surface' section in the documentation for
         more information: https://docs.docker.com/go/attack-surface/

Not sure what else to docker pull at the moment to tell you what version it pulls.

What are the environment variables? In the VS code, or in the PC itself?

jeremias.tx · March 10, 2025, 6:52pm

Based on your docker info output, namely this section:

...
 Kernel Version: 5.15.148-6.8.1+git.1cbf48124747
 Operating System: TorizonCore 6.8.1+build.25 (kirkstone)
 OSType: linux
 Architecture: aarch64
...

It would appear you are executing Docker commands in the context of the Toradex module and not your host PC.

You, probably have the DOCKER_HOST environment variable set due to VSCode. Check if this variable is set, and if so unset it when running any Docker based operation. This is basically the same issue as in this other thread: Docker info Architecture in the vscode terminal

Best Regards,
Jeremias

srzm · March 11, 2025, 8:28pm

Interesting…

I have the tcbdir open in the explorer, so there’s not really a docker open other than the torizoncore builder, and that happens when I source tcb-env-setup.sh…

I even looked in the settings.json under .vscode folder, and unset the DOCKER_HOST

  "docker.environment": {
    "DOCKER_HOST": "",
    "DEBUG_SSH_PORT": "2222",
    "DEBUG_PORT1": "2222",
    "DEBUG_PORT2": "2223",
    "DEBUG_PORT3": "2224"
  },
  "torizon_psswd": "torizon",
  "torizon_login": "torizon",
  "torizon_ip": "192.168.4.18",
  "torizon_ssh_port": "22",
  "host_ip": "192.168.4.25",
  "torizon_gpu": "-vivante",
  "torizon_arch": "aarch64"
}

Still same issue as above.

jeremias.tx · March 12, 2025, 12:08am

You must have DOCKER_HOST set still, or something similar. There’s no way docker would just randomly decide to execute TorizonCore Builder on the Toradex module without reason. By default docker executes on the host machine unless something tells it not to. The most common reason would be that DOCKER_HOST is set in your environment somewhere, somehow.

In this terminal where you are seeing this behavior what is the output of printenv?

Best Regards,
Jeremias

michael.tx · March 13, 2025, 2:13pm

Hey Sara,

Any updates here for us?

Best,

Michael Park
Toradex

srzm · March 13, 2025, 3:04pm

I restarted the computer and it’s working now in VS code. Maybe the cache was still there.

A simple “have you tried turning it off and on?” trick worked.

Thanks again @jeremias.tx .

@michael.tx all good from my side!

jeremias.tx · March 13, 2025, 8:32pm

Glad to hear you were able to resolve the issue.