This project intend to simplify the sysupgrade process of LEDE/LibreMesh. The provided tools here offer an easy way to reflash the router with a new release or package updates, without the need of opkg installed.

Add a view to the Luci system tab called "Attended Sysupgrade". Offers a button to search for updates and if found, to flash the image created by the update server.

Dependencies:

• rpcd-mod-rpcsys Used to read list of installed packages and trigger sysupgrade on the target.
• uhttpd-mod-ubus Communication between the Browser and the Router
• cgi-io Upload image from Browser to Router

Add CLI to perform sysupgrades.

Dependencies:

• rpcd-mod-rpcsys Used to read list of installed packages and trigger sysupgrade on the target.
• usteam-ssl and ca-certificates Securely communicate and download firmware from server via https

The server listens to update and image requests. Images are auto generated if the requests was valid. LEDE ImageBuilder is automatically setup up on first request of distribution, release, target & subtarget.

All requests are stored in a queue and build by workers.

• planetexpress - thanks @egon0 You can set this server in /etc/config/attendedsysupgrade after installation of a client

Sends information about the device to the server to see if a new distribution release or package upgrades are available. An upgrade check could look like this:

Most information can be retrieved via ubus call system board. Missing information can be gathered via the rpcd-mod-rpcsys package. packages contains all user installed packages plus version. Packages installed as an dependence are excluded as they've been automatically and dependencies may change between releases.

It's also possible to check for a new release without sending packages by removing packages from the request.

The server validates the request. Below is a possible response for a new release:

See other status codes

An release upgrade does not ignore package upgrades for the following reason. Between releases it possible that package names may change, packages are dropped or merged. The response contains all packages included changed ones.

The upgrade check response should be shown to the user in a readable way.

Once the user decides to perform the sysupgrade a new request is send to the server called upgrade request.

The upgrade request is nearly the same as the upgrade check before, except only containing package names without version and adding board and possibly model. While the server builds the requested image the clients keeps polling the server sending a request_hash via GET to the server.

If the request_hash was retrieved the client should switch to GET requests with the hash to save the server from validating the request again.

api/upgrade-request/<request_hash

See other status codes

It's also possible to request to build an image. The request is exactly the same as for upgrade-request. The response only contains a link to the created files or upgrade-request parameters if available.

This is a special case for clients that do not necessary require a sysupgrade compatible image. An example is the LibreMesh Chef firmware builder.

The client should check the status code:

It's also possible to receive information about build images or package versions, available devices and more. All responses are in JSON format.

• /api/image/<image_hash> Get information about an image. This contains various information stored about the image.

• /api/manifest/<manifest_hash> Get packages and versions of a manifest. The manifest contains all installed packages of an image. The manifest_hash can be received by the api call /api/image

• /api/distro Get all supported distros

• /api/releases[?distro=<distribution>] Get all supported releases (of distribution)

• /api/models?distro=&release=&model_search=<search string> Get all supported devices of distro/release that contain the model_search string

• /api/packages_image?distro=&release=&target=&subtarget=&profile= Get all default packages installed on an image