I am trying to debug some c++ code that worked maybe 4 weeks ago. and now it’s complaining that it can’t find bookworm 3.0.8. that is called out in the docker.debug. What version does it need to be?
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.
Debian Container Base Version Issue
Based on the Toradex documentation, the container images for Torizon derive from the Bookworm release of Debian(1). The Torizon IDE extension templates use Debian-based containers with the torizonPackages.json file for managing packages(2).
Current Base Container Configuration
For Torizon-supported templates, the base container images use the torizon/ containers(2). The base version is typically defined in the Dockerfile with:
ARG BASE_VERSION=4
[...]
FROM --platform=linux/${IMAGE_ARCH} \
torizon/debian:${BASE_VERSION} AS debug
[...]
Debugging Container Structure
The debug container (Dockerfile.debug) is built on the host machine and executed on the SoM(3). Since build files are copied to the debug container during build time, the container needs to have the correct base image version(3).
Package Management Configuration
By default, the autocomplete feature in torizonPackages.json searches for packages from the Debian bookworm release(2). You can modify the torizon.debianRelease setting to select different Debian releases including:
bookwormbullseyestabletestingsid
Recommendation
Try updating your BASE_VERSION in the Dockerfile to version 4 (the current supported version) and ensure your torizon.debianRelease setting is configured for bookworm(2). This should resolve the container base image compatibility issue you’re experiencing.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Now I am getting this response:
docker compose build gimbal3bcontainer-debug
I look in my docker desktop and it shows the arm64 tagged version recently built.
if I run that command, it fails:
invalid tag “:5002/gimbal3bcontainer-debug:”: invalid reference format
I exported the LOCAL_REGISTRY value (ipaddress) and TAG=arm64
and it works, but not really.
I am trying to cp a file I need to have in where the exe is going to be so the exe can find it. I used to have it in the dockerfile.debug, but it doesn’t seem to like it there now for some reason.
I added this line which used to work:
RUN cp ./src/filename /root/app
used to work. Now it just says: “This did not complete successfully. Exit code :1
If i comment out that line and let it build it, it succeeds However, when pulling it out, it times out:
Error response from daemon: Get “http://192.168.11.102:5002/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
What does this mean, exactly?
Steve
Hey @EvetsMostel1,
The dockerfile.debug is used for when debugging applications. Is this your intention with your RUN command? Also please see the note regarding the Dockerfile.debug and copying files.
-Eric
No, I was simply trying to copy my file into the docker directory where the app runs. I got it to work, using the COPY macro. This used to work just using the cp command though. Something must’ve changed. Thanks for the link, it is helpful!
I fixed my other issue with the debugging not working. It was because of the settings of secure registry, and covering the different network configures I have to deal with. It used to work by leaving the subnet as 0 working like a wildcard. But apparently, that no longer works. At least on either the linux side or the torizon side. I had to put multiple addresses in it due to different run locations.
Steve