Open AKHwyJunkie opened 6 months ago
dirkhh
commented
6 months ago 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
commented
6 months ago 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
commented
6 months ago 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
commented
6 months ago 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.
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
commented
6 months ago 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
commented
6 months ago 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
commented
6 months ago 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:
The install procedure for ASDB-IM is slightly modified as doing the above changes default behavior of Docker's availability via default repositories.
apt-get install -y python3-flask python3-requestsTo 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
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:
Output of systemctl status adsb-docker.service:
The full journalctl -xeu adsb-docker.service output is as follows, which repeats failure 6 times and then ceases as expected:
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.