Linux Install Bash Script Failing?

[AKHwyJunkie]

Hi there,

I'm interested in running this project, but I've been having troubles with the Linux installer instructions. I'd prefer to run this on a standard Linux variant as opposed to Raspberry Pi. I've tried a lot of different things and can't seem to figure it out.

I've found that the same problem happens regardless whether I use a Debian (11 or 12) or Ubuntu (23.04 or 23.10) OS. It also occurs whether I use the repository Docker or the "official" Docker via their repository. The failure codes aren't quite specific enough for me to deduce what might be going on. All dependencies have been resolved, at least according to the bash script's output. (i.e. python3, pyhton3-flask, git, docker, docker-compose) I also see the same thing when I download the script and run it locally.

All the systemd failures related to code 32 I've found seem to be file system related, issues with NFS and/or CIFS. I'm not super familiar with this methodology of invoking docker instances, so I'm not quite sure how to leverage more traditional docker debugging that I'd normally use to figure out why something doesn't start.

Help would be appreciated!

The install script failure:

root@adsb-im:~# curl https://raw.githubusercontent.com/dirkhh/adsb-feeder-image/main/src/tools/app-install.sh | sudo bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6135  100  6135    0     0  19693      0 --:--:-- --:--:-- --:--:-- 19726
You appear to be on a debian-style distribution
Cloning into '/tmp/tmp.dMrrArqBwO/adsb-feeder'...
remote: Enumerating objects: 9524, done.
remote: Counting objects: 100% (1479/1479), done.
remote: Compressing objects: 100% (492/492), done.
remote: Total 9524 (delta 973), reused 1286 (delta 873), pack-reused 8045
Receiving objects: 100% (9524/9524), 1.73 MiB | 1.60 MiB/s, done.
Resolving deltas: 100% (4370/4370), done.
Already on 'main'
Your branch is up to date with 'origin/main'.
Created symlink /etc/systemd/system/multi-user.target.wants/adsb-docker.service -> /lib/systemd/system/adsb-docker.service.
Job for adsb-docker.service failed because the control process exited with error code.
See "systemctl status adsb-docker.service" and "journalctl -xeu adsb-docker.service" for details.
Created symlink /etc/systemd/system/multi-user.target.wants/adsb-setup.service -> /lib/systemd/system/adsb-setup.service.
done installing
you can uninstall this software by running
sudo bash /opt/adsb/app-uninstall
root@adsb-im:

Output of systemctl status adsb-docker.service:

x adsb-docker.service - ADS-B Feeder Docker Service
     Loaded: loaded (/lib/systemd/system/adsb-docker.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2024-01-05 06:20:00 UTC; 24min ago
    Process: 4057 ExecStartPre=mount -o remount,exec /run (code=exited, status=32)
        CPU: 1ms

Jan 05 06:19:59 adsb-im systemd[1]: adsb-docker.service: Control process exited, code=exited, status=32/n/a
Jan 05 06:19:59 adsb-im systemd[1]: adsb-docker.service: Failed with result 'exit-code'.
Jan 05 06:19:59 adsb-im systemd[1]: Failed to start adsb-docker.service - ADS-B Feeder Docker Service.
Jan 05 06:20:00 adsb-im systemd[1]: adsb-docker.service: Scheduled restart job, restart counter is at 6.
Jan 05 06:20:00 adsb-im systemd[1]: Stopped adsb-docker.service - ADS-B Feeder Docker Service.
Jan 05 06:20:00 adsb-im systemd[1]: adsb-docker.service: Start request repeated too quickly.
Jan 05 06:20:00 adsb-im systemd[1]: adsb-docker.service: Failed with result 'exit-code'.
Jan 05 06:20:00 adsb-im systemd[1]: Failed to start adsb-docker.service - ADS-B Feeder Docker Service.

The full journalctl -xeu adsb-docker.service output is as follows, which repeats failure 6 times and then ceases as expected:

Jan 05 06:19:58 adsb-im systemd[1]: Starting adsb-docker.service - ADS-B Feeder Docker Service...
Jan 05 06:19:58 adsb-im systemd[1]: Starting adsb-docker.service - ADS-B Feeder Docker Service...
-- Subject: A start job for unit adsb-docker.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit adsb-docker.service has begun execution.
-- 
-- The job identifier is 760.
Jan 05 06:19:58 adsb-im systemd[1]: adsb-docker.service: Control process exited, code=exited, status=32/n/a
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- An ExecStartPre= process belonging to unit adsb-docker.service has exited.
-- 
-- The process' exit code is 'exited' and its exit status is 32.
Jan 05 06:19:58 adsb-im systemd[1]: adsb-docker.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit adsb-docker.service has entered the 'failed' state with result 'exit-code'.
Jan 05 06:19:58 adsb-im systemd[1]: Failed to start adsb-docker.service - ADS-B Feeder Docker Service.
-- Subject: A start job for unit adsb-docker.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit adsb-docker.service has finished with a failure.
-- 
-- The job identifier is 760 and the job result is failed.

And, FWIW, I also get the failure if I try to start the service manually. So, I think it's something related to that service.

root@adsb-im:~# sudo systemctl start adsb-docker.service
Job for adsb-docker.service failed because the control process exited with error code.
See "systemctl status adsb-docker.service" and "journalctl -xeu adsb-docker.service" for details.

[dirkhh]

The 'app install' on standard distributions is by far (I mean, order of magnitude) the least used and therefore least tested approach to installation.
I'll create a fresh VM to try to recreate the issue - the errors that you pasted here tell me nothing about what's going wrong.

[AKHwyJunkie]

I did gather as much from my reading. I can likely budget an SBC, but the value equation on these has changed in recent years. With 10MSPS being the "gold standard" these days, more CPU is often desirable for the enhanced resolution.

Also, while I have you, would you expect the new-gen Airspy R2 to work with your project? I know the Mini is compatible, but I'm thinking about updating my SDR and was considering this newer model.

[dirkhh]

I want this to work on a generic Linux version. Just give me the weekend to find time to fix this. I will fix it.

I don't know about the Airspy R2. You'd have to ask on the SDR-E Discord in the adsb-containers channel.

[dirkhh]

Hmm. So here's what I did:

Install a fresh Ubuntu 22.04 LTS
Run curl https://raw.githubusercontent.com/dirkhh/adsb-feeder-image/main/src/tools/app-install.sh | sudo bash
Wait maybe 30 seconds for this to complete (fast computer on a fast network - YMMV)
Connect to http://<ip-address>:1099
Fill out the data, click submit.
60 seconds later I had a working feeder, 90 seconds later I had a working map on http://<ip-address>:1090

I'm happy to try and debug what's going wrong for you.

• I haven't tried Ubuntu 23.anything as I don't have those around here
• This is in a VM, not on an actual computer
• This is a really basic setup, no shared drives, no weird filesystems, no other stuff

Can you reproduce this result and is this enough to get you going, or is there a hard requirement that is different from what I tried?

[AKHwyJunkie]

This helped and I found the rub. The issue was that I was trying to install into a Proxmox container, instead of a VM. Containers are my preferred approach to native Linux anything, plus it would alleviate any MLAT latency issues to USB since it provides native access to the host's hardware when passed through. I was able to get the service to start under a true VM. (Ubuntu 23.10 server edition was fine, FWIW.) I should have tried that!

I'll play around with the container based install and see if I can get that to work. I do know that simply offering a privileged container isn't enough. I'll update this issue if I'm able to find a working configuration.

[dirkhh]

Ah, interesting.
So yes - the problem with running this in a container is a bit trickier.
Given that the adsb.im feeder image wants itself to run containers, you need to facilitated nested Docker... I think the first thing that I would try is DooD - mounting the docker socket of your host machine (the Proxmox) as a bind mount into that container. That way, the app running inside that container is able to itself start more containers (which will talk to the outside docker daemon).
What I haven't thought through, though, is what this does to the ports and networking setup in my current setup. So that might need some adaption.
So this is completely untested, but maybe it gives you some ideas. If you make progress and can lay out the specific changes necessary, I might be willing to accept a pull request to add this as a feature. It's a cool idea, really.

[AKHwyJunkie]

OK, I got a working methodology using Proxmox containers. I fortunately didn't have to dive into DooD or DinD! I was starting to tear apart your source as I would prefer DinD, but then realized hardware passthrough was going to be a nightmare this way. So, I banged on it several more times as I thought it "should" be possible. I think I got caught up in enough iterations where I didn't shift the right variables at the right time.

In case someone follows in my footsteps, here's the procedure:

To create the container in Proxmox:

• Create a privileged container (This can't be easily changed later, so has to be done up front)
• I used Ubuntu 23.10, others Ubuntu flavors might work, but Debian 11/12 containers have some issues!
• Specs are to your liking, but minimums are likely 1vCPU/16GB vHDD/1GB vRAM
• Go into the container's options and enable nesting (disabled by default when creating privileged containers!)
• Prep machine as desired (enable SSH, updates, other baselines)

The install procedure for ASDB-IM is slightly modified as doing the above changes default behavior of Docker's availability via default repositories.

• Install Docker from Docker repository, since it's disabled when using nested virtualization
• Satisfy ASDB-IM pre-req's, slightly modified: apt-get install -y python3-flask python3-requests
• Your pre-req's could change based on OS release you use, but the bash script "should" tell you if you're missing anything.
• Run the curl'd bash script, or better yet, wget/review and then run as sudo (I found it to be trustworthy.)

To do this, you should understand the technical risks of running privileged containers using Docker and nested virtualization. Personally, I think it's safe in a home-lab environment with a low attack surface. If you're exposing your machine (container, docker, or app) to the public internet, that's a different ballgame and is highly risky.

Thanks for the help. I'm excited to get this going as it looks like it solved multiple feeders quite elegantly. I appreciate your hard work with the project, especially the detailed release notes.

Successful install with no service issues!

root@asdb-im:~# curl https://raw.githubusercontent.com/dirkhh/adsb-feeder-image/main/src/tools/app-install.sh | sudo bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6135  100  6135    0     0  18260      0 --:--:-- --:--:-- --:--:-- 18258
You appear to be on a debian-style distribution
Cloning into '/tmp/tmp.2pCb5QDOj6/adsb-feeder'...
remote: Enumerating objects: 9554, done.
remote: Counting objects: 100% (1509/1509), done.
remote: Compressing objects: 100% (506/506), done.
remote: Total 9554 (delta 994), reused 1307 (delta 885), pack-reused 8045
Receiving objects: 100% (9554/9554), 1.73 MiB | 2.31 MiB/s, done.
Resolving deltas: 100% (4391/4391), done.
Already on 'main'
Your branch is up to date with 'origin/main'.
Created symlink /etc/systemd/system/multi-user.target.wants/adsb-docker.service -> /lib/systemd/system/adsb-docker.service.
Created symlink /etc/systemd/system/multi-user.target.wants/adsb-setup.service -> /lib/systemd/system/adsb-setup.service.
done installing
you can uninstall this software by running
sudo bash /opt/adsb/app-uninstall