Binfmt for qemu-aarch64 is not enabled!

I think I am getting a mismatch between the torizon extension and VSC. When I start it up, I get this message after it loads the extension says it has to restart due to a change in a setting. However, if I restart VSC, it just reloads the extension and the same message comes up.
If I ignore it and try to build a debug version, I get the message:
binfmt for qemu-aarch64 is not enabled!

Here is the full log of the build:
:warning: VALIDATING ENVIRONMENT

OS: Linux
OS Version: 6.6.87.2-microsoft-standard-WSL2
OS Arch: x86_64
Under WSL: Ubuntu-24.04
VS Code:
1.111.0
ce099c1ed25d9eb3076c11e4a280f3eb52b4fbeb
x64

TOR Extension: toradex.apollox-vscode@3.3.0
:warning: binfmt for qemu-aarch64 is not enabled, trying to enable it …
Unable to find image ‘torizon/binfmt:latest’ locally
latest: Pulling from torizon/binfmt
Digest: sha256:4341763f8efc917a9ca02dfb9f6f0fdf53116a6358dcab0b363a03c6a0f69788
Status: Image is up to date for torizon/binfmt:latest
WARNING: image with reference torizon/binfmt:latest was found but its platform (linux/amd64) does not match the specified platform (linux/arm64)
docker: Error response from daemon: image with reference torizon/binfmt:latest was found but its platform (linux/amd64) does not match the specified platform (linux/arm64)

Run ‘docker run --help’ for more information

:cross_mark: binfmt for qemu-aarch64 is not enabled!

Error cause: Not configured

  • The terminal process “xonsh ‘.conf/validate-deps-running.xsh’” terminated with exit code: 1.
  • Terminal will be reused by tasks, press any key to close it.

What is going on?

Steve

Hi, I’m the Toradex AI Assistant.

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


I can help you resolve this ARM emulation issue. The error indicates that the binfmt system for ARM emulation is not properly enabled, which is necessary for building ARM containers on your x86 development machine.

Solution: Enable ARM Emulation

The primary issue is that ARM emulation needs to be enabled each time you boot your system. Based on the documentation, you need to run this command to enable ARM emulation (1):

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

(1)

Important Notes:

  1. Not Persistent: ARM emulation is NOT persistent and must be enabled at every boot (1)
  2. Privileged Container: This operation will run a privileged container, which should be a safe operation (1)
  3. Platform Compatibility: Use the same command for both Windows (Docker Desktop with WSL 2) and Linux distributions (1)

Verification Steps

After running the command above, test whether the interpreters have been successfully installed:

Test ARM64v8 Support:

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

(1)

The return should be:

aarch64

(1)

Test ARM32v7 Support:

$ docker run --rm -it --pull always --platform linux/arm/v7 debian arch

(1)

The return should be:

armv7l

(1)

Common Issue Resolution

The error you’re encountering is a common issue described in the documentation (1). When ARM emulation is not enabled, you’ll see exec format error when building or running ARM containers on an x86 platform.

Additional Setup Verification

Since you’re using WSL 2 with the Torizon IDE Extension, ensure your environment is properly configured:

  1. Docker Engine: Make sure Docker Engine is properly installed and configured to run without root privileges (2)
  2. Extension Dependencies: The extension should automatically check and install necessary dependencies during first activation (2)

After enabling ARM emulation with the command above, try building your debug version again. The extension should now be able to properly build ARM containers for your target device.

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.

I get:
exe /usr/bin/arch exec format error.

The “exec format error” you’re seeing confirms that ARM emulation is not properly enabled (1). This is exactly the error described in the documentation as a common issue when ARM emulation hasn’t been set up correctly (1).

Solution Steps

Step 1: Enable ARM Emulation

Run this command to enable ARM emulation:

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

(1)

Step 2: Verify Installation

After running the binfmt command, test the ARM64v8 emulation again:

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

(1)

This should return:

aarch64

(1)

Additional Troubleshooting

If you’re still getting the exec format error after running the binfmt command, there might be an issue with your Docker setup. Based on community reports, there’s a known issue with Docker Desktop’s containerd setting (2).

Check Docker Desktop Settings (if using Docker Desktop):

In Docker Desktop settings under “General”, ensure that “Use containerd for pulling and storing images” is unchecked (2). This setting can cause the “no matching manifest for linux/arm64/v8” type errors (2).

Important Notes

  • ARM emulation is not persistent and must be enabled after every system reboot (1)
  • The binfmt command runs a privileged container, which is a safe operation for enabling emulation (1)
  • This applies to both Windows (WSL 2) and Linux development environments (1)

Once ARM emulation is properly enabled, you should be able to build and debug your Torizon applications successfully.

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.

@ToradexAI
I am not using docker desktop. I’ve installed it in WSL Ubuntu Linux 24.04, which WAS working just fine. But not today.
This command “docker run --rm -it --privileged torizon/binfmt” continues to fail 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)

@ToradexAI
This problem happens with the “Hello World” app as well.

The error you’re experiencing indicates that Docker is incorrectly trying to pull the ARM64 version of the torizon/binfmt image instead of the AMD64 version. This is similar to the issue documented in the community forums (1).

Root Cause Analysis

Based on the community reports, this problem occurs when Docker thinks it’s running on an ARM64 system when it’s actually running on x86_64 (1). The issue is that the DOCKER_HOST environment variable might be set incorrectly, causing Docker to connect to a remote ARM64 system instead of your local x86_64 WSL environment (1).

Solution Steps

Step 1: Check Docker Environment Variables

In your WSL terminal, run:

printenv | grep DOCKER

Step 2: Check Docker Info

Run this command to see what Docker thinks your system architecture is:

docker info

Look for the “Architecture” field in the output (1). If it shows aarch64 instead of x86_64, that’s the problem.

Step 3: Unset DOCKER_HOST (if set)

If you find that DOCKER_HOST is set, unset it:

unset DOCKER_HOST

Step 4: Restart VS Code

Sometimes the environment variables get cached. As mentioned in the community forum, “have you tried turning it off and on?” often works (1). Close VS Code completely and restart it.

Step 5: Verify Docker is Running Locally

After unsetting any problematic environment variables, verify Docker is connecting to your local WSL instance:

docker info

The output should show:

  • Architecture: x86_64
  • Operating System: Should reference your WSL Ubuntu installation

Step 6: Re-enable ARM Emulation

Once Docker is connecting to the correct local instance, run the ARM emulation command:

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

(2)

VS Code Settings Check

Also check your VS Code settings in .vscode/settings.json and ensure DOCKER_HOST is not set or is empty:

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

(1)

This issue is commonly caused by VS Code extension settings that redirect Docker commands to the target device instead of the host development machine (1).

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.

Here is the real answer. I am not sure why this is happening now, but the issue is that wsl has “always” had the bin-fmt disabled, accoding to the web since they use that method to run windows exe in linux, like explorer.exe and notepad.exe.
So for 24.04 Ubuntu, it is not supposed to be an issue, so you can enable it by doing:
sudo vi /usr/lib/systemd/system/systemd-binfmt.service.d/wsl.conf
and commenting out the line:
[Unit]
ConditionVirtualization=!wsl

By putting a # in front.
Then you must just start the service:
sudo systemctl start systemd-binfmt.service

and it should have run but exited, which mine did.
You can check by running:
systemctl status systemd-binfmt.service

Steve