OTA Mechanism

[FlorentRevest]

The current recommended way of upgrading AsteroidOS is by reflashing the entire device from a computer. This has several limitations such as:

• changes are hard to follow and most users tend not to upgrade their watches
• this requires large downloads
• this wipes user's data (some users even reported they made scripts to restore their config after every flash)
• this takes time
• this is simply not a future-proof solution

Hence, a proper upgrade mechanism would be very useful to have. Asteroid already includes the "opkg" manager which could be used to fetch new packages from the nightly build servers's output directory (cf. https://release.asteroidos.org/ipk/ ) However, most watches don't have direct connectivity to the internet and package managers can result in incoherent system states.

The Yocto Project details some of the problems that need to be addressed when choosing an upgrade mechanism for an embedded Linux distribution in this page: https://wiki.yoctoproject.org/wiki/System_Update The proposed solutions can also easily be integrated in OpenEmbedded, which is a plus for us.

However, those solutions usually assume direct internet connectivity while everything we have is USB or Bluetooth Low Energy connectivity.

This task will most likely require a lot of work and has already been discussed for a long time so I decided to postpone it after the v1.0 release.

We should start by investigating what would be the most appropriate upgrade mechanism for Asteroid and then come up with a proof of concept that can be:

• usable on watches without wifi chips
• fast and efficient (can BLE transfers guarantee correct download times?)
• reasonably secure (signed updates?)
• safe (we should avoid breaking everything after an unfortunate update)
• easy to use (not requiring to boot the watch into a special mode or something)

[jrtberlin]

This issue is open for a while now and there are a few new things to consider.

Newer watches tend to have WiFi and could be faster and simpler to update for the end-user:

• A Wifi toggle should be a part of the settings app
• We should make sure that SSH is not available via wifi or only via key file.
• Watches with WiFi could be updated via a "Search for updates" entry in settings that essentially does opkg update and opkg upgrde if the user decides to install the updates.

A few thoughts on watches without WiFi:

• An option in settings to configure a default gateway and DNS as described in our documentation
• Then we can use the same "Search for updates" entry in settings as for the WiFi-enabled devices.
• On non-WiFi devices "Search for updates" should display how to configure the PC when no internet access is detected.

Updates via Bluetooth: The simplest option would be to forward network connectivity to the watch via Bluetooth. This is probably slow and using this feature should notify the user to put the watch on the charger during the process.

About the mentioned checklist:

• usable on watches without wifi chips
  • check
• fast and efficient
  • for WiFI devices and a small comfort improvement for non-WiFi devices
• reasonably secure (signed updates?)
  • Are the nightly packages signed?
  • opkg seems to use TLS (we should enable certificate pinning, if not already done)
• safe (we should avoid breaking everything after an unfortunate update)
  • maybe making nightlies an additional option and only rolling out tested releases as a default (Although the last release was a while ago)
• easy to use (not requiring to boot the watch into a special mode or something)
  • check

[FlorentRevest]

I wrote a documentation about about OTA updates for another project at https://pelux.io/pelux-architecture/master/chapters/configurations/software-update-management.html The main reason why we would want an update solution that is not opkg would be to have atomic update. But to be fair this would be a lot of work and at this point anything is better than nothing. I would have favored a "proper" approach a while back, but I now think that opkg would be just fine for AsteroidOS. The problem is indeed how to have IP connectivity or how to retrieve the packages over BLE. I did look into IP connectivity over BLE a while back and this would be a lot of work.