Automated Installation Scripts for following Mahines & OS:
(1) x86_64 / amd64 Debian, Ubuntu & Kali on PC (2) 32-bit and 64-bit (armv7l & aarch64) Raspbian, Ubuntu, and Kali on RPI Model 4 (3) x86_64 / amd64 Arch Linux on PC (scroll down to next post)
I’m still trying to make this work, was too dumb to build it on my own, apparently. I run the above script (x86_64 Debian 10.8) attempting to update the build and doesn’t appear to actually update anything. Update via FlightAware “My ADS-B” page’s Site Configuration (gear icon) also fails, as Automatic updates not available for OS debian:10 (Debian GNU/Linux 10 (buster))
The above script runs, completes and suggests i reboot the machine, however after restarting (attempted both yesterday and today) the version remains: dump1090 ModeS Receiver dump1090-fa 4.0
Unsure what I’m doing wrong, but gaining physical access to the machine right now isn’t that easy, so SSH or remote desktop are the only options available. Appreciate the time and care you’ve put into these builds.
Seems that from your manual attempts to build, you already had cloned folders dump1090 and piaware_builder when you ran the script.
This will cause the script to fail. To make the script sucessful you need to first delete these forders as well as any dump1090-fa*.deb packages there.
Please list the files & folders in the directory from which you ran the script. If you ran the script while in home folder, following 2 commads will list these
cd ~/
ls
EDIT:
On March 19, 2021, I modified my scripts. Now there is no need to delete old source-code folders and built packages. The script updates the sexisting source code, then bulids & installs the latest version.
You’re absolutely correct, I had old files/folders in my home directory which would have prevented the initial script(s) from running. You’re amazing, sorry for the hassle. Will report back once upgrade is complete. You’re the best!
On March 19, 2021, I modified my scripts. Now there is no need to delete old source-code folders and built packages. The script updates the sexisting source code, then bulids & installs the latest version.
Thank you for always encouraging best-practices and the immense assistance you provide to this community overall. It is greatly appreciated. That being said, I’m a complete maroon and kind of embarrassed i continually failed over a period of two days and you swoop in to resolve the issues in a matter of minutes. Thank you. Appears to be working perfectly already.
@peatrick
Did you check version of dump1090-fa also?
The piaware and dump1090-fa packages are build and installed independent of each other. It is quiet possible that piaware ver 5.0 was built and installed successfully, but dump1090-fa ver 5.0 did not built and install, and you still have dump1090-fa ver 4.0 running. The piaware 5.0 can run with dump1090-fa 4.0 without complaining.
However if a previous version was built and installed, the source code of previous version is still existing on the machine. In this case the source code of latest version will not be downloaded with warning “fatal: destination path 'dump1090' already exists and is not an empty directory”. The script will then proceeded with building package from existing old source code, and install the old version over the old version.
To overcome this problem, I have modified the script as shown below. If the old source code exists, the script updates it to latest version and builds & installs the latest version.
The modifications shown below are for dump1090-fa, but I have done similar modifications in scripts for piaware and dump978-fa.
ORIGINAL CODE
MODIFIED CODE
git clone https://github.com/flightaware/dump1090 cd dump1090 sudo dpkg-buildpackage -b --no-sign
git clone https://github.com/flightaware/dump1090
cd dump1090
sudo sed -i 's/dh-systemd,//' debian/control
sudo dpkg-buildpackage -b --no-sign
One strange thing (rather a bug) in Kali2021 is that if a command is issued like below sudo apt install pkg1 pkg2 pkg3 pk4 ... pkgn
and if any one of these packages is not available, the apt gives warning about it and exits without installing rest of the installable packages.
Please see second command in screenshot below in which I have added a non-available package foo. In the command with package foo, the apt totally ignored the installable packages python3 and rtl-sdr
Finally solved the issue of failure of installation of dump1090-fa and piaware on Kali Linux 2021 as follows:
(1) In the installation script for the piaware, dump1090-fa, dump978-fa, & piaware-web added this snippet:
if [[ `lsb_release -sc` == "kali-rolling" ]]; then
sudo sed -i 's/dh-systemd,//' debian/control
fi
(2) In the installation scripts for the piaware, dump1090-fa, dump978-fa, and piaware-web changed commands for installation of dependencies from following format:
The automated install scripts given in the first post of this thread were originally written for a FRESH INSTALL on X86_64 architecture.
I have now upgraded these to also do the UPGRADE of an existing install. If someone has an older install such as 3.8.1 or 4.0, running these scripts upgrades dum1090-fa and piaware to latest version (currently 5.0)
Although the title of script is AMD64, I have done another modification to make it work on armv7l (32-bit) and aarch64 (64-bit) on RPi.
Now if the automated install script detects architecture is armv7l or aarch64 (i.e. 32-bit or 64-bit OS on RPi), it installs dump1090-fa version 5.1~dev (development branch). This is due to failure in installing version 5.0 (master branch) on aarch64 (64-bit OS on RPi). I have tested it on following two distros on RPI Model 4:
Update an existing installation of older version of dump1090-fa
Installation of dump1090-fa on RPi with 32 & 64 bit Raspbian, Ubuntu & Kali
I have added following snippet in automated installation script
cd dump1090
# If older version's cloned source code exists on the computer,
# following two commands will update it to latest
git fetch --all
git reset --hard origin/master
# If an installation is on RPi, following will select the
# appropriate version of source code (master or development)
if [[ `uname -m` == "aarch64" || `uname -m` == "armv7l" ]]; then
if [[ `lsb_release -si` == "Debian" ]]; then
echo "Using master branch"
else
echo "Using development branch"
git fetch --all
git reset --hard origin/dev
fi
fi
I just ran these install scripts on an existing Piaware 4 installation on an RPi4 running PiOS aarch64. Everything looks on my feeder on my Flightaware.com page, however, I can’t run local maps because lighttpd will not start. Here is the log info:
Mar 28 09:26:49 tahoe systemd[1]: lighttpd.service: Service RestartSec=100ms expired, scheduling restart.
Mar 28 09:26:49 tahoe systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 1.
Mar 28 09:26:49 tahoe systemd[1]: Stopped Lighttpd Daemon.
Mar 28 09:26:49 tahoe systemd[1]: Starting Lighttpd Daemon…
Mar 28 09:26:49 tahoe lighttpd[9532]: Duplicate array-key ‘/data/’
Mar 28 09:26:49 tahoe lighttpd[9532]: 2021-03-28 09:26:49: (configfile.c.1296) source: /etc/lighttpd/conf-enabled/89-skyaware.conf line: 41 pos: 1 parser failed somehow near here: (EOL)
Mar 28 09:26:49 tahoe lighttpd[9532]: 2021-03-28 09:26:49: (configfile.c.1296) source: /etc/lighttpd/lighttpd.conf line: 47 pos: 15 parser failed somehow near here: (EOL)
Mar 28 09:26:49 tahoe systemd[1]: lighttpd.service: Control process exited, code=exited, status=255/EXCEPTION
Mar 28 09:26:49 tahoe systemd[1]: lighttpd.service: Failed with result ‘exit-code’.
Mar 28 09:26:49 tahoe systemd[1]: Failed to start Lighttpd Daemon.
pi@tahoe:~ $ ls -al /etc/lighttpd/conf-enabled
07-mod_setenv.conf
47-stat-cache.conf
50-piaware.conf (newly created in this install)
88-dump1090-fa-statcache.conf
88-graphs1090.conf
88-tar1090.conf
89-dump1090-fa.conf
89-skyaware978.conf
89-skyaware.conf (newly created in this install)
90-javascript-alias.conf
95-tar1090-otherport.conf