Dear SatNOGS Client Ansible (aka satnogs-setup) users,
It’s time for an upgrade! The playbook has been updated to install the latest compatible stable versions of satnogs-client and gr-satnogs. This brings along some nice new features and fixes (see satnogs-client and gr-satnogs changelogs).
Q: How can I upgrade my SatNOGS software?
A: You can find detailed instructions on how to update your system in SatNOGS Client Ansible wiki page
Thanks for the update.
Both 23 & 24 have been upgraded 
Thanks for making the upgrade painless for this newbie. It worked perfectly for me.
That’s GS33 done as well.
Alex
I am updating my stations as well, but noticed that there is no git tag for the recent releases!
It was my mistake. Release tags are there all right.
SatNOGS Client Ansible has just been updated to use the latest version of SatNOGS client. See top post on how to update your station.
SatNOGS Client Ansible has just been updated to use the latest version of SatNOGS client. See top post on how to update your station.
Keep in mind that this update will remove the client web interface. If you definitely need it, do not upgrade! See SatNOGS Client v1.0 is released! for more details regarding SatNOGS Client.
Any anticipated issues with upgrading and autoscheduler?
No, the autoscheduler does not interact with the client.
If you had flashed an image which is based on Raspbian stretch (<= 2018080300), then it is recommended to move to the buster based image. The next release of gr-satnogs will not be compatible with your system which will become non-upgradable. Normally, a reflash with the latest image is required, as described here.
On this release of SatNOGS Client Ansible though, a new option has been added to upgrade all system packages which also supports distribution release upgrades without a reflash. This is pretty useful for cases where a reflash is difficult due to limited physical access, e.g. remote, roof, mast installations. It is recommended only for users who can troubleshoot a Debian system in case something goes wrong.
Ansible update went clean for me 2x, thanks!
I updated 2 stations:
187 was already running Buster - standard upgrade worked perfectly.
272 was running stretch, so I used the method in the wiki to first upgrade to buster. The only thing that wasn’t in the wiki was that the SATNOGS_SETUP_RELEASE_UPGRADE_ENABLED option was not available, so I had to first run UPDATE. After that, the upgrade to Buster and client 1.0 seem to have gone just fine, as well.
Great work!
–Roy
K3RLD
Thanks, I’ve just added this info into the wiki page.
Is there a new image to download? The link on the Pi3 page for the artifacts zip is still dated September and download of Stretch.
I just downloaded this artifacts.zip linked in the download-button and it identifies as follows:
pd@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Hmm… Just noticed that either my autoscheduling isn’t working, or isn’t working as well as it should. I’ll troubleshoot tonight (hopefully) and report back. Just had to make some manual observations and I’ve already forgotten how to do it efficiently!
Autoscheduling appears to be running normally on the station that was already Buster before the client upgrade.
However, I get this error when manually running schedule_single_station.py (station 272, the station that I had to upgrade to Buster):
Traceback (most recent call last):
File "/home/pi/autosked/gitclone/satnogs-auto-scheduler/schedule_single_station.py", line 6, in <module>
from satellite_tle import fetch_tles
File "/home/pi/.local/lib/python2.7/site-packages/satellite_tle/__init__.py", line 1, in <module>
from .fetch_tle import * # noqa
File "/home/pi/.local/lib/python2.7/site-packages/satellite_tle/fetch_tle.py", line 6, in <module>
from lxml import html
File "/home/pi/.local/lib/python2.7/site-packages/lxml/html/__init__.py", line 53, in <module>
from .. import etree
ImportError: /home/pi/.local/lib/python2.7/site-packages/lxml/etree.so: undefined symbol: PyFPE_jbufundefined symbol: PyFPE_jbuf: This is probably caused by lxml being compiled for a different python version (at install time) then what is installed currently (after the upgrade).
I recommend to create a python virtual environment and install fresh packages inside it and never install packages globally using pip to prevent such errors (installing python packages globally using apt et al. will also prevent such errors).
cd auto-scheduler
apt-get install python3-virtualenv
python3 -m venv scheduler_env
source scheduler_env/bin/activate
pip install -r requirements.txt
# And to deactivate the virtuelenv in your session again
deactivate
# The python interpreter inside the virtualenv (e.g. to be called from a cron script) can be found at:
auto_scheduler/scheduler_env/bin/python
Thanks! I will attempt this fix this evening and report back with my findings.