which I have on Hold to prevent a slightly buggy AirNav Systems from overwriting the bug-fixed version from abcd567
What I would like to know is it safe to just go ahead and issue sudo apt full-upgrade which will update the FA stuff along with dump1090-fa?
And can I finally take mlat-client off hold or have they still not fixed that annoying bug yet?
I always get nervous before updating my VR Pi as in addition to feeding FA it also feeds FR24, RB24 and ADSB-X and I am thinking about feeding Freedar - does anybody else here share data with Freedar as I done a search and nothing turned up…
If I was in your place, I will simply use a SPARE microSD card to write Raspberry Pi OS Bullseye, then install lateat versions of all feeders.
Still the bug persists. Please brows these two very recent threads in RadarBox24 forum. Problem was finally solved by purging RB24 supplied mlat-client and installing mlat-client built from source code. The mlat-client source-code is available at github/mutability.
I have 5 Pi’s carrying out various tasks and I like to keep them all the same so not planning to update from Buster to Bullseye on just one of them at the moment.
Likewise not planning to update all 5 to Bullseye at the moment either!
Are we saying that FA 7.2 is Bullseye only and will not run under Buster and if so does that mean that dump1090-fa v7.2 is also Bullseye specific?
If it is not recommended I update either while still running Buster do you think it would be OK to do what I currently do with mlat-client and put a sudo apt-mark hold on both piaware and dump1090 just so I can continue to update the rest of my system?
If so what filenames would I use to stop piaware being updated based upon the above apt list --upgradable as although it looks easy to add dump1090-fa I am confused as to what I should add for the remaining piaware-repository/unknown and piaware-unknown unless it is as simple as specifying piaware?
I also notice rbfeeder has an update so fingers crossed that won’t upset anything;
I do have a recent clone of my currently working system so can always revert to that in the event of a meltdown but I’m just trying to minimise the impact of updating in the first place.
I’ll retain the hold on mlat-client as I have no faith whatsoever in AirNav ever fixing that particular bug if waiting for them to fix the annoying bug of not being able to highlight aircraft in their v6.02.003 Windows app since they modified it to support their ludicrously overpriced XRange devices in 2017/2018 is anything to go by not to mention many more bugs some of which I was reporting back in 2008
I’m very happy with the performance of my VR Pi (apart from slipping just outside of the Top 10 UK RadarBox Ranking recently) but really should take on board some of the 143 Raspbian updates sat there waiting patiently to be installed…
Thanks & kind regards,
-=Glyn=-
If you recall it was you who recommended I use the hold on mlat-client some time ago and that has worked exactly as it should have done and prevented it getting overwritten by the buggy version.
No, ver 7.2 of piaware, dump1090-fa, & dump978-fa are available for BUSTER also, but package for Buster will have an additional suffix ~bpo10+1 in their name.
Thanks for the link abcd…I’ve read that and other stuff but but as usual the more I read the more confused I get so do you think it would be OK to just run sudo apt full-upgrade and let it take care of itself along with the system updates or should I upgrade piaware by itself using the following;
If I have to install it by itself should I then also sudo apt-get install dump1090-fa afterwards?
They both show when I apt list --upgradable so hoping the usual sudo apt full-upgrade might work…
You know me abcd…I need it spelt out in plain English and some hand-holding before I commit even though I have a cloned micro SD Card waiting to go just in case and it usually seems to work anyway!
I’ve got to the age now that if something catastrophic happened and my cloned card also failed that would be the end of my feeding as I don’t think I could go through all of the install/configuration of the last two years again…
I think running sudo apt full-upgrade will be a huge upgrade, as it will upgrade the OS from Buster to Bullseye.
Better try these simple commands which will upgrade only piaware and dump1090-fa from ver 6.1 to ver 7.2 (and may also upgrade few other packages as well which are dependencies for piaware and dump1090-fa)
Thanks again abcd…although I did update all five of my other Pi 4’s yesterday using sudo apt full-upgrade and they’re definitely still all on Raspbian GNU/Linux 10 (buster)?
You are right. It wont without adding Bullseye repo in apt sources list.
I did upgraded Buster to Bullseye by adding bullseye repo to buster, and even posted the method last year, but completely forgot it now. Seems aging is taking its toll.
I’m right there with you on that. I spend some time nearly every day thinking about the hereafter. I walk across the room then stop and think, “What am I here after?”
Well just to close the loop on this thread its taken me all this time to pluck up the courage to update my VR Pi and as before there was actually nothing to worry about when it came to it.
Not only did I clone the spare SD card I keep plugged in at all times but I also cloned a second one just in case such was my paranoia so if worst came to worst I could just slot in another SD card and of course if that one had an issue I had my second cloned SD card I could switch in!
I ended up with 218 updates in all including two of the four VR packages; FA/dump1090 7.2 along with rbfeeder 1.0.8
A quick sudo apt update followed by sudo apt full-upgrade just went through the process of updating everything with only two prompts - one about whether to keep or replace /etc/lighttpd/conf-available/89-skyaware.conf and the other offering the same decision on whether to keep or replace /etc/rbfeeder.ini and I chose the default option on both which was to keep current version.
A quick sudo reboot and the Pi came straight back up with everything appearing to work perfectly as before!
So a quick thank you to those who gave me the confidence to forge ahead with the update. Cheers!
Gives me more confidence to update in the future but I won’t leave it so long next time.
I do wonder just what the differences were between the new and existing config files were though? There was an option to show the differences between the versions but I didn’t want to tax the installer so just accepted the defaults.
Does anybody know what those differences are and is there an easy way to compare the differences retrospectively?
Hey Tom, sorry for the very late reply…I’ve just seen this.
Still on Buster for all 6 of my Pi’s but that might change soon because using my usual cloning procedure from my ‘Hot Spare’ Pi onto a spare SD Card to kick-start a new Pi into life seems to have failed miserably this time round.
I usually just change the IP Address and Hostname on a cloned SD Card to allow me to boot a new Pi quickly & easily keeping my customisations and a few utility apps all set up to save doing a complete installation/configuration every time I get a new Pi
This time around it hasn’t worked though with the new Pi flashing the green LED 4 short/4 times long and refusing to boot indicating ‘Unsupported board type’ but I’ve got a handle on the why and just need to implement the fix now hopefully. If that doesn’t work then I might be forced to update to Bullseye or better still wait for Bookworm.
First time I’ve been on here for ages as I’m just about to post yet another one of my paranoid pre-update questions as I notice piaware is ready to update from 7.2 to 8.2 along with dump1090fa
You would think what with my cloning the SD card first and having been down this road without issues in the past I would have enough courage to just plough ahead with the update but my peace of mind feels the need to run it past the community in here first!
I have indeed Tom…after waiting a very loooong time for the Pi 4 to come back into stock!
Research suggests its Revision 1.5 - my existing Pi’s are Revision 1.2 and there are some boot inconsistencies between them especially if the software is based on NOOBS which I believe mine was back in the day.
There is a possible fix as I want to keep all 7 Pi 4’s running the same base version if at all possible so I will be giving that a try to see how I get on.
I had started a thread on the RPi forums here and so will post back there after I have tried the suggestion so I seem to be on the right track.
Oh and I’m partway through updating my VR Pi so will know if that was successful (or not) shortly.
How about that…no procrastinations this time. I just went for it!
And everything seems to be OK on the newly updated VR Pi and I’ve gone from v7.2->8.2
I still have a hold on the mlat-client 0.2.11 from AIrNav as that had a bug whereby it wouldn’t restart automatically if was stopped/restarted but that was a while ago so that might be resolved now.
Hopefully @abcd567 will drop by to let me know as I believe I am still using the recompiled version from his GitHub
I also need to check to see if I am running the latest version of fr24feed and ADSBEXchange before I can sleep easy at night…
Seems I am running the current rbfeeder as that is normally updated when I do the usual sudo apt update and sudo apt full-upgrade but it’s been a long while since I have checked and I forget how!
As the mlat-client I compiled from source-code at mutability was working OK, I did not bother to check if the package currently provided by Radarbox24 repository is OK or not. I have put my compiled copy on hold (sudo apt-mark hold mlat-client), so it did not get replaced automatically during upgrades.
During last few days I have replaced my OS from Bullseye to Bookworm. On this OS neither the version of mlat-client supplied by Radarbox24, nor the 0.2.11 compiled by me worked. So I have compiled version 0.2.13 from dev branch, and it works OK with rbfeeder on Bookworm.
By the way on Bookworm even the installation script of Radarbox24 failed saying “Dont know how to install on…”, I cheated it to believe that the version is not Bookworm but Bullseye by addind a line VERS=bullseye just below their version detecting script which starts with VERS=. After this cheat, the RB24 install script installed the rbfeeder package without any problems, and it is working OK.
Please see screenshot below:
Following Two Screenshots are Applicable to Bookworm Only
Appreciate your reply as always abcd but I’m still on Buster here and have no intention of ever going to Bullseye but might have no alternative but to look at Bookworm at some point as the last couple of new Pi 4’s I have bought recently won’t boot from any of my existing Buster SD Cards just giving the 4 short/4 long green flash indicating Unsupported board type.
