VSCode plugin container build broke over night, again... Not sure how to report this bug

Technical Support
, ,
1

So this is the second time this has happened this week, I can’t give another 12 hours to debugging the build system.

Leaving off yesterday, I pushed a working config.yaml and source to my private repo. Both release and debug SDK and app containers were tested working on my Apalis Imx6 module, connected via ethernet on a ixora 1.2 board.

Booting up today, I can no longer re-build and release or debug container. If I just boot up my dev machine, how is the “Image is not up to date”?

This happened earlier this week and I chocked it up to it being my first time setting up a VSCode Torizon C++ project and I spent a looonnggg time trying to understand what went wrong. I was very careful this time and verified that the container build worked BEFORE and AFTER my last commit yesterday. The only I fixed it was to completely scrub all the images and containers from my host machine and re-import the source from scratch. This is obviously not a sustainable solution.
The output from the build process:

[07-02 20:37:31.426] Preparing debug environment for C/C++ application...
[07-02 20:37:31.435] Running preLaunchTask build_debug...
[07-02 20:37:53.117] preLaunchTask completed.
[07-02 20:37:53.117] Deploying application to local folder...
[07-02 20:37:54.515] Selecting device...
[07-02 20:37:54.526] Device 10645191 selected.
[07-02 20:37:54.526] Updating app configuration...
[07-02 20:37:54.545] Image is not up to date, building it (this may take some time)...
[07-02 20:38:07.883] Step 1/9 : FROM --platform=linux/arm torizon/qt5-wayland:2
[07-02 20:38:08.841] ---> 9d1578a6f370
[07-02 20:38:08.845] Step 2/9 : EXPOSE 6502
[07-02 20:38:08.846] ---> Using cache
[07-02 20:38:08.846] ---> 27fb052b5e95
[07-02 20:38:08.846] Step 3/9 : ARG SSHUSERNAME=torizon
[07-02 20:38:08.846] ---> Using cache
[07-02 20:38:08.847] ---> 9aa72d822fdd
[07-02 20:38:08.847] Step 4/9 : ENV DEBIAN_FRONTEND="noninteractive"
[07-02 20:38:08.847] ---> Using cache
[07-02 20:38:08.847] ---> 204f9992118b
[07-02 20:38:08.847] Step 5/9 : RUN apt-get -q -y update     && apt-get -q -y install     gdbserver     procps     qml-module-qtquick2 qml-module-qtquick-extras qml-module-qtquick-window2 qml-module-qtquick-controls2 qml-module-qtquick-controls qml-module-qtmultimedia qml-module-qtgraphicaleffects libqt5bluetooth5 libsocketcan2 libqt5serialbus5 libqt5network5 libgpiod2 libqt5multimedia5 libqt5multimediaquick5 libqt5multimedia5-plugins gpiod    && rm -rf /var/lib/apt/lists/*
[07-02 20:38:10.601] ---> [Warning] The requested image's platform (linux/arm) does not match the detected host platform (linux/amd64) and no specific platform was requested
[07-02 20:38:10.601] ---> Running in 8ab558468598
[07-02 20:38:11.189] e[91mstandard_init_linux.go:228: exec user process caused: no such file or directory
e[0m
[07-02 20:38:11.781] Error (530) - Docker exception: The command '/bin/sh -c apt-get -q -y update     && apt-get -q -y install     gdbserver     procps     qml-module-qtquick2 qml-module-qtquick-extras qml-module-qtquick-window2 qml-module-qtquick-controls2 qml-module-qtquick-controls qml-module-qtmultimedia qml-module-qtgraphicaleffects libqt5bluetooth5 libsocketcan2 libqt5serialbus5 libqt5network5 libgpiod2 libqt5multimedia5 libqt5multimediaquick5 libqt5multimedia5-plugins gpiod    && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 1
code:1
message:The command '/bin/sh -c apt-get -q -y update     && apt-get -q -y install     gdbserver     procps     qml-module-qtquick2 qml-module-qtquick-extras qml-module-qtquick-window2 qml-module-qtquick-controls2 qml-module-qtquick-controls qml-module-qtmultimedia qml-module-qtgraphicaleffects libqt5bluetooth5 libsocketcan2 libqt5serialbus5 libqt5network5 libgpiod2 libqt5multimedia5 libqt5multimediaquick5 libqt5multimedia5-plugins gpiod    && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 1

I can guarantee that the problem is NOT: file/docker permissions, line endings, debian package / repo issues, typos in the config yaml or autogenerated dockerfile. In fact, if I copy the dockerfile and run it on my host, i get the same result… how could the RUN / CMD or installed apt get "spoiled’ over night on the “qt5-wayland:2” in my cache? If I remove the RUN apt line, the image will build. Rebuilding the SDK does not help, removing qt5-wayland:2 from the cache does not help.

A clue: If I close VScode, git reset --hard, and open VSCode I get:


[2021-07-02T20:57:32.348Z] Remote-Containers 0.183.0 in VS Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48).

[2021-07-02T20:57:32.348Z] Start: Resolving Remote

[2021-07-02T20:57:32.352Z] Setting up container for folder or workspace: XXXXXXX/code/XXXXXXX

[2021-07-02T20:57:32.354Z] Start: Check Docker is running

[2021-07-02T20:57:32.355Z] Start: Run: docker version --format {{.Server.APIVersion}}

[2021-07-02T20:57:32.404Z] Stop (49 ms): Run: docker version --format {{.Server.APIVersion}}

[2021-07-02T20:57:32.405Z] Server API version: 1.41

[2021-07-02T20:57:32.405Z] Stop (51 ms): Check Docker is running

[2021-07-02T20:57:32.415Z] Start: Run: git rev-parse --show-cdup

[2021-07-02T20:57:32.421Z] Stop (6 ms): Run: git rev-parse --show-cdup

[2021-07-02T20:57:32.423Z] Start: Run: docker ps -q -a --filter label=vsch.local.folder=XXXXXXX/code/XXXXXXX --filter label=vsch.quality=stable

[2021-07-02T20:57:32.461Z] Stop (38 ms): Run: docker ps -q -a --filter label=vsch.local.folder=XXXXXXX/code/XXXXXXX --filter label=vsch.quality=stable

[2021-07-02T20:57:32.464Z] Start: Run: docker build -f XXXXXXX/code/XXXXXXX/.devcontainer/Dockerfile -t vsc-XXXXXXX-7bc3cec1dc29b91f57a0b4e28fa8d310 XXXXXXX/code/XXXXXXX/.devcontainer

[2021-07-02T20:57:32.508Z] Sending build context to Docker daemon  6.144kB

[2021-07-02T20:57:32.598Z] Step 1/2 : FROM sha256:c6d2f6ee23b947a7f1905ea990c8baa8a76724f2e72a685bbbc93622d0653dc1

[2021-07-02T20:57:32.940Z] pull access denied for sha256, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

[2021-07-02T20:57:32.946Z] Stop (482 ms): Run: docker build -f XXXXXXX/code/XXXXXXXXXXXXX/.devcontainer/Dockerfile -t vsc-XXXXXXXXXXXXX-7bc3cec1dc29b91f57a0b4e28fa8d310 
XXXXXXXXXXXXXcode/XXXXXXX/.devcontainer

[2021-07-02T20:57:32.958Z] Command failed: docker build -f XXXXXXXXXXXXX/code/XXXXXXXXXXXXX/.devcontainer/Dockerfile -t vsc-XXXXXXXXXXXXX-7bc3cec1dc29b91f57a0b4e28fa8d310 
XXXXXXXXXXXXXX/code/XXXXXXXXXXx/.devcontainer

I’m on ubuntu 18.04 fwiw and I have had docker setup for years to do all sorts of things on this machine.

I miss just regular old cross-compiling and rsync, I even miss yocto, why is everything a bloody website of websites? That is to say, any help would be appreicated, and this does seem like a bug of fatally severe consequence.

2

Of course after typing all that out, I got the build working with what seems like a good lead on a simple bug in the extension: If I manually delete the .devcontainer folder THEN rebuild the SDK it works! RUN apt does indeed start installing packages in the deploy image.

3

The:
standard_init_linux.go:228: exec user process caused: no such file or directory
error is due to the fact that ARM emulation is not enabled on the host machine.
We do enable it when the VS extension starts, but we don’t do this when it’s running inside a container (there are issues figuring out what the actual host OS is…).
You may try to enable it manually with the Torizon: Enable ARM emulation command.
Sorry for the issue.

4

Ahhhh, I’ll watch out this in the future, many thanks. I had been treating the “image platform” warnings as a non-issue. Makes sense that the “contained” apt is an arm bin. Unfortunately this VSCode command doesn’t work for me… ??Ubuntu 18.04?? Same thing happened. I opened VSCode to play around with the valter.tx’s suggestion and this is the only thing I did in the IDE.

2842-badvscode.png
2842-badvscode.png1123×272 44.2 KB

5

Okay more weird behaviour:

Most docker platform warnings made sense (building arm on a linux host)… but now it thinks the host is arm64! What would reconfigure the project as arm64??? I guess the devcontainer or build container is being run as arm64 now, but wasn’t last week??? Again, I just started up VSCode fresh to try to test the arm emulation fix suggested above.

Also this VSCode installation has only ever compiled or debugged a very 32bit imx6q Apalis module. No 64 bit targets ever. During these tests, I did not have the Apalis module connected to the system (bridged over ethernet typically). Maybe some eager code reconfigured the dev or build container dockerfile as arm64 in the absence of the Apalis on the network (which would be kinda insane)??? Quick questions: does brought up here: does the “build” container build the deploy image? or does the devcontainer? Is there a workflow without the devcontainer??? I’d be just fine building both cross-comp and deploy images natively.

Step 1/10 : FROM --platform=linux/arm torizon/qt5-wayland:2


 ---> 9d1578a6f370

Step 2/10 : EXPOSE 6502


 ---> Using cache

 ---> 786fe2690da2

Step 3/10 : ARG SSHUSERNAME=root


 ---> Using cache

 ---> 2545e37f0216

Step 4/10 : ENV DEBIAN_FRONTEND="noninteractive"


 ---> Using cache

 ---> e1a7204b08bd

Step 5/10 : RUN usermod -a -G gpio torizon


 ---> [Warning] The requested image's platform (linux/arm) does not match the detected host platform (linux/amd64) and no specific platform was requested

 ---> Running in 6cd186b52707

e[91mstandard_init_linux.go:228: exec user process caused: no such file or directory
e[0m
[07-08 23:07:25.352] Local docker exception.
6

Spamming my own question in case any of this helps anyone else:

I fixed things by “Open the folder locally” to exit the “devcontainer”… i think… the “Remote Explorer” VSCode extension shows no active containers. VSCode was starting inside the devcontainer, but that was messing things up. I’m guessing that the Toradex extension may be in compatible with the Remote Explore and or Docker extensions??

Back to [Warning] The requested image's platform (linux/arm) does not match the detected host platform (linux/amd64) and successfully building a debug deploy container for the target.

7

Container is linux/arm, host is linux/amd64 not arm64.
That’s the architecture of your development machine.
I don’t see references to arm64 in the log.
Since enabling emulation is the issue, I suggest to do that manually.
You can run:

docker run -it --rm --privileged torizon/binfmt

before you start working on the project.