Not able to "bundle" my container into an easy build

Technical Support
, , , ,
1

I have been trying to get my working container into an Easy Loader build for production. Right now I have to install the torizon-os, then load the saved container.tar, then make the /var/sota/storage/docker-compose/ directory and copy in my docker-compose.yml to that directory. This works, but not for production. It needs to come to them as an Easy Installer package with my container and docker-compose.yml already installed.
My torizon os is 7.3.0+build18, torizoncore-builder 3.15.0, Ubuntu 24.04 in WSL.
I am using an insecure registry, although I have added login information to this with still no joy. This is the command that used to work for me with my PC IP used:
torizoncore-builder bundle --force --dind-param=“–insecure-registry=192.168.6.6:5002” docker-compose.yml

If I can get it to connect to the registry using local IP, WSL IP or windows IP, it can’t find my image. Otherwise it can’t connect to the registry at all and exceptions out.

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 can help you troubleshoot the bundling issue with your insecure registry. The problem appears to be related to the Docker-in-Docker (DIND) container configuration for accessing your insecure registry(1).

Network Connectivity Issue

Since you’re using WSL with an insecure registry, the DIND container needs proper network access and registry configuration. The --dind-param parameter you’re using is correct, but there might be a syntax issue(1).

Correct Bundle Command Syntax

For insecure registries, use this exact format(1):

$ torizoncore-builder bundle docker-compose.yml --platform linux/arm/v7 --dind-param="--insecure-registry=192.168.6.6:5002"

Notice the double dashes (--) before insecure-registry in the parameter(1).

Alternative Approaches

1. Using Login Credentials

If your registry requires authentication, combine the insecure registry parameter with login credentials(1):

$ torizoncore-builder bundle docker-compose.yml --platform linux/arm/v7 --dind-param="--insecure-registry=192.168.6.6:5002" --login-to 192.168.6.6:5002 username password

2. Network Troubleshooting

For WSL environments, try using the WSL host IP or Windows host IP that the DIND container can reach. You can find your WSL IP with:

ip addr show eth0

Complete Build Process

Once bundling works, integrate it into your build configuration(2)(3):

tcbuild.yaml

input:
  easy-installer:
    local: images/torizon-core-docker-your-module-Tezi_7.3.0+build.18.tar

output:
  easy-installer:
    local: torizon-core-docker-your-module-CUSTOM-WITH-CONTAINERS
    bundle:
      compose-file: docker-compose.yml

Then run:

$ torizoncore-builder build

This approach downloads container images during build time and creates a production-ready Easy Installer image(2)(3).

Environment Variable Forwarding

You can also pass environment variables to the DIND container using --dind-env(1):

$ torizoncore-builder bundle docker-compose.yml --dind-env REGISTRY_URL='192.168.6.6:5002'

Try the corrected syntax first, and if issues persist, please share your docker-compose.yml content and any specific error messages you’re seeing.

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

When using this, the process overwrites whatever the given “tag” to “arm64”, which is not the correct tag. Even if I create a new image with that tag instead of the one I have, it still won’t find it.

Trying:
$ torizoncore-builder bundle docker-compose.yml --dind-env REGISTRY_URL=‘172.26.58.184:5002’

Yields:
Error: container images download failed: 500 Server Error for https://172.17.0.5:22376/v1.44/images/create?tag=runme&fromImage=172.26.58.184%3A5002%2Fgimbals: Internal Server Error (“Get “https://172.26.58.184:5002/v2/”: http: server gave HTTP response to HTTPS client”)
from docker info:
Insecure Registries:
10.40.200.59:5002
172.26.58.184:5002
0.0.0.0:5000
10.40.100.5:5002
10.40.100.6:5002
172.17.0.3:5002
192.168.6.232:5002
192.168.6.242:5002
::1/128
127.0.0.0/8

Even adding --dind-param=“–insecure-registry=172.26.58.184:5002”, the bundle command STILL tries to connect using a secure connection. This is a bug as I have been saying. Please fix this! (The – in the above quote is 2 - but shows as 1 for some reason.)

4

I see the issues now. The error shows the DIND container is trying to use HTTPS to connect to your insecure registry, and there’s also a platform/tag mismatch problem.

Network Configuration Issue

The error message shows the DIND container is trying to connect via HTTPS to your HTTP registry(1). You need to properly configure the insecure registry parameter for the DIND container.

Correct Command for Insecure Registry

Use this exact syntax to configure the DIND container for your insecure registry(2):

$ torizoncore-builder bundle --dind-param="--insecure-registry=192.168.6.6:5002" docker-compose.yml --bundle-directory bundle

Platform Architecture Issue

For the platform/tag overwrite issue, you need to specify the correct platform that matches your target hardware(2). Since you mentioned the system is changing your tag to “arm64”, your target is likely 64-bit ARM:

$ torizoncore-builder bundle --platform=linux/arm64 --dind-param="--insecure-registry=192.168.6.6:5002" docker-compose.yml --bundle-directory bundle

For 32-bit ARM devices (i.MX6/i.MX7 based SoMs), use(2):

$ torizoncore-builder bundle --platform=linux/arm/v7 --dind-param="--insecure-registry=192.168.6.6:5002" docker-compose.yml --bundle-directory bundle

Multiple Registry Configuration

Since your Docker info shows multiple insecure registries, you can specify multiple --dind-param entries(1):

$ torizoncore-builder bundle --dind-param="--insecure-registry=192.168.6.6:5002" --dind-param="--insecure-registry=172.26.58.184:5002" docker-compose.yml --bundle-directory bundle

Alternative: Use Build Configuration

Instead of separate bundle/combine steps, use the build command with a configuration file(2):

tcbuild.yaml

input:
  easy-installer:
    local: images/torizon-core-docker-your-module-Tezi_7.3.0+build.18.tar

output:
  easy-installer:
    local: torizon-core-docker-your-module-CUSTOM
    bundle:
      compose-file: docker-compose.yml
      platform: linux/arm64
      dind-params:
        - "--insecure-registry=192.168.6.6:5002"
        - "--insecure-registry=172.26.58.184:5002"

Then run:

$ torizoncore-builder build

This approach handles the platform specification and registry configuration in one step(2).

Could you also share your docker-compose.yml content? This will help verify the image references are correct for your registry setup.

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
Sorry, I am in a different location now and the IP addresses are different. The 192.168.6.6:5002 is no longer valid.
The eth0 address associated with the WSL registry is 172.26.58.184:5002. I have tried using the full build version as well, and it does the same thing, uses secure connection attempts (https) instead of http. Additionally, it is going to 172.17.0.5, even putting in the:
dind-env:
- “REGISTRY_URL=172.26.58.184:5002”
in the tcbuild.yaml file.
And again, all connections are trying secure (https).

6

I understand the DIND container is still trying to use HTTPS despite your insecure registry configuration. The issue is that the dind-env parameter you’re using doesn’t configure the Docker daemon’s insecure registry settings(1).

Correct Configuration for Insecure Registry

The proper way to configure insecure registries in the tcbuild.yaml is using the dind-params array, not dind-env(1):

tcbuild.yaml

input:
  easy-installer:
    local: images/torizon-core-docker-your-module-Tezi_7.3.0+build.18.tar

output:
  easy-installer:
    local: torizon-core-docker-your-module-CUSTOM
    bundle:
      compose-file: docker-compose.yml
      platform: linux/arm64
      dind-params:
        - "--insecure-registry=172.26.58.184:5002"

(1)

Alternative Command Line Approach

If you prefer the standalone bundle command, use this exact syntax(2):

$ torizoncore-builder bundle --dind-param="--insecure-registry=172.26.58.184:5002" docker-compose.yml --bundle-directory bundle

Network Address Issue

The 172.17.0.5 address you’re seeing is the internal Docker-in-Docker container network. This suggests the DIND container can’t properly resolve or reach your WSL registry address.

For WSL environments, you might need to use the Windows host IP address that’s accessible from within Docker containers, or configure Docker Desktop to allow access to WSL network ranges.

Debug Steps

  1. Verify your docker-compose.yml references the correct registry:

    services:
  your-service:
    image: 172.26.58.184:5002/your-image:tag

  2. Test registry connectivity from within a regular Docker container:

    docker run --rm --add-host host.docker.internal:host-gateway alpine/curl curl -v http://172.26.58.184:5002/v2/

The key issue is that dind-env sets environment variables but doesn’t configure the Docker daemon’s registry settings. You must use dind-params with the --insecure-registry flag to properly configure the Docker daemon inside the DIND container(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.

7

@ToradexAI @matheus.tx

Results:
Unable to find image ‘alpine/curl:latest’ locally
latest: Pulling from alpine/curl
6a0ac1617861: Pull complete
d70add8dfd13: Pull complete
f3f198be84dd: Pull complete
Digest: sha256:16ed43d4038dd824e3b935d16d6763cac68aca3e7c5b4248f38409a85a13547c
Status: Downloaded newer image for alpine/curl:latest
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 0* Trying 172.26.58.184:5002…

  • Established connection to 172.26.58.184 (172.26.58.184 port 5002) from 172.17.0.4 port 53082
  • using HTTP/1.x

GET /v2/ HTTP/1.1
Host: 172.26.58.184:5002
User-Agent: curl/8.19.0
Accept: /

  • Request completely sent off
    < HTTP/1.1 200 OK
    < Content-Length: 2
    < Content-Type: application/json; charset=utf-8
    < Docker-Distribution-Api-Version: registry/2.0
    < X-Content-Type-Options: nosniff
    < Date: Tue, 19 May 2026 16:24:27 GMT
    <
    { [2 bytes data]
    100 2 100 2 0 0 285 0 0
    {}* Connection #0 to host 172.26.58.184:5002 left intact

Which shows that you CAN connect using an insecure connection. I used both the dind-env and the dind-parameter settings in the tcbuild.yaml. I tried without it first and got the same result. The bundle command is simply incapable of doing an insecure connection.

8

This is what worked for me on my own Windows/WSL2 setup.

First I created an insecure local registry:

$ docker run -d -p 5000:5000 --restart always --name registry registry:2

I then pushed an container image into this registry and removed the local copies of the image:

$ docker pull --platform linux/arm64 hello-world
$ docker tag hello-world:latest localhost:5000/hello-world:latest
$ docker image remove localhost:5000/hello-world:latest
$ docker image remove hello-world:latest

I then setup TorizonCore Builder like so. The --network=host is so that the networking is simpler in the end. Since networking can be strange on WSL2.

$ source ../tcb-env-setup/tcb-env-setup.sh -- --network=host

I created a docker-compose.yml file that looks like this:

version: '2.4'

services:
  hello-world:
   image: localhost:5000/hello-world:latest

I then ran the bundle command and it worked:

$ torizoncore-builder bundle --force --dind-param="--insecure-registry=localhost:5000" docker-compose.yml
Creating Docker Container bundle...
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Using Docker host "tcp://127.0.0.1:22376"
Connecting to Docker Daemon at "tcp://127.0.0.1:22376"
Fetching container image localhost:5000/hello-world:latest in service hello-world
  Pulling from hello-world
  58dee6a49ef1: Pull complete
  Digest: sha256:f805bf1f635317fe194d3fa74b2b05d5b9f2d8513ec411a88128503f341e95be
  Status: Downloaded newer image for localhost:5000/hello-world:latest
Saving Docker Compose file
Exporting storage
Storing container bundle into "bundle"
Stopping DIND container
Successfully created Docker Container bundle in "bundle"!

This clearly shows that the bundle command is capable of doing insecure connections. Any further issues are probably related to your specific network setup. In which case it’s difficult for us to say what the issue is as we don’t have control or knowledge on how your network is configured.

Best Regards,
Jeremias

9

@jeremias.tx
Thank you for doing this. I sincerely appreciate the simple steps. However, my results are not the same as yours.
My script said it was out of date. So I got a new one using the command they gave:
wget -o tcb-env-setup.sh https://raw.githubusercontent.com/toradex/tcb-env-setup/master/tcb-env-setup.sh
However, if it finds the same file locally, it adds a “.number” to the end. It does not replace replace the file, unlike the cp command. So when I run the new one using your command, minus the ../tcb-env-setup/, since my script is just local.
source ./tcb-env-setup.sh.1 – --network=host
my result:
-bash: [[: : syntax error: operand expected (error token is “”)

You may have an outdated version installed. Would you like to check for updates online? [y/n]
y
I received version 3.15.0.

I have a couple of questions…

What does the extra – do? I understand the basic premise of the --network=host.
I am using 5002 port, but that shouldn’t matter. I was told by the AI in another post that I could not use localhost because it was inaccessible under WSL. Also the confusing part was that is ALWAYS was trying https connections and complaining that it got an http response. I never saw it do an http connection even in the --verbose and debug output. And it was constantly using v1.44 protocol.
Also, I have tried this under my home network as well as my company network (which I will admit was a concern for me, but the builder behaved the same under both environments). Also, when the network or my PC blocks an network access, I get a message. This never occurred. I removed and added a new registry to make sure it was a v2 type.
Why did you remove all the other images? My original image is just name:tag, which works fine on the devices I run installing the image manually.
If the problem is some issue on my computer, I have my own laptop set up the same way so I can use that. I have tried localhost, specific IP’s related to my computer, i.e. WSL ip’s and Windows IP’s. It either won’t connect at all, or if it does connect, it can’t find the image. I get the same result on my personal laptop that has none of the network security things my company laptop has. So I am concluding that it is not a network security issue.
So, running the setup the you have here is my registry:
registry 2 26b2eb03618e 2 years ago 25.4MB
running:
46b40a84a50 registry:2 “/entrypoint.sh /etc…” 5 months ago Up 45 hours 0.0.0.0:5002->5000/tcp, [::]:5002->5000/tcp registry

My image:
localhost:5002/myname mytag 45420117efb2 3 months ago 141MB

My results:
torizoncore-builder bundle --force --dind-param="–insecure-registry=localhost:
5002" docker-compose.yml
Creating Docker Container bundle…
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Using Docker host “tcp://127.0.0.1:22376”
Connecting to Docker Daemon at “tcp://127.0.0.1:22376”
Fetching container image localhost:5002/myname:mytag in service myname-latest
Stopping DIND container
Error: container images download failed: 404 Client Error for https://127.0.0.1:22376/v1.44/images/create?tag=mytag&fromImage=localhost%3A5002%2Fmyname: Not Found (“manifest for localhost:5002/myname:mytag not found: manifest unknown: manifest unknown”)

I do have multiple versions in the registry with different names/tags to try to debug this.
10.40.100.6:5002/myname arm64 45420117efb2 3 months ago 141MB
10.40.100.6:5002/myname mytag 45420117efb2 3 months ago 141MB
172.26.58.184:5002/myname arm64 45420117efb2 3 months ago 141MB
172.26.58.184:5002/myname mytag 45420117efb2 3 months ago 141MB
myname mytag 45420117efb2 3 months ago 141MB
host.docker.internal:5000/myname mytag 45420117efb2 3 months ago 141MB
localhost:5000/myname mytag 45420117efb2 3 months ago 141MB
localhost:5002/myname mytag 45420117efb2 45420117efb2 3 months ago 141MB

So I ask, is the reason it can’t find my image is that there are 2 many and should only have one?

Steve

10

@jeremias.tx
Just as a check, I remove all the extra tagged and even original, just like you did above, only I had a lot more for all the variations I was trying.

torizoncore-builder bundle --force --dind-param=“–insecure-registry=localhost:5002” docker-compose.yml
Creating Docker Container bundle…
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Using Docker host “tcp://127.0.0.1:22376”
Connecting to Docker Daemon at “tcp://127.0.0.1:22376”
Fetching container image localhost:5002/myname:mytag in service myname-latest
Stopping DIND container
Error: container images download failed: 404 Client Error for https://127.0.0.1:22376/v1.44/images/create?tag=mytag&fromImage=localhost%3A5002%2Fmyname: Not Found (“manifest for localhost:5002/myname:mytag not found: manifest unknown: manifest unknown”)

11

However, my results are not the same as yours.

I’m not sure what else I could share. These steps work for me, my colleagues, and many other customers.

What does the extra – do?

This is clearly documented in the README for the tcb-env-setup script: tcb-env-setup/README.md at master · toradex/tcb-env-setup · GitHub

Why did you remove all the other images?

I removed the copy of the container images that existed on my machine’s local cache. That way the only copy that exists would be in the registry container that I ran and pushed to. This was not necessary, but this way there would be no ambiguity or claims that the bundle command got the container image from anywhere but the registry container. It was simply extra proof to show you that the bundle command could do what you claimed it could not.

I do have multiple versions in the registry with different names/tags to try to debug this.

How are you pushing images with different IP addresses to the same registry? Are you even able run docker pull on your WSL2 CLI targeting the images that you have stored in the registry container?

There’s really not much else we can provide or suggest here. We’ve tested this thoroughly on our side, and we’ve provided a step-by-step method that works for everyone else we’ve shown it to. It’s difficult for us to diagnose an issue that we can’t reproduce and only happens on your setup.

Best Regards,
Jeremias

12

@jeremias.tx
Hi Jeremias,
The original, is just a name and a tag which the product has no problem finding in the easyloader build. All the other versions were created using the tag command in docker, using different IP addresses, and tags, since when you put the --platform in the command line, it overwrites the given tag with “arm64” as the tag it looks for.
I don’t have any issues running a release build, other than I have to create a “debug” version without the symbols before I create the release build because for whatever reason, it is copying that exe into the container when it builds it, not the one it builds in the build container. If my debug version isn’t on my disk, then there is no exe after the release build. Works correctly with Hello World setup, but not in my actual product.
I have even tried a fresh redo of my build directory with the same results, and have compared the differences using Beyond Compare, with no luck. There are differences, the docker-compose.yml is different and there are subtle differences in my Makefile as well.
I will try again with my personal laptop to see if it is some security issue that I am dealing with.
Thank you for your efforts.

Steve

13

All the other versions were created using the tag command in docker, using different IP addresses, and tags, since when you put the --platform in the command line, it overwrites the given tag with “arm64” as the tag it looks for.

This statement makes no sense to me at all. The --platform option in the docker CLI doesn’t override the tag in the docker image name. You can see clearly from my step-by-step that I kept the latest tag throughout the entire process.

These strange statements of yours are really making me think there is some misunderstanding, or strange behavior happening on your end.

Also I’m not sure why you’re bringing up building and Makefiles now. This is a separate topic to the bundle command. Please don’t bring up new topics/information unless you can prove they’re related to the issue at hand. Otherwise you just make the entire thread confusing with irrelevant information.

Also you didn’t answer my question from my previous reply:

How are you pushing images with different IP addresses to the same registry? Are you even able run docker pull on your WSL2 CLI targeting the images that you have stored in the registry container?

What I’m saying here is take a container image ANY container image, doesn’t even need to be your application. Use a hello-world container image like I did for testing sake. Re-tag this container image and push it to your registry container. Then do what I did and remove all copies of the container image from your local cache. That way the only existing copy of this container image is in the registry container.

Now, if you try to docker pull the container image that only exists in that registry. Does that work on your setup?

Best Regards,
Jeremias

14

@jeremias.tx
Hi Jeremias,
So, in your second statement, this is what you have:

in this situation, it appears you are downloading hello-world:latest, then tagging it with localhost:5000/hello-world:latest, then the 3rd statement you are removing the one you just tagged and then removing the original. That seems that you wouldn’t have any images. Am I missing something?
As far as the different IP addresses, they are all my computer, starting from the original image of myname:mytag to any-ip-address:5002/myname:mytag. You can tag any image to something else with the tag command. In my case, my external IP address, my localhost IP address, my WSL ipaddress, etc. All/most suggested by AI. I am not pushing or pulling anything new. I did “load” the original of myname:mytag from tar file though, it wasn’t pulled or pushed. Does that make a difference? This is the way I have done it in the past.

I am trying to recreate everything on my home computer using your steps to see if there is some soft of blockage that is occurring on my work computer.
I will let you know the result.

Steve

15

@jeremias.tx
Hi Jeremias,
I removed the original hello-world:latest after tagging the localhost:5000/hello-world:latest, so that is the only image I have.
I am providing internet from my phone, so there is no other network involved. My laptop doesn’t have any bitlocker or other network security. I am running torizoncore-builder 3.15.0. This is the result:
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Using Docker host “tcp://127.0.0.1:22376”
Connecting to Docker Daemon at “tcp://127.0.0.1:22376”
Fetching container image localhost:5000/hello-world:latest in service hello-world
Stopping DIND container
Error: container images download failed: 404 Client Error for https://127.0.0.1:22376/v1.44/images/create?tag=latest&fromImage=localhost%3A5000%2Fhello-world: Not Found (“manifest for localhost:5000/hello-world:latest not found: manifest unknown: manifest unknown”)

When I run it with --verbose, here is the issue I see in the verbose output:
DinD> time=“2026-05-26T20:05:43.340024811Z” level=warning msg=“Error getting v2 registry: Get "https://localhost:5000/v2/\”: http: server gave HTTP response to HTTPS client"
DinD> time=“2026-05-26T20:05:43.340062871Z” level=info msg=“Attempting next endpoint for pull after error: Get "https://localhost:5000/v2/\”: http: server gave HTTP response to HTTPS client"
DinD> time=“2026-05-26T20:05:43.344723138Z” level=error msg=“Not continuing with pull after error: manifest unknown: manifest unknown”

Do you see this when you run verbose? In both cases it is trying to connect via https, not http.

Steve

P.S. The tag “override” only happens if you put --platform=arm64 in the commandline (as recommended by the AI). Unless it is OK with “latest”, which I don’t use.

16

Are you ever actually using docker push to push the re-tagged image to the registry that is running via the docker run -d -p 5000:5000 --restart always --name registry registry:2 command?

I didn’t explicitly type this command out since it’s heavily implied, and I did make several mentions of “pushing” the container image into the registry. In case you need the full command it would be:

$ docker push localhost:5000/hello-world:latest

Of course adjust for your port. This command places the container image into the registry. The bundle command works by fetching container images from a registry. The list of container images you see by running docker images, this is not what is in the registry. That’s what’s on your local computer cache, which again is not a registry. Which is why we need to run docker run -d -p 5000:5000 --restart always --name registry registry:2 to create a registry.

This would be easier if you used a standard hosted registry like Dockerhub, but I assume you have a reason not to do so.

So again have you ever in this entire process used docker push to actually push the container image to the registry?

This is why I’ve asked questions in this thread like:

Now, if you try to docker pull the container image that only exists in that registry. Does that work on your setup?

Which you never clearly answered.

As for the error you see, I only see this error if I neglect to push my container image into the registry. Which means there’s nothing in the registry. So I’m going to assume you’ve never actually used the registry correctly throughout this.

Best Regards,
Jeremias

17

@jeremias.tx
Hi Jeremias,
I used to use docker desktop. The “load” functionality is what I have always used and never had to “push” an image to use it. Maybe docker desktop spoiled me? I have “loaded” the image onto the device’s docker using docker load -i myimage.tar. Then using a docker-compose.yml with no localhost:5000/ in front, as the myname:mytag, it runs like a champ. No pushing.
You are correct about me not being able to use public registries. Everything is locked away here.
I do apologize. I did create the registry exactly as you did in my test but did not do a “push”. I will try this and hopefully get past this issue. I had one already, but I deleted it and created a new one.

Thank you for your patience.
Steve

18

@jeremias.tx
Hi Jeremias,
I was able to push to the registry and I did try to pull it (docker pull localhost:5000/myname:mytag) and that was successful. However, if I try to bundle it:
torizoncore-builder --verbose bundle --force --dind-param=“–insecure-registry=localhost:5000” docker-compose.yml
on my home computer and got a “connection refused”

Detail info:
DinD> time=“2026-05-27T14:52:06.219620711Z” level=info msg=“Daemon has completed initialization”
DinD> time=“2026-05-27T14:52:06.269034971Z” level=info msg=“API listen on /var/run/docker.sock”
DinD> time=“2026-05-27T14:52:06.269106129Z” level=info msg=“API listen on [::]:22376”
DinD> time=“2026-05-27T14:52:06.269130841Z” level=info msg=“API listen on [::]:2376”
DinD> time=“2026-05-27T14:52:06.306267952Z” level=warning msg=“Error getting v2 registry: Get "https://localhost:5000/v2/\”: dial tcp [::1]:5000: connect: connection refused"

It still looks like it is using an secure connection here to me.
I did try the curl command:
curl -X GET https://localhost:5000/v2/_catalog
curl -X GET http://localhost:5000/v2/_catalog
https was refused, but the http worked fine and returned:
{“repositories”:[“myname”]}
as did:
curl -X GET http://localhost:5000/v2/gimbals/tags/list
{“name”:“myname”,“tags”:[“mytag”]}

Steve

torizoncore-builder 3.15.0

19

The only way I can reproduce the error you got is if I did everything on port 5000, but then in my docker-compose.yml that I used for the bundle command I mistakenly specify a different port like so:

version: '2.4'

services:
  hello-world:
   image: localhost:5001/hello-world:latest

But, my registry and image itself were using port 5000. If I do this kind of mistake then I can get the same error as you.

Maybe you did something similar and weren’t consistent with the port number throughout your process? Otherwise I’m out of ideas why your system would be behaving differently in this regard.

Best Regards,
Jeremias

20

@jeremias.tx
I had deleted my registry and then created it exactly the same way you did, just to keep everything the same. And yes, I had already changed my compose file to have localhost:5000/myname:mytag when I ran it before.
I checked everything and ran it again with the same result.
Can you run yours with debug and see if the first time it tries to connect to the registry if it is using a secure connection? Because with mine it is, then it tries with the http connection but it says that is refused as well, which seems very odd.
I turned off my windows firewall completely just to check because I read that the DIND has problems getting into localhost.
I can run the curl -X GET http://localhost:5000/v2/gimbals/tags/list, and that works fine. I would think that is a close test?
Otherwise I am at a complete loss. I even used the simple docker-compose.yml as yours substituting my name:tag. But i keep getting the same result. I may have to use tracenet to see what is really going on. Weird.
I am on Windows 11, I don’t know if that makes a difference…
Steve