Deleting image from the local registry

Technical Support
, , , ,
1

I have changed my Dockerfile and now I want to force the Torizon IDE to re-build the image.
Of course, in order to avoid landing with the already existing one, I need to delete it from the registry.

Current, I get UNSUPPORTED operation message on the delete request over HTTP:

vmetodiev@vmetodiev:~$ curl -sS -X DELETE 192.168.100.6:5002/v2/helloc-debug/manifests/sha256:2662d6eabb156e425f47b73cb9935346ddeac5b647dd7fed631f2e62dbbca80d
{"errors":[{"code":"UNSUPPORTED","message":"The operation is unsupported."}]}

Is there any recommended flow for this?

Thanks!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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

Hello! Thank you for your question.

The error you’re seeing, {"code":"UNSUPPORTED","message":"The operation is unsupported."}, occurs because the default Docker Registry (registry:2) you are using does not support the DELETE operation by default. This is a known behavior—image deletion via HTTP API is disabled unless explicitly enabled on the registry configuration.

Recommended Flow for Forcing an Image Rebuild in Torizon IDE:

  1. Rebuild with --pull:
    Instead of deleting the image from the registry, you can force a rebuild and push a new version of the image using the Docker --pull flag. This ensures the base image is updated:

    docker build --pull -t <username>/my-image .
docker push <username>/my-image

    (Reference)

  2. Tag with a New Version:
    It’s also common practice to tag each build with a new tag (version or hash). This avoids confusion with cached or stale images:

    docker build -t <username>/my-image:<tag> .
docker push <username>/my-image:<tag>

    Update your deployment or compose files to use the new tag.

  3. If You Need to Delete Images:
    Deleting images directly from the Docker registry is not straightforward due to the default settings:

    • You would need to reconfigure your registry to enable delete support (not generally recommended for embedded workflows, as it may impact registry stability).
    • Alternatively, if the registry loss is acceptable, you can simply delete and recreate your local registry data directory on the server. However, this removes all images.

Summary:
For most Torizon development workflows, it’s best to force a fresh build and push (with or without a new image tag) rather than deleting images from the registry.

For more details:

Let me know if you need further details or run into other issues!

Best regards,
Toradex AI Assistant.

3

In addition to the @ToradexAI suggestion, I don’t want to make (and commit) a new tag of the image, but to re-create it completely.

4

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thank you for clarifying your requirement.

If you want to completely recreate (overwrite) an image in your local Docker registry without creating a new tag, you can follow this workflow:

  1. Build the container image and tag it with the same name as before, pointing to your local registry:

    docker build -t localhost:5000/<my-container-image> .

  2. Push the newly built image to your local registry (this will overwrite the old image with the same tag):

    docker push localhost:5000/<my-container-image>

This process will ensure that the existing image in your registry is replaced with the new build, and the Torizon IDE will use the latest version when deploying to your device.

If you are using the Torizon IDE extensions, tasks like run-container-torizon-release-<arch> will also rebuild and redeploy the image, ensuring you’re always running the most recent version without manually deleting the image from the registry.

Please make sure all necessary files and dependencies are correctly specified in your Dockerfile to ensure successful builds.

References:

Best regards,
Toradex AI Assistant.

5

Hi @vmetodiev

I was not able to fully understand what you were trying to do.

How did you trigger this command?
You manually typed it in the terminal? From where did you get this ???

If you just want to delete an image from the local registry, can’t you just?

docker rmi <image-id>
6

Hi @allan.tx ,

Well… upon deploying from the Torizon IDE, I have the following on the device:

torizon@verdin-imx8mm-15400884:~$ docker images
REPOSITORY                        TAG       IMAGE ID       CREATED       SIZE
192.168.100.6:5002/helloc-debug   arm64     e03b9aee29ba   2 days ago    256MB
portainer/portainer-ce            2.17.1    ada025d39772   2 years ago   267MB
torizon/chromium                  2         cb7ac4913734   2 years ago   609MB
torizon/weston-vivante            2         eb17fa1e613f   2 years ago   424MB

Then, I delete the deployed docker container (instance):

torizon@verdin-imx8mm-15400884:~$ docker ps -a | grep 'helloc'
d7ebb7e73a92   192.168.100.6:5002/helloc-debug:arm64   "/usr/sbin/sshd -D"      3 minutes ago   Up 3 minutes   0.0.0.0:2230->2230/tcp, :::2230->2230/tcp                       torizon-helloc-debug-1

torizon@verdin-imx8mm-15400884:~$ docker stop d7ebb7e73a92
d7ebb7e73a92
torizon@verdin-imx8mm-15400884:~$ docker rm d7ebb7e73a92
d7ebb7e73a92

And the image:

  1. From the Verdin:
torizon@verdin-imx8mm-15400884:~$ docker images
REPOSITORY                        TAG       IMAGE ID       CREATED       SIZE
192.168.100.6:5002/helloc-debug   arm64     e03b9aee29ba   2 days ago    256MB
portainer/portainer-ce            2.17.1    ada025d39772   2 years ago   267MB
torizon/chromium                  2         cb7ac4913734   2 years ago   609MB
torizon/weston-vivante            2         eb17fa1e613f   2 years ago   424MB
torizon@verdin-imx8mm-15400884:~$ docker rmi e03b9aee29ba 
Untagged: 192.168.100.6:5002/helloc-debug:arm64
Untagged: 192.168.100.6:5002/helloc-debug@sha256:2662d6eabb156e425f47b73cb9935346ddeac5b647dd7fed631f2e62dbbca80d
Deleted: sha256:e03b9aee29ba8aab8d3e6e35ad2b35ff856b466e042ef6e58ce617399accc7b4
  1. From the PC where I run VScode (Torizon IDE):
vmetodiev@vmetodiev:~$ docker images
REPOSITORY                     TAG                               IMAGE ID       CREATED         SIZE
localhost:5002/helloc-debug    arm64                             e03b9aee29ba   2 days ago      256MB
cross-toolchain-arm64-helloc   latest                            1d2fdd66f080   2 days ago      497MB
torizon/torizoncore-builder    3                                 3763b2759554   6 weeks ago     1.46GB
nvidia/cuda                    12.0.1-cudnn8-devel-ubuntu22.04   187c5dc02f8f   18 months ago   9.89GB
registry                       2                                 26b2eb03618e   19 months ago   25.4MB
torizon/binfmt                 latest                            893244d86992   4 years ago     37.5MB

vmetodiev@vmetodiev:~$ docker rmi e03b9aee29ba
Untagged: localhost:5002/helloc-debug:arm64
Untagged: localhost:5002/helloc-debug@sha256:2662d6eabb156e425f47b73cb9935346ddeac5b647dd7fed631f2e62dbbca80d
Deleted: sha256:e03b9aee29ba8aab8d3e6e35ad2b35ff856b466e042ef6e58ce617399accc7b4

At this stage, if I check the registry on my PC, I have something remained:

vmetodiev@vmetodiev:~$ curl -sS 192.168.100.6:5002/v2/_catalog
{"repositories":["helloc-debug"]}

After that, I am going to VScode and run Ctrl + F5 to re-deploy everything, expecting that I will end up with a freshly built container (thus forcing Torizon IDE to re-run docker build with the changes I have made in my Dockerfile).

WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string. 
[+] Pushing 16/16
 ✔ Pushing localhost:5002/helloc-debug:arm64: e5e519fe8cba Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 29d21206053d Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 2862f3d001f4 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 7ade0e303278 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: ef5ab135b4e1 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 0d44ca85e203 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: cbfca7efdd64 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: c5852bef3e08 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 6cd757f87b26 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 84f02289282b Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: db9633f880e7 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: ab925bd8dc65 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 5f70bf18a086 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: ac6442dc9f87 Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 169ce75e923c Layer already exists                                                                       0.0s 
 ✔ Pushing localhost:5002/helloc-debug:arm64: 66a307619b8c Layer already exists                                                                       0.0s 
 *  Terminal will be reused by tasks, press any key to close it. 

 *  Executing task: DOCKER_HOST=192.168.100.7:2375 LOCAL_REGISTRY=192.168.100.6 TAG=arm64 GPU=-imx8 DEBUG_SSH_PORT=2230 DEBUG_PORT1= DEBUG_PORT2= DEBUG_PORT3= docker compose pull helloc-debug 

WARN[0000] The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string. 
[+] Pulling 15/17
 ⠧ helloc-debug [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 90.51MB / 91.49MB Pulling

And upon listing the images, I get the following:

torizon@verdin-imx8mm-15400884:~$ docker images
REPOSITORY                        TAG       IMAGE ID       CREATED       SIZE
192.168.100.6:5002/helloc-debug   arm64     e03b9aee29ba   2 days ago    256MB
portainer/portainer-ce            2.17.1    ada025d39772   2 years ago   267MB
torizon/chromium                  2         cb7ac4913734   2 years ago   609MB
torizon/weston-vivante            2         eb17fa1e613f   2 years ago   424MB

192.168.100.6:5002/helloc-debug arm64 e03b9aee29ba 2 days ago 256MB

And the 2 days ago makes me think that I am still deploying from the registry remnants…

7

@vmetodiev

But did you change anything in the Dockerfile?
It’s reusing all the layers from the cache.

Try running this on your PC:

docker system df
docker builder prune -af

Just to point it out, but this is not exclusive to Torizon or the IDE.
This is all about how Docker containers work, so you may find more information on Docker’s documentation.

8

Hi @allan.tx ,

I just saw the in Docker Compose YAML that the debug and release builds use different Dockerfiles. Everything is fine…

Apologise for the false alert and thanks for your help!

Best regards,
Varban