What should we not update or upgrade?


I have just changed my RPi3 to boot from a 120GB SSD. This gives me more storage for data and also a more robust disk than the SD card. I also added a remote power-off button, UPS monitoring and a heart-beat LED all which are controlled from a Python task which is started by CRON.

In the course of doing this I started to do the usual “sudo apt-get update” followed by “sudo apt-get upgrade” process and then stopped before upgrading. As I didn’t build this image then I started to wonder what packages are required by the “quake software”. Rather than break the system I wondered what parts of the system are to left untouched?

I want to add Python 3.5 next as 2.7 is shortly going unsupported but have now stopped doing anything until the situation is clearer as to what you can touch and what you should not.


Hi @dgoadby, this is a good question. My answer will be verbose but not specific, because there’s little way to know how upgrading something will ultimately affect the system. That’s part of the nature of relying on UNIX software as a custom release.

  1. Python 2.7 becoming unsupported is a non-issue, unsupported does not mean it stops working, it will continue to work just fine as is.
  2. We do not recommend full-upgrading the OS yourself, this is typically not necessary, and may (or may not) break the Shake system, and there is no way to predict this.
  3. Running sudo apt update and then installing whatever software you need is generally safer than upgrading the entire system. The fewer dependencies you upgrade the less likely you will be to break anything. You’re welcome to experiment with doing this. If you break anything…
  4. …downloading the latest image available will always guarantee that the OS is restored to a working release.
  5. If this becomes a long-running unit, with your own custom software installed, you should make your own installation routine so that installation on top of an updated OS, provided in the latest Shake OS image, is as trivial as possible. I do this on my own Shakes.

Some of my previous attempts to do a full sudo apt upgrade have broken things, and some have not. In general, given the aforementioned nature of UNIX software, the longer it’s been since a raspishake OS release, the more likely you are to upgrade a package that the Shake software relies on which may or may not end up breaking it.

Hope this helps.


I should also mention that while you can do whatever you want to the system, when you do, we take no responsibility whatsoever if the system stops working, and we will very likely be unable to help you diagnose what went wrong. In that case, refer to #4 above:


Thanks for the information and all understood. I always have a fresh SD card to hand just in case.

As the system is running Docker I kind of assumed that the 'quake software looked after itself and there were few system constraints as that is kind of the point. Using Docker makes sense as upgrades are easy to deploy although the current total size of 444MB does assume that we all have good Internet bandwidth and quotas.

All I have to do now is find out why my station doesn’t show on the map.

1 Like

If you attach your logs we can help you look into it.



Well what do you know? I have just appeared on the map! Patience rewarded…

We had a quake in the UK today about 100 miles north of me. It’s a fracking site. The quake was magnitude 2.9 @ 2km deep. I checked my traces and in the N & E traces I do have an event but the time is a little later after the quake time. Assuming quakes don’t travel very quickly it could easily be my first real event. If it is I’m well chuffed.


Assuming P waves travel ~6 km/sec, S waves travel ~3.5 km/sec (both could vary widely depending on local geology), and 100 miles = 160 km:

# p wave travel time:
>>> 160 / 6

# s wave travel time:
>>> 160 / 3.5