Live data from Hacker News

Mender – An open-source OTA software updater for embedded Linux devices

mender.io

1–10 of 48 posts

Re: Mender – An open-source OTA software updater for embedded Linux devices

#5
post #4

This is kind of a stupid question, but why not just use .rpm/dnf or .deb/apt and a custom repo?

Embedded Linux systems supporting OTA usually employs a dual root file system (RFS) approach where the upgrade is placed onto the currently not used partition and then after successful upgrade the RFS to boot into is replaced.

It is an easy solutions which ensures integrity and has few drawbacks for typical embedded systems.

The output of a typical Embedded Linux CI build is a complete RFS, having to care about individual packages would just be a headache, when you can replace the entire RFS and be done with it.

Re: Mender – An open-source OTA software updater for embedded Linux devices

#6
post #4

This is kind of a stupid question, but why not just use .rpm/dnf or .deb/apt and a custom repo?

Embedded Linux systems supporting OTA usually employs a dual root file system (RFS) approach where the upgrade is placed onto the currently not used partition and then after successful upgrade the RFS to boot into is replaced. It is an easy solutions which ensures integrity and has few drawbacks for typical embedded systems. The output of a typical Embedded Linux CI build is a complete RFS, having to care about indiv…

Exactly. I wish Mender was around 4 years ago. I built exactly this!

Re: Mender – An open-source OTA software updater for embedded Linux devices

#7
post #4

This is kind of a stupid question, but why not just use .rpm/dnf or .deb/apt and a custom repo?

Embedded Linux systems supporting OTA usually employs a dual root file system (RFS) approach where the upgrade is placed onto the currently not used partition and then after successful upgrade the RFS to boot into is replaced. It is an easy solutions which ensures integrity and has few drawbacks for typical embedded systems. The output of a typical Embedded Linux CI build is a complete RFS, having to care about indiv…

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.

Re: Mender – An open-source OTA software updater for embedded Linux devices

#8

Earlier quoted context omitted.

Embedded Linux systems supporting OTA usually employs a dual root file system (RFS) approach where the upgrade is placed onto the currently not used partition and then after successful upgrade the RFS to boot into is replaced. It is an easy solutions which ensures integrity and has few drawbacks for typical embedded systems. The output of a typical Embedded Linux CI build is a complete RFS, having to care about indiv…

Exactly. I wish Mender was around 4 years ago. I built exactly this!

Interesting! How did you go about falling back to an older version if the update was bad? Is there a nice way to do this automatically? Say I update to a really botched version with the kernel panicing before it reaches userland. Does this need manual intervention?

Re: Mender – An open-source OTA software updater for embedded Linux devices

#9

Earlier quoted context omitted.

Embedded Linux systems supporting OTA usually employs a dual root file system (RFS) approach where the upgrade is placed onto the currently not used partition and then after successful upgrade the RFS to boot into is replaced. It is an easy solutions which ensures integrity and has few drawbacks for typical embedded systems. The output of a typical Embedded Linux CI build is a complete RFS, having to care about indiv…

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 reproducabl…

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.

Post reply on HN