We did implemented this update method on our current system, and we see that it helps a lot. With a mobile device as ours, the connection is not stable at all and suddend disconnections are normal.
Could you elaborate on this point. Do you have another update method alongside Torizon Cloud?
Additionally, with torizon updates being likely bigger than a yocto optimized image update this “never ending update” it’s even more likely to happen.
I’m not sure what you mean by Torizon updates being bigger than a Yocto image. When the OS/filesystem is being updated via OSTree it should only need to download the differences between what is on the device and what is on the server. Unless the difference is 100%, which is unlikely in practical scenarios, you’re never going to be downloading an entire image worth of data.
This amount of data is even further reduced if you make use of static deltas: Signing and Pushing Torizon OS Packages to Torizon Cloud | Toradex Developer Center
Do you think that a sort of caching is technically possible?
Is it something we could developed as standalone service … And then feed the Aktualizr with a local registry or so?
I wouldn’t say it’s “impossible”, but we’re not talking about trivial work and changes to our current update framework. The reason I suggest initial testing in this case, is that we may be going down a road that will require non-trivial amounts of time and effort for a potential problem that hasn’t been analyzed yet.
To give further context, the link I shared here before: Aktualizr - Modifying the Settings of Torizon Update Client | Toradex Developer Center
We’ve tested these configurations before with a low-bandwidth non-stable connection modem that had download speeds around 10kB/s. So far from an ideal network connection. Via the documented configurations we set a timeout period of about 1hr. We then performed several OSTree based update tests where the size of the update ranged from around 100-200MB. In one test where the connection was particularly bad, the update took around 16hrs, but it still succeeded.
Keep in mind the timeout configuration is for each individual curl
request during the download process. During which most errors will trigger OSTree to retry the current download chunk it is on. So with a high enough timeout set, in theory the device will keep retrying download during the update.
I think it’s worth it to try our current solutions to see if they can already satisfy your use-case. If we see that these can not solve your potential problems, then we can of course discuss other potential solutions/work.
Best Regards,
Jeremias