Simple process to update 4.2.0 to 4.2.3?

Issue: How to update previously-installed distributions?

Setup: RAK2245 on Pi-3B+, gateway 4.2.0 downloaded from

Server: Raspberry Pi-3B+; PiOS aarch64; Buster

Details: I installed rak_common_for_gateway 4.2.0 several months ago, configured it, and have been running just the ttn-gateway periodically since then, as I was learning the system. I’m preparing to do some development now and want to update to 4.2.3.

But I don’t see an easy way to do updates. If I clone 4.2.3 into a new directory and configure and install it, I presume it will overwrite the current (running) 4.2.0 version (meaning that I’d have to re-run the configuring programs again and re-install any changes I made).

I’ve done a “diff -r” on the 4.2.0/ and 4.2.3/ git clone directories, and the result is pretty long. But I think the changes I want are actually in the /opt/ttn-gateway/ directory that the install procedure creates, anyway, so the patch file that would result from the “diff -r” wouldn’t be useful anyway.

Am I missing something? Is there an easy way to apply ongoing RAK patches to the current, running gateway system so that I can keep the system up to date without doing a complete reinstall and reconfigure?

If not, is this the best way to do it, taking care along the way to back things up and check the results of each step before proceeding?

  1. systemctl stop ttn-gateway.service; systemctl disable ttn-gateway.service

  2. mv /opt/ttn-gateway /opt/old-ttn-gateway

  3. cd ~/Installs/rak_common_for_gateway-4.2.3 (git clone of current version)

  4. ./ (install the new version)

  5. cd /opt; diff -ruN old-ttn-gateway/ ttn-gateway/ > patchfile.patch

  6. Edit that patchfile to remove changes to things I don’t want changed

  7. patch -s -p0 < patchfile.patch and apply to old-ttn-gateway

  8. systemctl stop ttn-gateway.service; systemctl disable ttn-gateway.service

  9. cd /opt; mv ttn-gateway delete-this-eventually; mv old-ttn-gateway ttn-gateway

  10. cd /opt/ttn-gateway/packet_forwarder; make clean; make

  11. systemctl enable ttn-gateway.service; systemctl start ttn-gateway.service

Hello @hdtodd, Nice to see you again!

This is the upgrade log of rak_common_for_gateway, We can see that they did not update the lora function, but added some support for the new lora module.
For RAK2245, V4.2.0 and V4.2.3 are almost unchanged.

2020-08-06 09-23-34

Hi, @ZhuQI!! Thanks for the quick response (and all your help getting me going this Spring).

I’ll check that log carefully and only upgrade the files that affect the work I’m doing.

But in the long term, this need to upgrade my code base at some time in the future is likely to still be a problem.

I’ve thought of another approach. I’ll try it out and post again if it seems to work.

But at this point, there doesn’t seem to be an easy way to do this. Nothing as simple as

sudo apt-get update; sudo apt-get upgrade


git pull

Or maybe look at extracting / backup your config, upgrade to the latest & greatest version, put your config back?


I’ve made some changes to the source code for the gateway, and I’ll be making some more. I’m trying to figure out if there’s an easy way to preserve my configs, apply RAK patches to the code base (e.g., 4.2.0 --> 4.2.3) and then apply my changes over those, recompile and install, and restore my config files. The RAK install process (git clone, ./; resulting production system in /opt) complicates things.

The RAK code seems pretty stable, but I expect there will come a time when I’ll need to install an upgrade. I thought that successive diffs and patches from the install tree might do it, but I haven’t worked through it yet. I was trying to work through the process before I make many more changes in the base code.

I’m increasingly thinking that this will be a manual process.

At some point in the next couple of months I will be looking at the upgrade path - which I’m anticipating will be mostly about preserving the config and allowing the newer code base to overwrite the older (after a backup). The gateway is relatively stateless, that is, it doesn’t need to hold information like the last frame counter or any of the keys, so I see no reason why this wouldn’t work out.

In the meanwhile, I’m just doing the equivalent of a new install.