Error running on latest (v4)

[klara31]

Did you change something on the latest version? I am toggling between Raspberry Pi OS armhf and arm64 (still waiting for a stable version of the latter). I was running on arm64, but for some reason, network sometimes does not come up at boot. So I switched back to a clean armhf image.
Now I noticed piaware was not providing data. Checking the logs shows:
[dump1090] 2020/12/06 17:17:14 /usr/local/bin/dump1090: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

When reverting back from latest to before_refactor, it works OK. Something wrong with v4 (running on armhf)?

[mikenye]

Sorry about this - I have no way to test on armhf yet. I'll try to get my hands on an earlier Pi.

I've added the missing library and am rebuilding the image.

[klara31]

You can just run it on a Pi4 if you have one. They run both armhf and arm64.
As soon as the new build comes online, I will give it a try

[mikenye]

The images have been rebuilt. Let me know if that fixes the problem. Thanks.

[klara31]

Just pulled latest again, and I am still getting the same error...

[mikenye]

Hi @klara31, sorry for the delay. Is it exactly the same error (missing libatomic.so.1)?

[klara31]

This is the error:
/usr/local/bin/dump1090: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

[mikenye]

Hi @klara31, could you provide the output of uname -m from your host?

Looking at the armhf version of the container, dump1090 doesn't appear to need libatomic:

root@6aecf2a782b3:/# uname -m
armv7l
root@6aecf2a782b3:/# ldd $(which dump1090)
	linux-vdso.so.1 (0xbee91000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6e8f000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e14000)
	librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6dfe000)
	librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xb6de2000)
	libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xb6d6c000)
	libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xb6d57000)
	libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xb6ccf000)
	libncurses.so.6 => /lib/arm-linux-gnueabihf/libncurses.so.6 (0xb6ca7000)
	libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0xb6c7a000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6b80000)
	/lib/ld-linux-armhf.so.3 (0xb6f0a000)
	libusb-1.0.so.0 => /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (0xb6b5f000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6a54000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6a2b000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6a18000)
	libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb69f0000)

... however, I've included libatomic in the image's packages, so it should be there anyway:

root@6aecf2a782b3:/# find / -type f,l -name '*libatomic.so.1*' -exec ls -lah {} \;
lrwxrwxrwx 1 root root 18 Apr  6  2019 /usr/lib/arm-linux-gnueabihf/libatomic.so.1 -> libatomic.so.1.2.0
-rw-r--r-- 1 root root 22K Apr  6  2019 /usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0

I've (last night) changed the build process, so if you could pull the latest version and try again, it would be appreciated.

Thanks for your patience.

[klara31]

On the host:

root@flight:~# uname -m
aarch64
root@flight:~# cat /etc/apt/sources.list.d/docker.list
deb [arch=armhf] https://download.docker.com/linux/raspbian buster stable
root@flight:~# docker info
Client:
 Debug Mode: false

Server:
 Containers: 9
  Running: 9
  Paused: 0
  Stopped: 0
 Images: 9
 Server Version: 19.03.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ea765aba0d05254012b0b9e595e995c09186427f
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.4.79-v8+
 Operating System: Raspbian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 1.809GiB
 Name: flight
 ID: 2CQV:J5QX:J6EO:4IRP:QBNV:MPTN:CB2K:IPEQ:PB5Z:47PF:TWLG:3Q3O
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

and in the container:

root@1d658542a370:/# uname -m
aarch64

I do have arm_64bit=1 in /boot/config.txt, but the base OS is the official 32bit Raspbian.
When using exactly the same board and the same docker-compose.yml on a 64bit Raspbian (the beta version), there is no error and piaware runs fine.

[mikenye]

Can I trouble you to run the following commands:

On the host: file $(which cp)

In the container:

file $(which dump1090)
ldd $(which dump1090)

Thanks.

[klara31]

On the host:

pi@flight:~ $ file $(which cp)
/usr/bin/cp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=eb5d9d5d19a1b120325e502590eebc81787bc81d, stripped

In the container:

root@1d658542a370:/# file $(which dump1090)
bash: file: command not found
root@1d658542a370:/# ldd $(which dump1090)
        libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xf7ecd000)
        libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xf7e18000)
        librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xf7e01000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xf7de1000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xf7d53000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xf7d3d000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xf7c93000)
        libncurses.so.6 => /lib/arm-linux-gnueabi/libncurses.so.6 (0xf7c63000)
        libtinfo.so.6 => /lib/arm-linux-gnueabi/libtinfo.so.6 (0xf7c32000)
        libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xf7add000)
        /lib/ld-linux.so.3 (0xf7f59000)
        libusb-1.0.so.0 => /lib/arm-linux-gnueabi/libusb-1.0.so.0 (0xf7ab8000)
        libatomic.so.1 => not found
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabi/libstdc++.so.6 (0xf7972000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabi/libgcc_s.so.1 (0xf7943000)
        libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xf7930000)
        libudev.so.1 => /lib/arm-linux-gnueabi/libudev.so.1 (0xf78ff000)
root@1d658542a370:/#

[mikenye]

Hi @klara31,

I've updated the build action to build single platform versions of the image, so the following images are now available:

• mikenye/piaware:latest_arm_v6
• mikenye/piaware:latest_arm_v7
• mikenye/piaware:latest_arm64

Comparing your output from your system above with the outputs below, it looks like your docker is using the arm/v6 architecture version of the image (based on library paths names).

mikenye/piaware:latest_arm_v6:

root@883e1ffb4d31:/# ldd $(which dump1090)
        libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xf79ff000)
        libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xf794a000)
        librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xf7933000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xf7913000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xf7885000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xf786f000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xf77c4000)
        libncurses.so.6 => /lib/arm-linux-gnueabi/libncurses.so.6 (0xf7794000)
        libtinfo.so.6 => /lib/arm-linux-gnueabi/libtinfo.so.6 (0xf7763000)
        libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xf760e000)
        /lib/ld-linux.so.3 (0xf7a8b000)
        libusb-1.0.so.0 => /lib/arm-linux-gnueabi/libusb-1.0.so.0 (0xf75e9000)
        libatomic.so.1 => /usr/lib/arm-linux-gnueabi/libatomic.so.1 (0xf75cf000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabi/libstdc++.so.6 (0xf7489000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabi/libgcc_s.so.1 (0xf745a000)
        libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xf7447000)
        libudev.so.1 => /lib/arm-linux-gnueabi/libudev.so.1 (0xf7416000)

mikenye/piaware:latest_arm_v7:

root@40e6d8c2c2aa:/# ldd $(which dump1090)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf7def000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf7d74000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xf7d5e000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xf7d42000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xf7ccc000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xf7cb7000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xf7c2f000)
        libncurses.so.6 => /lib/arm-linux-gnueabihf/libncurses.so.6 (0xf7c07000)
        libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0xf7bda000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7ae0000)
        /lib/ld-linux-armhf.so.3 (0xf7e6a000)
        libusb-1.0.so.0 => /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (0xf7abf000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xf79b4000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf798b000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xf7978000)
        libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xf7950000)

mikenye/piaware:latest_arm64:

root@a57bdb4a25f5:/# ldd $(which dump1090)
        linux-vdso.so.1 (0x0000ffff9caee000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff9ca32000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff9c975000)
        librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff9c95d000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0x0000ffff9c93b000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0x0000ffff9c89c000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0x0000ffff9c885000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0x0000ffff9c7b7000)
        libncurses.so.6 => /lib/aarch64-linux-gnu/libncurses.so.6 (0x0000ffff9c781000)
        libtinfo.so.6 => /lib/aarch64-linux-gnu/libtinfo.so.6 (0x0000ffff9c743000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff9c5d1000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff9cac0000)
        libusb-1.0.so.0 => /lib/aarch64-linux-gnu/libusb-1.0.so.0 (0x0000ffff9c5aa000)
        libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffff9c41f000)
        libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff9c3fb000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff9c3e7000)
        libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000ffff9c3b3000)

However, I notice that your system says libatomic.so.1 => not found, although the output from the arm/v6 image above shows it does exist in the image, so I'm not sure if there is caching going on somewhere or another issue...

Are you able to try all three of the above single-architecture images and see if any give you success?

[klara31]

I tried this with a simple docker, created with: docker run -d -e LAT=1 -e LONG=1 mikenye/piaware:latest_arm*

mikenye/piaware:latest_arm_v6:

root@5c9098748621:/# ldd $(which dump1090)
        libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xf7850000)
        libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xf779b000)
        librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xf7784000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xf7764000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xf76d6000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xf76c0000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xf7615000)
        libncurses.so.6 => /lib/arm-linux-gnueabi/libncurses.so.6 (0xf75e5000)
        libtinfo.so.6 => /lib/arm-linux-gnueabi/libtinfo.so.6 (0xf75b4000)
        libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xf745f000)
        /lib/ld-linux.so.3 (0xf78dc000)
        libusb-1.0.so.0 => /lib/arm-linux-gnueabi/libusb-1.0.so.0 (0xf743a000)
        libatomic.so.1 => /usr/lib/arm-linux-gnueabi/libatomic.so.1 (0xf7420000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabi/libstdc++.so.6 (0xf72da000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabi/libgcc_s.so.1 (0xf72ab000)
        libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xf7298000)
        libudev.so.1 => /lib/arm-linux-gnueabi/libudev.so.1 (0xf7267000)

mikenye/piaware:latest_arm_v7:

ldd $(which dump1090)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf7f2c000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf7eb1000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xf7e9b000)
        librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0xf7e7f000)
        libbladeRF.so.2 => /usr/local/lib/libbladeRF.so.2 (0xf7e09000)
        libhackrf.so.0 => /usr/local/lib/libhackrf.so.0 (0xf7df4000)
        libLimeSuite.so.20.10-1 => /usr/local/lib/libLimeSuite.so.20.10-1 (0xf7d6c000)
        libncurses.so.6 => /lib/arm-linux-gnueabihf/libncurses.so.6 (0xf7d44000)
        libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0xf7d17000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7c1d000)
        /lib/ld-linux-armhf.so.3 (0xf7fa7000)
        libusb-1.0.so.0 => /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (0xf7bfc000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xf7af1000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf7ac8000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xf7ab5000)
        libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xf7a8d000)

mikenye/piaware:latest_arm64 does not start up...
I'm not sure what is happening here... confusing...

[mikenye]

OK. I would suggest you use mikenye/piaware:latest_arm_v7. That should work for you.

[klara31]

will do, thanks again :)

[mikenye]

No problems, thanks for your patience.