Source tcb-env-setup.sh thinks it's source tcbbuilder to a arm64 host

Technical Support
, , ,
1

When I run: source tcb-env-setup.sh on my Windows amd64 WSL linux, it returns:
docker: no matching manifest for linux/arm64 in the manifest list entries . Why is it doing that? This used to work.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

This error is typically related to Docker version compatibility issues and ARM emulation configuration. Here are the most likely causes and solutions:

Docker 29 Incompatibility

If you’re using Docker v29, this is a known compatibility issue(1). The error occurs when Docker v29 attempts to pull container images with platform manifests(1).

Solution: Update to Torizon IDE Extension Version 3.3.114 (pre-release) which fixes this issue(1). Alternatively, you can downgrade your Docker installation to version 28.x as a workaround(1).

Docker Desktop Configuration Issue

If you’re using Docker Desktop, check the “Use containerd for pulling and storing images” setting(2). When this option is enabled, it can cause the “no matching manifest for linux/arm64/v8” error(2).

Solution: In Docker Desktop settings under General, uncheck “Use containerd for pulling and storing images”(2).

ARM Emulation Not Enabled

ARM emulation is not persistent and must be enabled at every boot(3). This commonly causes exec format error when building or running ARM containers on x86 platforms(3).

Solution: Enable ARM emulation by running:

$ docker run --rm -it --privileged torizon/binfmt

(3)

Docker Installation Conflicts

Ensure you have only one Docker installation - either Docker Engine in WSL2 OR Docker Desktop on Windows, not both(2). Having both installed can result in weird interactions(2).

Recommendation: Use Docker Engine in WSL2 rather than Docker Desktop, as Docker Desktop is licensed under the Docker Subscription Service Agreement while Docker Engine uses the Apache License, Version 2.0(4).

Try these solutions in order, starting with checking your Docker version and the containerd setting if using Docker Desktop.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

@ToradexAI
I installed docker version 28.5.2, however, I still have the same issue. I also updated back to IDE Extension Version 3.3.114, still with no luck. If I force the pull to use the —platform=amd64, I can pull it, but I cannot use it. When I try to run it but then doesn’t find it and tries to download it but without the --platform=amd64 and gets the same message as before, “there is no arm64 version in the manifest.”

4

Based on your follow-up, it seems the issue persists despite the version changes. The key problem appears to be that ARM emulation is not properly configured on your system. Here are the specific steps to resolve this:

Enable ARM Emulation

ARM emulation is not persistent and must be enabled at every boot (1). Run this command to enable ARM emulation:

$ docker run --rm -it --privileged torizon/binfmt

(1)

Verify ARM Emulation is Working

After enabling ARM emulation, test it with these commands:

Test arm64v8:

$ docker run --rm -it --pull always --platform linux/arm64/v8 debian arch

(1)

The return should be:

aarch64

(1)

If this test fails, the ARM emulation is not working properly, which explains why you’re getting the “no matching manifest” error.

Docker Configuration Check

Since you mentioned forcing --platform=amd64 works but then fails when the system tries to use it, verify your Docker installation:

  1. Ensure single Docker installation: Make sure you only have Docker Engine in WSL2, not both Docker Engine and Docker Desktop (2)
  2. Check Docker version: Confirm you’re actually running Docker 28.5.2:
    docker --version

TorizonCore Builder Specific Issue

The tcb-env-setup.sh script is trying to pull ARM64 containers on your x86 system. This requires ARM emulation to be properly configured. The script expects to be able to run ARM containers through emulation.

Alternative Approach

If ARM emulation continues to fail, you may need to run TorizonCore Builder on a native ARM64 system or use a different approach. However, the standard workflow is to run it on x86 with ARM emulation enabled (1).

Try the ARM emulation setup first - this is the most common cause of the issue you’re experiencing.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

@ToradexAI

This command fails with: docker: Error response from daemon: image with reference torizon/binfmt was found but its platform (linux/amd64) does not match the specified platform (linux/arm64)

However, this command works:
docker run --rm -it --pull always --platform linux/arm64/v8 debian arch
Status: Image is up to date for debian:latest
aarch64

6

Excellent! The fact that the ARM64 test command works confirms that ARM emulation is already properly configured on your system (1). The issue with the torizon/binfmt command is actually expected - it’s trying to run the wrong platform.

The Real Issue: Environment Variables

Based on similar cases in the community, this appears to be related to Docker environment variables being set incorrectly (2). When VS Code or certain environments are active, the DOCKER_HOST environment variable can get set to point to an ARM64 target device instead of your local x86 Docker daemon (2).

Troubleshooting Steps

  1. Check your environment variables:
printenv | grep DOCKER

  1. Look specifically for DOCKER_HOST:
    If DOCKER_HOST is set to something like 192.168.x.x:2375 (pointing to a Toradex device), this explains why Docker thinks it’s running on ARM64 (2).

  2. Unset the problematic variable:

unset DOCKER_HOST
  1. Try the TorizonCore Builder setup again:
source tcb-env-setup.sh

VS Code Configuration Check

If you’re using VS Code, check your .vscode/settings.json file for Docker environment settings (2). Look for entries like:

"docker.environment": {
    "DOCKER_HOST": "192.168.x.x:2375"
}

Set DOCKER_HOST to an empty string if found (2):

"docker.environment": {
    "DOCKER_HOST": ""
}

Alternative Solution

If environment variable issues persist, try restarting your computer - this has resolved similar issues for other users (2). Sometimes Docker environment caching can cause these problems to persist until a full restart.

Since your ARM emulation is working correctly (as proven by the successful debian arch test), the issue is likely environment configuration rather than Docker platform support.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

7

Hi @EvetsMostel1 we had an issue with Docker 29 that would cause a similar report. I don’t know why downgrading docker did not help in your case but as far as I know the early-access version has a proper fix. Can you try running . tcb-env-setup.sh -t early-access?

8

@drew.tx

The reason this happened goes back to another issue I had where the binfmt functionality wasn’t working. Torizon ai asked me to set a variable to make sure it stays in arm64, which of course, broke a whole bunch of other issues. So, deleting that export for Docker fixed this and other issues.
Anyway, this issue has been resolved, but I am hoping the early access version will fix my bundling issue that I have been trying to get working for almost a month. I cannot make a full custom version where I can just download it via easyloader in production and have it run. I have the modified OS all but the container bundle, but that means someone in engineering has to do the programming, which is not supposed to be that way for our production.

Steve