Offline-First Update System for School and Clinic Device Fleets on Poor Connections

The problem: updating devices where the internet barely works

NGOs, school networks, health programmes and retail chains increasingly place small Linux devices in the field: learning kiosks in government schools, registration terminals in basic health units, digital signs and point of sale boxes in small shops. In much of rural Pakistan and similar regions, these sites have slow mobile data, monthly data caps, frequent power cuts and sometimes no connection for days.

Updating these devices is a constant struggle. A full system image may be hundreds of megabytes, which burns the data budget and fails halfway. Ten devices at one school each download the same update. A failed update can leave a device unbootable, hours from the nearest technician. Many programmes give up and leave devices on old, insecure software.

What already exists and the gap

• Mender, balena and RAUC provide robust over-the-air updates for embedded Linux with A/B partitions and rollback; some offer delta updates. They generally assume each device reaches a server.
• OSTree versions whole filesystem trees and supports static deltas for offline use.
• casync combines rsync-style chunking with content-addressed storage to distribute images efficiently.
• Rugix and SWUpdate are further open source update engines for embedded Linux.

The gap is the combination needed in the field: chunk-level deltas, sharing between devices on the same site so the update crosses the slow link once, a USB fallback for sites with no connection, strict data budgets and resumption, all with the safety of A/B rollback.

Inspiration

Andrew Tridgell's PhD thesis "Efficient Algorithms for Sorting and Synchronization" (Australian National University, 1999) introduced the rsync algorithm for efficiently updating files over slow network links by exchanging block signatures. Lennart Poettering's casync built on that idea with content-addressed chunk stores for distributing filesystem images. This project applies those ideas to a fleet where many devices share one poor link and some have no link at all.

What you build

• Programme technicians publish an update once from the console.
• At each site, one device fetches the missing chunks within the data budget, others fetch from it over local Wi-Fi or Ethernet, and every device applies the update to its inactive partition.
• Field staff carry a USB stick to sites with no connection; devices verify the signature and update.
• If a device fails to boot, it rolls back by itself and reports the failure next time it is online.

The technically interesting part

• Chunking and deltas. Content-defined chunking means a small change produces few new chunks. Measure how much each type of change (a new package, a kernel update, an app change) actually costs in transfer, and tune chunk size.
• Local peers. Discover peers with mDNS, fetch chunks from peers before the internet, verify every chunk by hash so a compromised peer cannot inject anything, and elect which device uses the slow link.
• Disconnection as the norm. Downloads resume chunk by chunk across days. The console must cope with devices that check in weekly and show "last known state" honestly.
• Trust. Updates are signed; devices verify signatures for internet, peer and USB paths alike.
• Safe switching. Apply to the inactive partition, switch, run health checks after boot, and roll back if they fail or the device does not come up.

How to evaluate it

• Data used: bytes over the slow link per site update, compared with full image downloads and with each device downloading separately.
• Success under bad links: throttle and randomly cut the connection; measure completion time and failures.
• Rollback: deliberately ship broken updates and confirm every device recovers.
• USB path: time and steps for a non-technical person to update a site with a stick.

Suggested plan

• Weeks 1 to 4: A/B updates with an existing engine on two Raspberry Pis; try casync.
• Weeks 5 to 10: device agent with chunked, resumable downloads and data budgets.
• Weeks 11 to 15: peer discovery and sharing; first throttled test.
• Second semester: USB bundles, signatures, console, rollback testing, the six-device evaluation and the write-up.

Who it is for, concretely

A programme running 300 learning kiosks across 60 village schools, each site on a prepaid mobile data package, with two technicians who visit each school a few times a year. Today an update means a technician visit; with this system it means one small download per site.

Path to a product

Organisations running device fleets in low-connectivity areas, from education programmes to retail distributors, need exactly this, and few existing products target them. An open source core with paid hosting and support for programme operators is a credible model.

Scope warning

Build on an existing A/B update engine; do not write bootloader logic from scratch. Start with whole-image updates for one device type. Containers and staged rollouts are stretch goals.

Learn what you need on Sefism

• Embedded systems and IoT roadmap: Linux devices, boot and field deployment.
• Embedded systems and IoT cheat sheet: device concepts in one place.
• DevOps and cloud roadmap: release pipelines and rollouts.
• Beej's Guide to Network Programming: sockets for peer sharing.
• Operating Systems: Three Easy Pieces: filesystems and crash consistency.

Get help with this idea

The risk is trying to solve every part at once. Tauseef can help you pick the update engine, order the work so each semester ends with something that runs, and design the throttled-link tests. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session