Lora Basicstation & datadog multicontainer problems

Could use some help here.

I’ve got a RAK7244 developer gateway - basically a Lora hat on top of a Raspberry Pi 4.

I’ve deployed the basicstation from here (https://github.com/balenalabs/basicstation) with no problem as a single container.

But when I try to do multi-container with both basicstation (https://github.com/balenalabs/basicstation) & datadog (https://github.com/balena-io-examples/balena-datadog) agent I’m getting a failing build. The datadog container succeeds in the build, but the basicstation fails even though I did no modification of the code that works as a single container deploy.

Suggestions appreciated!

My docker-compose.yaml:

version: '2'
services:
  basicstation:
    build: ./basicstation
    privileged: true
  datadog:
    build: ./datadog
    privileged: true
    restart: always
    pid: "host"
    network_mode: "host"
    labels:
      io.resin.features.dbus: '1'
      io.resin.features.balena-socket: '1'

And the build fail logs:

[basicstation]  Step 6/7 : RUN make platform=rpi variant=std arch=aarch64
[basicstation]   ---> Running in 453b5b6c3bf2
[basicstation]  mkdir -p build-local/bin
[basicstation]  gcc -std=gnu11 -Isrc -DCFG_prog_crc32 src/crc32.c -o build-local/bin/crc32
[basicstation]  mkdir -p build-local/bin
[basicstation]  gcc -std=gnu11 -Isrc -DCFG_prog_genkwcrcs src/genkwcrcs.c -o build-local/bin/genkwcrcs
[basicstation]  build-local/bin/genkwcrcs $(cat src/kwlist.txt | sed -e '/^#/d;s/[ \t]\+#.*//') > build-local/temp-kwcrc.h
[basicstation]  mv build-local/temp-kwcrc.h src/kwcrc.h
[basicstation]  platform=rpi variant=std make -C deps/mbedtls
[basicstation]  make[1]: *** deps/mbedtls: No such file or directory.  Stop.
[basicstation]  
[basicstation]  makefile:67: recipe for target 'deps/mbedtls' failed
[basicstation]  make: *** [deps/mbedtls] Error 2
[basicstation]  
[basicstation]  Removing intermediate container 453b5b6c3bf2
[basicstation]  The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info]          Uploading images
[Success]       Successfully uploaded images
[Error]         Some services failed to build:
[Error]           Service: basicstation
[Error]             Error: The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info]          Built on arm01
[Error]         Not deploying release.
Remote build failed

Hey @barryjump welcome to the community! That is odd that it is not building. One thing I would start by doing is push the single container project and once that is there, copy the generated docker-compose.yml. You will find this in the “Releases” page for your application. I would then take that generated docker-compose and use that in the project and just push that, if that works then I would introduce the datadog service into the compose.

Did you create a new application to push the multicontainer project to or was it the existing one? The failure you are seeing seems like the base image is missing the some tools which means that something changed in the base image or your setup when between pushing the single container and the multicontainer version. If you can still get the single container version to build that will help us narrow it down.

Hey @shaunmulligan thanks for the warm welcome.

Funny you should say that, it’s actually exactly what I did after the first failed release. Here are some screens from the last failed build.

I will try building the same multi-container in a new application new to see if that helps with the base image issue and report back shortly.

@shaunmulligan back to report deploying to a brand new application gives the same error, which I guess eliminates the base image missing tools when going from single to multi possibility.

It must be something in my docker-compose.yml?

Hi there, it looks like the basicstation Dockerfile expects deps/ to be in the root, so that worked fine when it’s a single app, but not whe you have deps/ directory in ./basicstation/deps. This multi-container approach would require modifying various files (e.g. makefile) to specifically cater for this change.

Good eye Anton thanks for the tip.
Unfortunately that means I’m over my head technically speaking.
I’ll see if I can make sense of the complexity in the makefile code even if it looks like gibberish to me.

Ok, good luck, and let us know if you run into issues we can help with when making these changes.