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.
Never mind, I had my Airspy Mini not fully inserted in the USB port. 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.
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 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.
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
.
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