Installation of pfclient_5.3.2_arm64.deb an Piaware 10.2 SD card image fails (pi5)

I ran into one problem.

As I said, I used a 32-bit piaware sd card image before on my pi4.
Now I use Raspberry Pi OS Lite 64-bit on a new pi5.
I exported graphs1090 XML data from 32-bit pi4 and imported into the 64-bit pi5, like described here: Backup and Restore (moving from 32bit to 64bit, between arm64 and amd64 should be fine using the normal backup but no guarantees)
All historical data is shown on the new pi5, but it does not collect any new ADS-B data sind saturday 20:00
All 4 feeders (piaware, fr24feed, pfclient, rbfeeder) are working.
What config could I have missed?

rerun the graphs1090 install if you switched decoders, for example dump1090-fa to readsb.

You should also take a look at sites like airplanes.live / adsb.lol
Couple more exist. You can get historic and live data in quite some detail / with detailed track labels.

Anyhow adsb.im is less complex to the user but that abstraction requires some complexity of course.
The backup / restore is pretty nice if you ever have to redo your system though compared to installing raspbian lite.

I did not change to readsb, still using dump1090-fa like on my old pi4.
I did the reinstall of graphs1090 now using:

sudo bash -c "$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)"

Let’s see if I get ADS-B stats now. fingers-crossed

Well check the collectd logs as the graphs1090 readme suggests.

This is strange… it works after reinstall and reboot. Thanks!

Must have to do something with the XML import from the old 32-bit pi4, as I did the install on the pi5 in exactly this order:

sudo apt-get update; sudo apt-get full-upgrade
sudo apt-get clean; sudo apt-get autoclean; sudo apt-get autoremove; sudo apt-get purge;
sudo rpi-eeprom-update
sudo rpi-eeprom-update -a
sudo raspi-config
sudo dpkg-reconfigure tzdata

# PiAware
wget https://flightaware.com/adsb/piaware/files/packages/pool/piaware/f/flightaware-apt-repository/flightaware-apt-repository_1.2_all.deb
sudo dpkg -i flightaware-apt-repository_1.2_all.deb
sudo apt-get update
sudo apt-get install dump1090-fa
sudo apt-get install piaware
sudo apt-get install piaware-web
sudo apt-get install piaware-support
sudo piaware-status
sudo systemctl stop piaware
sudo piaware-config feeder-id *******-****-****-****-**************
sudo rm /var/cache/piaware/feeder_id
sudo systemctl restart piaware

# FR24
sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"
sudo service fr24feed status

# pfclient
wget http://client.planefinder.net/pfclient_5.3.2_arm64.deb
sudo dpkg -i pfclient_5.3.2_arm64.deb

# rbfeeder
sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
sudo apt-get install mlat-client -y
sudo rbfeeder --showkey
sudo systemctl restart rbfeeder
sudo piaware-config
sudo nano /boot/piaware-config.txt

# graphs1090
sudo bash -c "$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)"
sudo /usr/share/graphs1090/rrd-restore.sh /tmp/xml.tar.gz /var/lib/collectd/rrd/localhost
sudo nano /etc/default/graphs1090
sudo nano /etc/cron.d/graphs1090
#15 0 * * * bash -c "$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)"
sudo reboot
1 Like

Maybe airnav / rbfeeder are starting dump1090-mutability or installed that as a service.
That would mean dump1090-fa can’t use the SDR and graphs1090 can’t see the json files in /run/dump1090-fa because they don’t exist.

So much for less complexity :slight_smile:

Yes, that could be it:

pi@piaware:~ $ sudo find / -name "dump1090-mutability"
/run/dump1090-mutability

This exists also on my old pi4 32-bit piaware image, but there is no “/run/dump1090-fa” folder. :face_with_monocle:
Of course “dump1090-fa” is installed on the old pi4 system.
Is there anything I need to do now?

(1) AirNav Radarbox does NOT install dump1090-mutability. It installs following binary:

/usr/bin/dump090-rb

Neither an html folder for map, nor a service file are installed for dump1090-rb. The dump1090-rb binary is run by hard-coded command in rbfeeder binary if user makes following setting in file /etc/rbfeeder.ini

network_mode=false

(2) Flightradar feeder fr24feed installs dump1090-mutability ONLY IF

(a) user makes following setting in file /etc/fr24feed.ini:

receiver=dvbt

OR
(b) The fr24feed is installed before installing any decoder. In this case the fr24feeder detects abscence of decoder and triggers installation of dump1090-mutability.

 

This is strange, because I installed PiAware before FR24, as shown in my previous post.

Anyways… it works now after reinstalling graphs1090. :+1:

The Piaware is data feeder, and NOT a decoder. The dump1090-fa and readsb are decoders. The radarbox installed dump1090-rb binary is not detected by fr24feed as a decoder since it is dormant, it does not have service file or /run/dump1090-rb folder.

I know, but I meant the Section “# PiAware” from my .bash_history:

The first package I installed was “dump1090-fa”, then the other packages from PiAware.
Then FR24, pfclient, rbfeeder & graphs1090.

This is great. With this sequence of installation, fr24feed would have detect presence of dump1990-fa and wont initiate automatic installation of dump1090-mutability. However you will still see an empty directory /run/dump1090-mutability. This is created by file /usr/lib/fr24/create_missing_directories.sh whenever fr24feed is started, but it is NOT detected by graphs1090 as proof that dump1090-mutability is installed, and does not interfere in anyway with it. If dump1090-mutability is actually installed, this directory will hold aircrft.json file, lot of history.json files, receiver.json file, etc.

@wiedehopf
Anyway, the good news is that Debian and Raspbian Trixie repositories have discontinued hosting dump1090-mutability. The Flightradar24 will have to modify their feeder to work without thursting dump1090-mutability upon users. :wink:

I like the policy of Planefinder. They provide their feeder app only, and leave the user to install a decoder of his own choice. :+1:

Then the question still is why graphs1090 did stop updating the graphs until I reinstalled it. :winking_face_with_tongue:

As i wrote the decoder switched compared to the first install.
The install checks which decoder is running and configures accordingly.

If you have multiple decoders fighting for the SDR and ports it is random which one will start up.
Your system is probably still broken because it could not work properly on next boot.

@Tomcraft1980

Since @wiedehopf suspects you have multiple decoders installed, so to check which decoders are running / installed, please post output of following commands:

pgrep -l dump1090  

pgrep -l readsb  

cat /etc/fr24feed.ini | grep receiver  

cat /etc/rbfeeder.ini | grep network_mode  

 

 

I rebooted several times now and all 4 feeders and graphs1090 is working completely fine.

pi@piaware:~ $ pgrep -l dump1090
751 dump1090-fa
pi@piaware:~ $ pgrep -l readsb  
pi@piaware:~ $ cat /etc/fr24feed.ini | grep receiver 
receiver="beast-tcp"
pi@piaware:~ $ cat /etc/rbfeeder.ini | grep network_mode  
network_mode=true
pi@piaware:~ $ 

@abcd567 if the /run folder for mutability is present, something is wrong.

systemctl disable --now dump1090-mutability

Would possibly clean that up.
Or just check if it’s trying to run:

systemctl status dump1090-mutability

Even if it is not running now it could still be trying to run and failing.
Anyhow if it works, it works … until it doesn’t :slight_smile:

pi@piaware:~ $ systemctl status dump1090-mutability
Unit dump1090-mutability.service could not be found.

Everything works for now, so I am currently very happy with the setup. :wink:

Some stupid developer at FR24 has set in fr24feed that whenever fr24feed is started, the folder: /run/dump1090-mutability is created by file:
/usr/lib/fr24/create_missing_directories.sh,
irrespective of dump1090-mutability is installed or not installed,

 

 

Later Addition:
The Raspberry Pi OS Trixie will be released in a month or two. Debian Trixie (already released a month ago), has discontinued hosting dump1090-mutability in it’s repositories. It is natural that Raspberry Pi OS Trixie will also discontinue hosting dump1090-mutability in it’s repository. Now on Trixie, the fr24feed installation will not be able to create a mess by force-installing dump1090-mutability, that also silently in the background, and without user knowing it.

 

Good news, thanks! :+1: