4 ms·

That's true. I'm currently also involved in the development of an embedded linux project for which we yet have to find out the perfect update story. We thought

That's true. I'm currently also involved in the development of an embedded linux project for which we yet have to find out the perfect update story. We thought about replacing individual packets too, but it looks like a hard way from various perspectives: - Build system: Would need to figure out how to build all these packets (with their requirements) in a reliable way. - Deployment: Deployments should be reproducable. All devices should get the same version of all subcomponents. And a rollback to an older version (with older versions of subcomponents) should be possible. Having some devices floating around with untested configurations (because the device decided to update on package but not the remaining ones) is not desirable, because you want to only handover fully tested/qualified software versions to the customer. Building the whole RFS at once, storing it and flashing it at once currently seems like the way to go. Will take a look at mender if it could help.

jononor 10y ago
Yes, I did package-based updates on a embedded system (not enough time to go dual-RFS), and it was painful. The statefulness of such update means that all transition paths must be tested for each release, which adds up very quickly. This effectively reduced how often and how timely we shipped updates. Package systems are also quite fragile, ie if a post-trigger/script fails the package install fails. And sometimes not cleanly either, where the partially-installed package blocks install of a new fixed package. In the worst case the system is left in an in-between broken state.
karmicthreat 10y ago
I'm kind of in this boat now with a couple of products. The catch is I need to do both local and OTA updates. This seems to be a rare feature that nobody is doing. I also am trying to get Resin.io like containers working. It seems like it would be an easier way to test and deploy.
- Matthias247 10y ago
  That's also a requirement for me - local updates (via connected USB stick, triggered via reboot or web interface) should work also in addition to OTA. _In fact local updates would have an even higher priority. We fiddled around also a little bit with the container route. I liked it for quick iteration times (rebuild a docker container, pull it from local image registry to device and test it there). But we found out that we won't get by with just container updates, and that most updates would also need to contain a new kernel or kernel module versions.
  - eystein 10y ago
    It is not that uncommon for an updater to support both local and remote updates. For example, Mender has two modes of operation: standalone and managed [0]. Like you, many teams are still doing local updates, or transitioning from local to OTA, at least for some products. [0] https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation https://docs.mender.io/1.0/Architecture/Overview#modes-of-op...
- deleted 10y ago
  [deleted]

jononor 10y ago

Yes, I did package-based updates on a embedded system (not enough time to go dual-RFS), and it was painful. The statefulness of such update means that all transition paths must be tested for each release, which adds up very quickly. This effectively reduced how often and how timely we shipped updates. Package systems are also quite fragile, ie if a post-trigger/script fails the package install fails. And sometimes not cleanly either, where the partially-installed package blocks install of a new fixed package. In the worst case the system is left in an in-between broken state.

karmicthreat 10y ago

I'm kind of in this boat now with a couple of products. The catch is I need to do both local and OTA updates. This seems to be a rare feature that nobody is doing. I also am trying to get Resin.io like containers working. It seems like it would be an easier way to test and deploy.

Matthias247 10y ago
That's also a requirement for me - local updates (via connected USB stick, triggered via reboot or web interface) should work also in addition to OTA. _In fact local updates would have an even higher priority. We fiddled around also a little bit with the container route. I liked it for quick iteration times (rebuild a docker container, pull it from local image registry to device and test it there). But we found out that we won't get by with just container updates, and that most updates would also need to contain a new kernel or kernel module versions.
- eystein 10y ago
  It is not that uncommon for an updater to support both local and remote updates. For example, Mender has two modes of operation: standalone and managed [0]. Like you, many teams are still doing local updates, or transitioning from local to OTA, at least for some products. [0] https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation https://docs.mender.io/1.0/Architecture/Overview#modes-of-op...
deleted 10y ago
[deleted]