159 karma · joined January 25, 2017
The Yocto Project is a popular build system for your own embedded Linux distribution.
Mender integrates with the Yocto Project with a layer (https://github.com/mendersoftware/meta-mender), but is a separate project for end-to-end OTA, which includes the client and the management server. Both are licensed under Apache 2.0 thus it is freely available and you're not locked into a hosted-only backend.
Although this is an older blog post, here is how you can port the Mender client to a non-Yocto build system: https://mender.io/blog/porting-mender-to-a-non-yocto-build-s...
We had looked into OSTree before but given the use case of embedded devices in the wild, we concluded it was too risky as OSTree relies on the filesystem to protect from power failures. And rollback was not built-in and is quite challenging to implement reliably.
>>> without the lock-in
>> Anyone know more precisely what he's talking about? The article doesn't specify.
Apologies for the confusion, yes I had meant vendor lock-in. That is usually a blocker for many embedded projects starting out. This is why we've created a open source project with both client and management server licensed under the permissive Apache 2.0.
If you are interested, we are always looking at ways to improve our project and if you'd like to participate in a one hour user test, we conduct those over Google Hangouts:
We have looked into hardware watchdog for this, but it is in the gray-zone of what an updater should be involved in. This is actually a more generic problem - maybe it hangs even when you did not deploy an update. There is varying support for hardware watchdogs across boards as well, unfortunately.
Most of the time it will not just hang, maybe it will crash or kernel panic and in those cases Mender will rollback. But the indefinite-hanging case is quite tricky and not yet handled.
Would be open to ideas here.
We have been evaluating OSTree as a potential building block for Mender, however the key challenges we've come across:
integrating OSTree into an existing device/OS seems quite invasive - https://ostree.readthedocs.io/en/latest/manual/adapting-exis...
block level signatures is not possible, which we feel is a requirement for an over-the-air updater
rollback is not built-in and can be quite challenging to implement reliably (bootloader level)
Think OSTree as more of a building block, like Git is for your development process. We might use it in the future but robustness and easy integration are our first priorities.