It's time to upgrade the software of your stations, again (Dec 23, 2020)

Thanks for pointing this out. For about 10 days, my setup was failing with libhdf5_serial.so.103 not getting found. A “sudo apt install libhdf5-dev” followed by Apply in satnogs-setup has enabled my station to run again. I thought my station was standard…

OK - I’m still getting intermittent failures but what is common to the all is the following line in the debug output:

Assertion 'close_nointr(fd) != -EBADF' failed at ../src/basic/fd-util.c:67, function safe_close(). Aborting.

I have absolutely no idea what’s going on here.
Any thoughts?

It looks like the current release is broken in Debian Buster. After updating I get the following output after an observation start:

Nov 03 15:09:24 rico-server satnogs-client[719]: Traceback (most recent call last):
Nov 03 15:09:24 rico-server satnogs-client[719]:   File "/usr/bin/satnogs_fm.py", line 441, in <module>
Nov 03 15:09:24 rico-server satnogs-client[719]:     main()
Nov 03 15:09:24 rico-server satnogs-client[719]:   File "/usr/bin/satnogs_fm.py", line 424, in main
Nov 03 15:09:24 rico-server satnogs-client[719]:     tb = top_block_cls(antenna=options.antenna, 
bb_freq=options.bb_freq, bw=options.bw, dc_removal=options.dc_removal, decoded_data_file_path=options.decoded_
Nov 03 15:09:24 rico-server satnogs-client[719]:   File "/usr/bin/satnogs_fm.py", line 89, in __init__
Nov 03 15:09:24 rico-server satnogs-client[719]:     tune_args, settings, samp_rate_rx, "fc32")
Nov 03 15:09:24 rico-server satnogs-client[719]:   File "/usr/lib/python3/dist-packages/soapy/soapy_swig.py", line 166, in make
Nov 03 15:09:24 rico-server satnogs-client[719]:     return _soapy_swig.source_make(nchan, device, dev_args, stream_args, tune_args, other_settings, sampling_rate, type)
Nov 03 15:09:24 rico-server satnogs-client[719]: RuntimeError: device_id missing.
Nov 03 15:09:29 rico-server satnogs-client[719]: Post observation script for sat id 39428
Nov 03 15:09:29 rico-server satnogs-client[719]: No processing to be done for sat id 39428
Nov 03 15:09:29 rico-server satnogs-client[719]: satnogsclient.observer.observer - ERROR - No waterfall data file found'`

Also, when running apt update; apt upgrade I get a couple of soapy updates, but after installing them and running apt upgrade gain they keep appearing, there seems to be something wrong in the versioning or so:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
 soapysdr0.7-module-airspy soapysdr0.7-module-audio soapysdr0.7-module-bladerf soapysdr0.7- 
 module-osmosdr soapysdr0.7-module-redpitaya
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/187 kB of archives.
After this operation, 0 B of additional disk space will be used.

My installation was fixed if i entered the driver=airspy rather than just airspy

I upgraded my station about a week ago. Everyhing works fine, including my custom script to upload iq files to Dropbox.

1 Like

Never mind, I had my Airspy Mini not fully inserted in the USB port. :sleeping: I found out after running SoapySDRUtil --probe, re-plugging the Airspy fixed it.

That doesn’t fix my persisting soapy updates of course, but I guess that’ll be fixed after the next soapy update.

I have a similar issue. After maintaining currency using “sudo satnogs-setup” over the past few months on my RPi with an RTLSDR v3 dongle, six SoapySDR modules keep showing as upgradable. After I do seek to upgrade them using apt, there is no version change and these same modules continue to appear as upgradable:

$ sudo apt list --upgradable
Listing... Done
soapysdr0.7-module-airspy/unknown 0.1.2-2 armhf [upgradable from: 0.1.2-2]
soapysdr0.7-module-audio/unknown 0.1.1-2 armhf [upgradable from: 0.1.1-2]
soapysdr0.7-module-bladerf/unknown 0.4.1-2 armhf [upgradable from: 0.4.1-2]
soapysdr0.7-module-hackrf/unknown 0.3.3-3 armhf [upgradable from: 0.3.3-3]
soapysdr0.7-module-lms7/unknown 20.01.0+dfsg-2 armhf [upgradable from: 20.01.0+dfsg-2]
soapysdr0.7-module-osmosdr/unknown 0.2.5-3 armhf [upgradable from: 0.2.5-3]

Try:

sudo apt-get clean

Thanks for this suggestion. I just tried it, and unfortunately it doesn’t help. The same 6 packages indicated in my post above are showing as upgradable.

I’m pleased to report that this issue is no longer present for me. Since I did nothing special on my side, I assume that something was fixed on the developer / distribution side of things.

1 Like

Ok, so I tried to upgrade today - result: broken
Install process went up to:
Install SatNOGS Flowgraphs…

localhost failed | msg: ‘/usr/bin/apt-get -y -o “Dpkg::Options::=–force-confdef” -o “Dpkg::Options::=–force-confold” install ‘satnogs-flowgraphs=1.2.2-1’’ failed: E: Unable to correct problems, you have held broken packages.
| stdout: Reading package lists…
Building dependency tree…
Reading state information…
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
satnogs-flowgraphs : Depends: gr-satnogs (< 2.2) but 2.2.0.0-1 is to be installed
| stderr: E: Unable to correct problems, you have held broken packages.

Any ideas what to do now?

Oh, I just see there was an issue opened while I was writing my comment: https://gitlab.com/librespacefoundation/satnogs/satnogs-client/-/issues/414

moved to: https://gitlab.com/librespacefoundation/satnogs/satnogs-client-ansible/-/issues/89

Hopefully there will be a solution, soon.

I encountered the same issue. As a temporary workaround, I enabled the “Experimental” setting (“Install latest versions of all software”) in the Software Package Settings using satnogs-setup. That seems to have resulted in a functioning system again.

Once the “stable” releases are again truly stable, I intend to switch this back.

Should have checked this thread before updating my system :slight_smile: Same failure here!

I used the experimental version but a test job failed. I will wait offline for info about a fix.

Have in mind that currently returning back to stable from experimental is only possible by flashing sd-card from scratch with the stable image.

1 Like

Same failure on my side…

The issue should be fixed for new updates but unfortunately it won’t recover stations which are already in this state.

To recover you need to manually run:
sudo apt-get purge libgnuradio-satnogs gr-satnogs
and then do a normal Update through satnogs-setup.

3 Likes

still the same issue. I´ll run my alternative SD Card again

@dl4eec or anyone else, could you provide logs after running sudo apt-get purge libgnuradio-satnogs gr-satnogs?

I´ll try later the day/night. Maybe others could be faster

1 Like