This is also happening to me on ROS 7.17.2 (error 400)

I even tried to download the image and import it myself using the instructions by the wiki and it’s failing to extract. (Stuck extracting forever)

Really wish we would get detailed logs on what’s happening. It’s hard to troubleshoot.

Also the registry I’m using is https://registry-1.docker.io/

Check with this, try to execute from Terminal:

Code: Select all

:put ([/tool/fetch url="https://registry.hub.docker.com/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}" output=user as-value]->"status")

You should get: finished
Where url placeholders can be get from remote image format {namespace}/{repository}:{tag}, if {tag} is not specified latest is used.
For example for Pi-hole container namespace and repository are named pihole (pihole/pihole) and fetch url will be then: https://registry.hub.docker.com/v2/name ... ags/latest

unable to import, container 2eb2e36f-23ef-4ea5-b780-70fb6f0c25ac

"error code getting container config: 400"
"error parsing container config"
"was unable to import, container X"

It seems new ROS version issue if for same containers fetch command is not failing, maybe it is building docker hub API url wrong. Container debug logs did not help? Maybe there is a debug log from which url is trying to fetch when building container.

Check with this, try to execute from Terminal:

Code: Select all

:put ([/tool/fetch url="https://registry.hub.docker.com/v2/namespaces/{namespace}/repositories/{repository}/tags/{tag}" output=user as-value]->"status")

You should get: finished
Where url placeholders can be get from remote image format {namespace}/{repository}:{tag}, if {tag} is not specified latest is used.
For example for Pi-hole container namespace and repository are named pihole (pihole/pihole) and fetch url will be then: https://registry.hub.docker.com/v2/name ... ags/latest

I ran the command with a few repos and those finish. My problem seems to be no matter which container I try, Technitium/dns-server, PiHole (from wiki example) and even a docker hello-world for the purposes of no mounts, env being needed. In the logs I always get the same error was

unable to import, container 2eb2e36f-23ef-4ea5-b780-70fb6f0c25ac

This also was using the old registry that I mentioned before, and also the new one https://registry.hub.docker.com that was suggested. After trying a few different times I will then get

"error code getting container config: 400"
"error parsing container config"
"was unable to import, container X"

Not sure if this has to do with updating ROS as I had no problem running a container before on v7.16. (I just saved my old /container/add line from when I first created the container and tried to run it again)

I ran the command with a few repos and those finish. My problem seems to be no matter which container I try, Technitium/dns-server, PiHole (from wiki example) and even a docker hello-world for the purposes of no mounts, env being needed. In the logs I always get the same error was




This also was using the old registry that I mentioned before, and also the new one https://registry.hub.docker.com that was suggested. After trying a few different times I will then get



Not sure if this has to do with updating ROS as I had no problem running a container before on v7.16. (I just saved my old /container/add line from when I first created the container and tried to run it again)

you using a tag when pulling your container? for example technitium/dns-server:latest

Update - Upgrading to ROS v7.18 beta 5 fixed my problem ran the same command previously and now my container is running. I am no longer encountering the unable to import container. Looks like it's just a bug with ROS v7.17

1. Pull image with command in format:
   Code: Select all

   # podman pull --arch <architecture> docker.io/<namespace>/<repository>[:tag]
   

   depending on ROS architecture where container needs to be added, <architecture> can be: arm64 for ARM64, arm/v6 or arm/v7 for ARM (32bit), amd64 for x86_64
   example for Pihole (pihole/pihole) for ARM (32bit) ROS:
   
   Code: Select all

   # podman pull --arch arm/v7 docker.io/pihole/pihole

2. Save image with command in format:
   Code: Select all

   # podman save -o <image_name>.tar docker.io/<namespace>/<repository>[:tag]
   

   example for pulled image from 1st step:
   
   Code: Select all

   # podman save -o pihole.tar docker.io/pihole/pihole
   

Just to follow up regarding Docker image save bug

you using a tag when pulling your container? for example technitium/dns-server:latest

Yes I was, I tried technitium/dns-server:latest and even technitium/dns-server:latest@sha256:6f25ba81ad8be0019cb3d439d8452435614b40d2fe8252fced684eef277e2257 (I thought this might help as I seen in v7.18 there was a change about how containers choose the correct arch, didn't know if v7.17 was grabbing the wrong arch which caused it to fail importing)

/container stop [find repo ~"pi-hole"]

/container stop [find tag ~"pi-hole"]

Also a possible bug, if you don't have a registry set (blank) after upgrading to 7.18 beta 5, it doesn't look like editing the registry via Winbox in container config will stick. I was able to confirm this by "/container/config print" as it still showed "assumed-registry-url: https://lscr.io" instead of the specific registry I put. Checking the container config (winbox, gui) after rebooting also showed that container config registry was empty.

After changing the registry via the terminal with the "/container/config set registry-url=" it look like it took and the registry was updated when running the "/container/config print" again. I was also able to confirm editing the registry via winbox gui was now working after at least setting it once via terminal.

Strange.

Update - Reported this issue to Mikrotik support@mikrotik.com. They were able to reproduce it and said it would be fixed on a later update.

Also a possible bug, if you don't have a registry set (blank) after upgrading to 7.18 beta 5, it doesn't look like editing the registry via Winbox in container config will stick. I was able to confirm this by "/container/config print" as it still showed "assumed-registry-url: https://lscr.io" instead of the specific registry I put. Checking the container config (winbox, gui) after rebooting also showed that container config registry was empty.

After changing the registry via the terminal with the "/container/config set registry-url=" it look like it took and the registry was updated when running the "/container/config print" again. I was also able to confirm editing the registry via winbox gui was now working after at least setting it once via terminal.

Strange.

Update - Reported this issue to Mikrotik support@mikrotik.com. They were able to reproduce it and said it would be fixed on a later update.