Sysupgrade

As it happened, Attended Sysupgrade with the latest version of OpenWrt 25.12, since it became the default approach to update OpenWrt devices, started seeing a spike in popularity.

When I first tried this, I was either 1st in the queue or just a few users behind. Days later, when the next version (25.12.1) was released, this jumped to around 200-300. Now, with another release (25.12.2), the servers cannot handle it anymore.

Server response: server overload, queue contains too many build requests: 1001

Following a discussion with one of my visitors, it was suggested that I use someone else’s server for Attended Sysupgrade, but there is always a catch to that. The recommended server uses SNAPSHOT builds as default, which I do not recommend for a production or business environment. While you can play with it on a home router, in business, you need to rely on stability.

I have been thinking that maybe I will create my own server for that purpose. I already have a small mini-PC at home (and at work) — a Chromebox repurposed as an Ubuntu Server running Docker. My usage is not massive, and there is plenty of computing power available.

I should have discovered this years ago!

I never came across this feature, and it was apparently available a few versions ago. Just now, when version 25.12.0 was officially released, I learned how to simplify upgrading from one version to another (I did this from 24.10.2 to 25.12.0).

I have developed my own routine for backing up packages and configuration files, installing a new image, and restoring everything. To be honest, I always hate doing that, especially in a business environment, as it always requires some downtime. This is why I sometimes fall behind on some sub-versions of OpenWrt firmware (I was still on 24.10.2 instead of 24.10.5).

When you cannot afford extended downtime, you can minimise it with this approach: Attended Sysupgrade (ASU).

In the past, I have followed a method of updating OpenWrt devices with an option to restore all installed packages and their configurations without needing to spend hours on reconfiguring and testing everything.

This method uses a simple script run in the terminal to generate a list of installed packages, followed by a web interface to generate a backup file used to restore everything.

As long as the backup file is generated correctly, the restoration process works well, but the problem arises when it isn’t!

On several routers with OpenWrt (24.10.x) that I worked with over recent weeks, I experienced a strange issue that caused me to rethink how I generate a backup file to later use to restore all packages and settings after updating OpenWrt to the latest version.

I discovered this issue the hard way when I wanted to extract a backup to retrieve some configuration from individual files. I noticed that the backup failed to extract correctly.