When I try to debug a hello world c++ project, I get the following error:
The terminal process “sshpass ‘-p’, ‘torizon1’, ‘ssh’, ‘-o’, ‘UserKnownHostsFile=/dev/null’, ‘-o’, ‘StrictHostKeyChecking=no’, ‘torizon@10.100.19.19’, ‘LOCAL_REGISTRY=10.100.19.205 TAG=arm64 docker-compose pull bgcplus-debug’” terminated with exit code: 18.
Its the same when I run build-debug-arm64:
…
[11-29 10:09:12.808] Device 10.100.19.19 set as Docker Host
[11-29 10:09:13.844] Debian bookworm packages list load OK
[11-29 10:09:47.830] ERROR :: pull-container-torizon-debug-arm64 failed with exit code 18
I just see, before this sshpass error it shows: docker compose build %s bgcplus-debug Error response from daemon: manifest for 10.100.19.205:5002/bgcplus-debug:arm64 not found: manifest unknown: manifest unknown
When the extension creates your container image it creates a local registry on the same PC you are running the extension. This is to use as an intermediary storage for your container images while you’re developing.
Now what looks like is happening here is that the extension is trying to access your container image via this identifier 10.100.19.205:5002/bgcplus-debug:arm64, but for some reason this isn’t being found. Could you try pulling this image from your local registry and confirm whether that is the case or not.
Also what version of the extension are you using and on what platform? (Linux/Windows)
I truely would love to pull the image from local registry, but before I can start learning this, I have spent 40 hours now trying to set up a hello world project and though including a lot of toradex direct help, I am still not at the point to run the eayiest project. Maybe you can tell me a location of a documentation of docker commands which goes beyond --help. I dont know how to go on, and browsing the articles in the community turns out to be endless and frustrating before finding just the one tip that could solve it.
On your Toradex device run docker pull 10.100.19.205:5002/bgcplus-debug:arm64. What do you get? Do you see a similar error as seen in the extension?
If yes try stopping and removing the registry container on your PC running the extension with docker stop and docker rm. Then re-try the deploy process since this will create a new registry that way we can see if the issue happens again or not.
Also you didn’t answer what kind of PC/platform you’re running the extension on and what version of it you are running.
Sorry, I was traveling and didnt have access to the system: The development IDE is VSCode 1.84.2 with docker desktop V4.25.1 on Ubuntu 22.04.3 LTS under WSL 2.0.9.0 on Windows 10.0.22631.2715
And yes, it is a similar result:
Error response from daemon: manifest for 10.100.19.205:5002/bcgplus-debug:arm64 not found: manifest unknown: manifest unknown
I tried the “docker stop registry” and “docker rm registry”. Then I had to restart VSCode. By the way, after it opened Powershell, it hang until I pressed a key, then I saw that it created a registry container. After restarting VSCode, it had the same error 18 again
After restarting VSCode, it had the same error 18 again
Well it seems consistent at least. Okay there seems to be something wrong with the registry container when it runs on your system for some reason. Though it’s not clear what’s wrong yet. I also have a Windows 10 system with Ubuntu 22.04 on WSL and I’m not seeing this issue on my setup.
Let’s try some tests here to see if we can diagnose what is wrong with the registry container. The following command should be executed in your WSL terminal.
This command will list all the container images found in your registry:
curl -X GET http://localhost:5002/v2/_catalog
Do you see your bcgplus-debug image listed?
If yes then try listing all the tags for your image:
curl -X GET http://localhost:5002/v2/bcgplus-debug/tags/list
Do you see the arm64 tag listed?
This should show us whether your container image is even in your registry to begin with.
The answer to the containers is:
{“repositories”:}
For my understanding, on WSL when I do “docker container list” I get
“CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3cd599349262 registry:2 “/entrypoint.sh /etc…” 6 hours ago Up 6 hours 0.0.0.0:5002->5000/tcp registry”
So registry is a container under docker. And now bgcplus-debug is supposed to be a container image within the container “registry”?
I now tried the “run-docker-registry” task within VSCode. It throws:
Run Arguments: -d -p 5002:5000 --restart=always registry:2
Container Name: registry
Error response from daemon: No such container: registry
Container does not exists. Starting …
Okay then so it looks like there’s no container image stored in your registry. Therefore the error you’re getting is accurate it really can’t find the image, since it’s not there to begin with. Though this doesn’t make sense since your container image should be pushed to this registry prior to deploying and debugging.
The task that is responsible for this is push-container-torizon-debug-arm64. Could you try explicitly executing this task in VSCode via the task runner. Then observe whether this task actually succeeds or not. And if it does succeed try running that curl command again to confirm whether your container image is in the registry this time.
So registry is a container under docker. And now bgcplus-debug is supposed to be a container image within the container “registry”?
So a container registry is a place to store container images. Like Dockerhub for example. The registry container is a container that simulates such a registry. That way you don’t have to setup your own registry manually and you don’t have to push your container to an external registry like Dockerhub while you’re still in development.
What our extension does is build your container image containing your application. It then pushes this container image to this registry running on your PC. When it comes time to deploy/debug, the Toradex device will pull the container image from this registry on your PC.
Now as I said, you’re getting an error here cause for some reason your container image was never actually pushed into your registry. So when it came time for the device to pull the image, there was nothing to pull.
Unfortunately there is no task push-container-torizon-debug-arm64 that I could run.
I have been looking around with docker images on my system and found the following
When I run “docker images” in the VSCode Terminal, I get docker images REPOSITORY TAG IMAGE ID CREATED SIZE 192.168.0.215:5002/bg1-debug arm64 3601da7ba488 3 months ago 181MB torizon/torizon-provisioner 0.0.11 09af1149c647 23 months ago 10MB
These seem to be images, that were created during the bootcamp, when VSCode was running on Linux within a dropbox
When I do “docker images” under the wsl terminal, I get REPOSITORY TAG IMAGE ID CREATED SIZE cross-toolchain-amd64-bgcplus latest 7dbe64814cb4 25 hours ago 466MB localhost:5002/bgcplus-debug arm64 abd7f3759633 2 days ago 235MB cross-toolchain-arm64-bgcplus latest c7f0cb0f8154 2 days ago 472MB registry 2 ff1857193a0b 5 weeks ago 25.4MB torizon/torizoncore-builder latest b2fa5265d0ad 3 months ago 939MB torizon/binfmt latest 893244d86992 3 years ago 37.5MB
which seems to be the new stuff when I installed VSCode on Windows after the bootcamp.
So I was assuming these docker instances are not the same, which might be wrong?
I tried to set up the docker registries on VS-Code to “Generic Registry V2” on http://localhost:5002, but that did not change anything. I dont want to change more things, because I might rather make it worse, and unfortunately I really dont know what I am doing.
Toradex IDE Extension v2.3.1
Yes in the tasks.json there is “push-container-torizon-debug-arm64”.
But under MenuItem “Terminal->Run Task…” there are only the tasks, which are shown on “Explorer Task Runner”:
That’s very strange your TASK RUNNER seems to be missing a lot of tasks.
What template are you using specifically? Also have you tried creating a new project from scratch, then deploy and debug the fresh project? Does that work?
When you do the deploy and debug process do you see the push task get executed at all in the logs?
to me even more. I am using "Torizon: Create New Single Container project. And there I have created a QT C++ project and the current one is a C++ Makefile Console Application.
This is basically all the happens, when I press the run-debug button
I can see the image that was pushed on wsl terminal
Okay so I can the push is being ran. If you run that curl command from before is your container image actually in the registry container?
But when I list docker images within VSCode, there are only old ones:
Okay that is strange I don’t know why you’re seeing a different list of containers between the VSCode terminal and the WSL terminal. Are these terminals not connected to the same thing? On my setup they’re both essentially the WSL terminal.
Let me try and consult one of our IDE specialist here, because you’re seeing and describing a lot of strange behavior that I can’t reproduce or explain.
But when I list docker images within VSCode, there are only old ones:
Earlier you mentioned you have Docker Desktop installed. Did you then install Docker engine in your WSL environment as well?
I believe this would create 2 docker instances on your PC one from the WSL and another from Docker desktop. Maybe the extension is getting confused between the two.
On my setup I only have Docker Desktop installed. I never installed Docker separately in WSL. Via Docker Desktop I can invoke the docker command in WSL that way.
Perhaps with the 2 docker instances on your PC the extension pushes your image to one instance but the device is pulling from the other (empty) instance. If that makes sense.
This sounds reasonable. And how can I solve this?
When I was going according to the toradex howto install site, it was unclear to me that due to license reasons I should only install the docker engine and not the full Desktop. I tried this, but it finally ended up in a Desktop…
I mean it is not as simple as “uninstall this software” because there are so many software packages under so many platforms
When I was going according to the toradex howto install site, it was unclear to me that due to license reasons I should only install the docker engine and not the full Desktop. I tried this, but it finally ended up in a Desktop…
Well we recommend just the engine since it’s not feasible for everyone to be able to use Desktop. That said using the desktop is fine and works as that is what I do in my setup.
This sounds reasonable. And how can I solve this?
Are you able to confirm whether you have both installed in the first place? In any case I would just recommend removing/uninstalling everything Docker related to be sure. Make sure it’s gone from both Windows and in WSL. Then everything is clean, try installing just the Docker engine in WSL as we instruct here: Set up the Torizon IDE Extension 2 Environment | Toradex Developer Center
Like I said you could alternatively install Docker Desktop in Windows like I have, just make sure you only install one or the other, not both.
I tried uninstall of various compenents, finally even all tools related to the IDE. It seems rather difficult, because when reinstalling it still has data from previous installations. I am not sure how I could uninstall with all data destroyed. On my next install, it ran to a different point, until it came to an error result 17.
Therefore I started trying to install on a completely different computer. But on that I have the same issue like on the first installation, when the trouble began. It is that I install wsl with Ubuntu-22.04 successfully and then go exact through the steps to install docker-engine from here: Install Docker Engine on Ubuntu | Docker Docs Install using the apt repository.
There is a problem at the end of this install:
torizon_ide@CPQBG5:/mnt/c/Users/bernh$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin Reading package lists… Done Building dependency tree… Done Reading state information… Done The following additional packages will be installed:
docker-compose-plugin libltdl7 libslirp0 pigz slirp4netns* 0 upgraded, 11 newly installed, 0 to remove and 111 not upgraded. Need to get 114 MB of archives. After this operation, 410 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 Index of /ubuntu jammy/universe amd64 pigz amd64 2.6-1 [63.6 kB] Get:2 Index of linux/ubuntu/ jammy/stable amd64 containerd.io amd64 1.6.25-1 [28.7 MB] Get:3 Index of /ubuntu jammy-updates/main amd64 dbus-user-session amd64 1.12.20-2ubuntu4.1 [9442 B] Get:4 Index of /ubuntu jammy/main amd64 libltdl7 amd64 2.4.6-15build2 [39.6 kB] Get:5 Index of /ubuntu jammy/main amd64 libslirp0 amd64 4.6.1-1build1 [61.5 kB] Get:6 Index of /ubuntu jammy/universe amd64 slirp4netns amd64 1.0.1-2 [28.2 kB] Get:7 Index of linux/ubuntu/ jammy/stable amd64 docker-buildx-plugin amd64 0.11.2-1~ubuntu.22.04~jammy [28.2 MB] Get:8 Index of linux/ubuntu/ jammy/stable amd64 docker-ce-cli amd64 5:24.0.7-1~ubuntu.22.04~jammy [13.3 MB] Get:9 Index of linux/ubuntu/ jammy/stable amd64 docker-ce amd64 5:24.0.7-1~ubuntu.22.04~jammy [22.6 MB] Get:10 Index of linux/ubuntu/ jammy/stable amd64 docker-ce-rootless-extras amd64 5:24.0.7-1~ubuntu.22.04~jammy [9030 kB] Get:11 Index of linux/ubuntu/ jammy/stable amd64 docker-compose-plugin amd64 2.21.0-1~ubuntu.22.04~jammy [11.9 MB] Fetched 114 MB in 10s (10.9 MB/s) Selecting previously unselected package pigz. (Reading database … 24137 files and directories currently installed.) Preparing to unpack …/00-pigz_2.6-1_amd64.deb … Unpacking pigz (2.6-1) … Selecting previously unselected package containerd.io. Preparing to unpack …/01-containerd.io_1.6.25-1_amd64.deb … Unpacking containerd.io (1.6.25-1) … Selecting previously unselected package dbus-user-session. Preparing to unpack …/02-dbus-user-session_1.12.20-2ubuntu4.1_amd64.deb … Unpacking dbus-user-session (1.12.20-2ubuntu4.1) … Selecting previously unselected package docker-buildx-plugin. Preparing to unpack …/03-docker-buildx-plugin_0.11.2-1~ubuntu.22.04~jammy_amd64.deb … Unpacking docker-buildx-plugin (0.11.2-1~ubuntu.22.04~jammy) … Selecting previously unselected package docker-ce-cli. Preparing to unpack …/04-docker-ce-cli_5%3a24.0.7-1~ubuntu.22.04~jammy_amd64.deb … Unpacking docker-ce-cli (5:24.0.7-1~ubuntu.22.04~jammy) … Selecting previously unselected package docker-ce. Preparing to unpack …/05-docker-ce_5%3a24.0.7-1~ubuntu.22.04~jammy_amd64.deb … Unpacking docker-ce (5:24.0.7-1~ubuntu.22.04~jammy) … Selecting previously unselected package docker-ce-rootless-extras. Preparing to unpack …/06-docker-ce-rootless-extras_5%3a24.0.7-1~ubuntu.22.04~jammy_amd64.deb … Unpacking docker-ce-rootless-extras (5:24.0.7-1~ubuntu.22.04~jammy) … Selecting previously unselected package docker-compose-plugin. Preparing to unpack …/07-docker-compose-plugin_2.21.0-1~ubuntu.22.04~jammy_amd64.deb … Unpacking docker-compose-plugin (2.21.0-1~ubuntu.22.04~jammy) … Selecting previously unselected package libltdl7:amd64. Preparing to unpack …/08-libltdl7_2.4.6-15build2_amd64.deb … Unpacking libltdl7:amd64 (2.4.6-15build2) … Selecting previously unselected package libslirp0:amd64. Preparing to unpack …/09-libslirp0_4.6.1-1build1_amd64.deb … Unpacking libslirp0:amd64 (4.6.1-1build1) … Selecting previously unselected package slirp4netns. Preparing to unpack …/10-slirp4netns_1.0.1-2_amd64.deb … Unpacking slirp4netns (1.0.1-2) … Setting up dbus-user-session (1.12.20-2ubuntu4.1) … Setting up docker-buildx-plugin (0.11.2-1~ubuntu.22.04~jammy) … Setting up containerd.io (1.6.25-1) … Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service → /lib/systemd/system/containerd.service. Setting up docker-compose-plugin (2.21.0-1~ubuntu.22.04~jammy) … Setting up libltdl7:amd64 (2.4.6-15build2) … Setting up docker-ce-cli (5:24.0.7-1~ubuntu.22.04~jammy) … Setting up libslirp0:amd64 (4.6.1-1build1) … Setting up pigz (2.6-1) … Setting up docker-ce-rootless-extras (5:24.0.7-1~ubuntu.22.04~jammy) … Setting up slirp4netns (1.0.1-2) … Setting up docker-ce (5:24.0.7-1~ubuntu.22.04~jammy) … invoke-rc.d: could not determine current runlevel Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service. Created symlink /etc/systemd/system/sockets.target.wants/docker.socket → /lib/systemd/system/docker.socket. Processing triggers for man-db (2.10.2-1) … Processing triggers for libc-bin (2.35-0ubuntu3.1) … /sbin/ldconfig.real: Can’t link /usr/lib/wsl/lib/libnvoptix_loader.so.1 to libnvoptix.so.1 /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link
and after that I cant run docker run hello-world, because “docker daemon is not running”. When I start “sudo dockerd” it ends with failed to start daemon: Error initializing network controller: error obtaining controller instance: unable to add return rule in DOCKER-ISOLATION-STAGE-1 chain: (iptables failed: iptables --wait -A DOCKER-ISOLATION-STAGE-1 -j RETURN: iptables v1.8.7 (nf_tables): RULE_APPEND failed (No such file or directory): rule in chain DOCKER-ISOLATION-STAGE-1
