Still getting exceptions trying to bundle my docker image into an easy loader build

Technical Support
, , , ,
1

2026-02-16 19:58:58,134 - torizon.tcbuilder.backend.bundle - DEBUG - Using DindManager
2026-02-16 19:58:58,134 - docker.utils.config - DEBUG - Trying paths: [‘/root/.docker/config.json’, ‘/root/.dockercfg’]
2026-02-16 19:58:58,134 - docker.utils.config - DEBUG - No config file found
2026-02-16 19:58:58,134 - docker.utils.config - DEBUG - Trying paths: [‘/root/.docker/config.json’, ‘/root/.dockercfg’]
2026-02-16 19:58:58,134 - docker.utils.config - DEBUG - No config file found
2026-02-16 19:58:58,139 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /version HTTP/1.1” 200 853
2026-02-16 19:58:58,144 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /v1.52/info HTTP/1.1” 200 None
2026-02-16 19:58:58,144 - docker.utils.config - DEBUG - Trying paths: [‘/root/.docker/config.json’, ‘/root/.dockercfg’]
2026-02-16 19:58:58,144 - docker.utils.config - DEBUG - No config file found
2026-02-16 19:58:58,144 - docker.utils.config - DEBUG - Trying paths: [‘/root/.docker/config.json’, ‘/root/.dockercfg’]
2026-02-16 19:58:58,144 - docker.utils.config - DEBUG - No config file found
2026-02-16 19:58:58,149 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /version HTTP/1.1” 200 853
2026-02-16 19:58:58,151 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /v1.52/containers/json?limit=-1&all=0&size=0&trunc_cmd=0&filters=%7B%22name%22%3A+%5B%22tcb_1771271937%22%5D%7D HTTP/1.1” 200 1821
2026-02-16 19:58:58,152 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /v1.52/containers/51807cc0023278eb9afa9510039bc98b024fed3116b5fede03036a518c371688/json HTTP/1.1” 200 None
2026-02-16 19:58:58,152 - torizon.tcbuilder.backend.common - DEBUG - Current container ID (found by container name): 51807cc0023278eb9afa9510039bc98b024fed3116b5fede03036a518c371688
2026-02-16 19:58:58,153 - urllib3.connectionpool - DEBUG - http://localhost:None “GET /v1.52/containers/51807cc0023278eb9afa9510039bc98b024fed3116b5fede03036a518c371688/json HTTP/1.1” 200 None
2026-02-16 19:58:58,153 - torizon.tcbuilder.backend.bundle - INFO -
Starting DIND container
2026-02-16 19:58:58,154 - urllib3.connectionpool - DEBUG - http://localhost:None “POST /v1.52/volumes/create HTTP/1.1” 201 182
2026-02-16 19:58:58,154 - torizon.tcbuilder.backend.bundle - DEBUG - Default platform: arm64
2026-02-16 19:58:58,154 - torizon.tcbuilder.backend.bundle - DEBUG - Volume mapping for DinD: [{‘Target’: ‘/workdir/’, ‘Source’: ‘/home/steve/tcbdir3’, ‘Type’: ‘bind’, ‘ReadOnly’: False}, {‘Target’: ‘/var/lib/docker/’, ‘Source’: ‘dind-volume’, ‘Type’: ‘volume’, ‘ReadOnly’: False}]
2026-02-16 19:58:58,154 - torizon.tcbuilder.backend.bundle - DEBUG - Environment variables for DinD: {‘DOCKER_TLS_CERTDIR’: ‘/workdir/certs_20260216195858_134605.tmp’, ‘DOCKER_DEFAULT_PLATFORM’: ‘arm64’}
2026-02-16 19:58:58,154 - torizon.tcbuilder.backend.bundle - DEBUG - Running DinD container: ports={‘22376/tcp’: 22376}, network=bridge
2026-02-16 19:58:58,155 - urllib3.connectionpool - DEBUG - http://localhost:None “POST /v1.52/containers/create?name=tcb-fetch-dind HTTP/1.1” 409 241
2026-02-16 19:58:58,155 - torizon.tcbuilder.backend.bundle - INFO - Stopping DIND container
2026-02-16 19:58:59,217 - urllib3.connectionpool - DEBUG - http://localhost:None “DELETE /v1.52/volumes/dind-volume HTTP/1.1” 409 120
2026-02-16 19:58:59,217 - root - CRITICAL - An unexpected Exception occurred. Please provide the following stack trace to
the Toradex TorizonCore support team:

2026-02-16 19:58:59,219 - root - ERROR - Traceback (most recent call last):
File “/usr/local/lib/python3.9/dist-packages/docker/api/client.py”, line 275, in _raise_for_status
response.raise_for_status()
File “/usr/local/lib/python3.9/dist-packages/requests/models.py”, line 1024, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 409 Client Error: Conflict for url: http+docker://localhost/v1.52/containers/create?name=tcb-fetch-dind

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/builder/tcbuilder/backend/bundle.py”, line 659, in download_containers_by_compose_file
manager.start(network, default_platform=platform,
File “/builder/tcbuilder/backend/bundle.py”, line 296, in start
self.dind_container = self.host_client.containers.run(
File “/usr/local/lib/python3.9/dist-packages/docker/models/containers.py”, line 876, in run
container = self.create(image=image, command=command,
File “/usr/local/lib/python3.9/dist-packages/docker/models/containers.py”, line 935, in create
resp = self.client.api.create_container(**create_kwargs)
File “/usr/local/lib/python3.9/dist-packages/docker/api/container.py”, line 440, in create_container
return self.create_container_from_config(config, name, platform)
File “/usr/local/lib/python3.9/dist-packages/docker/api/container.py”, line 457, in create_container_from_config
return self._result(res, True)
File “/usr/local/lib/python3.9/dist-packages/docker/api/client.py”, line 281, in _result
self._raise_for_status(response)
File “/usr/local/lib/python3.9/dist-packages/docker/api/client.py”, line 277, in _raise_for_status
raise create_api_error_from_http_exception(e) from e
File “/usr/local/lib/python3.9/dist-packages/docker/errors.py”, line 39, in create_api_error_from_http_exception
raise cls(e, response=response, explanation=explanation) from e
docker.errors.APIError: 409 Client Error for http+docker://localhost/v1.52/containers/create?name=tcb-fetch-dind: Conflict (“Conflict. The container name “/tcb-fetch-dind” is already in use by container “ea133cd89b35dbe42081bebb3b3bfc91307a87fce89dbf6de830c88e5d75e877”. You have to remove (or rename) that container to be able to reuse that name.”)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/builder/tcbuilder/backend/bundle.py”, line 698, in download_containers_by_compose_file
raise OperationFailureError(
tcbuilder.errors.OperationFailureError: Error: container images download failed: 409 Client Error for http+docker://localhost/v1.52/containers/create?name=tcb-fetch-dind: Conflict (“Conflict. The container name “/tcb-fetch-dind” is already in use by container “ea133cd89b35dbe42081bebb3b3bfc91307a87fce89dbf6de830c88e5d75e877”. You have to remove (or rename) that container to be able to reuse that name.”)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.9/dist-packages/docker/api/client.py”, line 275, in _raise_for_status
response.raise_for_status()
File “/usr/local/lib/python3.9/dist-packages/requests/models.py”, line 1024, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 409 Client Error: Conflict for url: http+docker://localhost/v1.52/volumes/dind-volume

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/builder/torizoncore-builder”, line 232, in
mainargs.func(mainargs)
File “/builder/tcbuilder/cli/bundle.py”, line 132, in do_bundle
bundle(bundle_dir=args.bundle_directory,
File “/builder/tcbuilder/cli/bundle.py”, line 83, in bundle
bundle_be.download_containers_by_compose_file(
File “/builder/tcbuilder/backend/bundle.py”, line 702, in download_containers_by_compose_file
manager.stop()
File “/builder/tcbuilder/backend/bundle.py”, line 361, in stop
self.dind_volume.remove()
File “/usr/local/lib/python3.9/dist-packages/docker/models/volumes.py”, line 25, in remove
return self.client.api.remove_volume(self.id, force=force)
File “/usr/local/lib/python3.9/dist-packages/docker/api/volume.py”, line 163, in remove_volume
self._raise_for_status(resp)
File “/usr/local/lib/python3.9/dist-packages/docker/api/client.py”, line 277, in _raise_for_status
raise create_api_error_from_http_exception(e) from e
File “/usr/local/lib/python3.9/dist-packages/docker/errors.py”, line 39, in create_api_error_from_http_exception
raise cls(e, response=response, explanation=explanation) from e
docker.errors.APIError: 409 Client Error for http+docker://localhost/v1.52/volumes/dind-volume: Conflict ("remove dind-volume: volume is in use - [ea

I keep seeing “conflict” in the debug and I am wondering if there is a left over piece that needs to be deleted or removed after an exception occurs during the build process.
Also, I noticed a new image in docker call docker:24.0.3-dind. Is that the image it is trying to make or is that used to build the image?

Steve

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.

I’d be glad to help! Could you let me know which OS and version you are using?

To help you get the complete system information, please run the tdx-info command on your device. You can find more details about this command at https://developer.toradex.com/software/development-resources/tdx-info/.

Once you provide your hardware platform and OS version, I can give you specific guidance on resolving the Docker container naming conflict you’re experiencing with TorizonCore Builder.

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

torizoncore-builder 3.14.0

Software summary

Bootloader: U-Boot

Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 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/5c84b03643fe3e8b7be49b13c2171a7f45d0dce855097b9fafed3f75e9260a47/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15132679

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board

Toradex version: 0058 V1.1A
Serial number: 15132679
Processor arch: aarch64

4

Thanks for providing your system information! I can see you’re using Torizon OS 7.3.0-build.18 on a Verdin iMX8M Plus with TorizonCore Builder 3.14.0.

Root Cause

The error you’re encountering is a Docker container naming conflict(1). The TorizonCore Builder is trying to create a Docker-in-Docker (DIND) container named tcb-fetch-dind, but this container already exists from a previous operation that didn’t clean up properly(1).

Solution

To resolve this issue, you need to manually clean up the leftover Docker containers and volumes:

Step 1: Remove the Conflicting Container

docker rm -f tcb-fetch-dind

(1)

Step 2: Remove the Associated Volume

docker volume rm dind-volume

(1)

Step 3: Clean Up Any Other TorizonCore Builder Containers

docker ps -a | grep tcb
docker rm -f $(docker ps -aq --filter name=tcb)

About the docker:24.0.3-dind Image

The docker:24.0.3-dind image you noticed is the Docker-in-Docker container that TorizonCore Builder uses internally during the bundle command(1). This image is used by the tool to fetch and process container images from registries, not the final output of your build(1).

Prevention

To avoid this issue in the future, ensure that TorizonCore Builder operations complete successfully. If they’re interrupted, the cleanup process might not run properly, leaving these containers behind(1).

Next Steps

After cleaning up the containers and volumes, you should be able to run your TorizonCore Builder bundle command again successfully(2).

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

Yes, that did help, but I still can not get it to bundle without an exception. It is issues with certificates and secure vs insecure registries. I can login with with local host:
docker login 127.0.0.1:5002
Authenticating with existing credentials… [Username: evetsmostel]

i Info → To login with a different account, run ‘docker logout’ followed by ‘docker login’

Login Succeeded

Here is the output when I try to bundle:
torizoncore-builder bundle docker-compose.yml --login-to 127.0.0.1:5002 evetsmostel password --platform linux/arm64
Creating Docker Container bundle…
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Connecting to Docker Daemon at “tcp://172.17.0.4:22376”
Attempting to log in to registry ‘127.0.0.1:5002’ with username=evetsmostel
Stopping DIND container
Error: container images download failed: 500 Server Error for https://172.17.0.4:22376/v1.44/auth: Internal Server Error (“Get “http://127.0.0.1:5002/v2/”: dial tcp 127.0.0.1:5002: connect: connection refused”)

Steve

6

Hey @EvetsMostel1,

How are you doing with this? Have you made progress? It looks like there is IP mismatch between your private registry and what the build process has access to.

-Eric

7

@eric.tx
I believe I have tried every combination I have. I have a IP address of 10.40.100.6 and a localhost IP address of 127.0.0.1 (all listed in the insecure registry list) and a wsl IP address of 172.26.58.184. I have tried all 3 or various combinations, but it can either reach the registry or not but when it does reach it, the image is not listed. I can login into using all three addresses:5002 from the command line. This used to work in the power shell version.
I have also tried with the name of the image using one of the IP addresses:5002 but that usually comes back it can’t find it in the list. I have all three versions using tags in the docker images:
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
10.40.100.6:5002/gimbals:runme 45420117efb2 141MB 0B
172.26.58.184:5002/gimbals:runme 45420117efb2 141MB 0B
gimbals:runme 45420117efb2 141MB 0B

Do you have any idea what is happening?

Steve

8

@eric.tx
The thing is sometimes it is trying to use <ip address:5002/v2> and other times it tries to do an
https://172.17.0.4:22376/v1.44/images/create?tag=runme&fromImage=gimbals: Not Found (“pull access denied for gimbals, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied”). This is a V2 repository. Why is it trying to talk to it via v1.44 protocol. What is triggering that?

This is the command I am using:
torizoncore-builder bundle --force --dind-param=“–insecure-registry=172.26.58.184:5002” docker-compose.yml --login-to 172.26.58.184:5002 myuser mypass

Oh and my docker is only running in WSL under Ubuntu 24.04. It is not available on the Windows side. Does that matter? I used to be running it under Windows desktop using Docker Desktop. Maybe that’s why it’s not working?

Steve

9

@eric.tx
This is my docker info:
Client: Docker Engine - Community
Version: 29.2.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.31.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.0.2
Path: /usr/libexec/docker/cli-plugins/docker-compose

Server:
Containers: 5
Running: 1
Paused: 0
Stopped: 4
Images: 199
Server Version: 29.2.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
runc version: v1.3.4-0-gd6d73eb8
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.87.2-microsoft-standard-WSL2
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 31.19GiB
Name: DZYNE-8DVL094
ID: bcbafbed-ee60-4365-aefc-7f99772b98c5
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
172.26.58.184:5002
192.168.6.232:5002
192.168.6.242:5002
0.0.0.0:5002
10.40.100.5:5002
10.40.100.6:5002
10.40.200.59:5002
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables
as you can see, all of my IP addresses are listed as Insecure. I have tried removing them as insecure, but and adding the --login-to part but it doesn’t seem to make a difference.

10

@eric.tx @ToradexAI @jeremias.tx
I think there is a bug in your bundle routine. I pulled the 172.26.85.184 IP address from the insecure registry, so in theory, and then used a tag to create an entry in the image list that uses the WSL IP address (one that I can use to successfully log in from a bash command line) and then changed the docker-compose.yml file to point to that image. Should this command be run by root (i.e., Sudo) Then I used this command line to try to get it to bundle:
torizoncore-builder bundle --force docker-compose.yml --login-to 172.26.58.184:5002 myuser mypass

Starting DIND container
Connecting to Docker Daemon at “tcp://172.17.0.4:22376”
Fetching container image 172.26.58.184:5002/gimbals:arm64 in service gimbals-latest
Stopping DIND container
Error: container images download failed: 404 Client Error for https://172.17.0.4:22376/v1.44/images/create?tag=arm64&fromImage=172.26.58.184%3A5002%2Fgimbals&platform=arm64: Not Found (“manifest for 172.26.58.184:5002/gimbals:arm64 not found: manifest unknown: manifest unknown”)
This looks like a bug where it is substituting ASCII values with escape keys, which is not correct and why it cannot find the image. It either needs to be put inside double or single quotes in the code.

%3A5002%2F
@jeremias.tx ,
Does this still work for you with local private registries, running docker locally in Linux under WSL? If so, can you please let me know the exact command you are using?
Thanks,

Steve