Hi Paul, > Personally with how fragile package management can end up being, I'm > convinced > that full-image updates are the way to go for a lot of cases, but ideally > with > some intelligence so that you only ship the changes (at a filesystem level > rather than a package or file level). This ensures that an upgraded image on > one device ends up exactly identical to any other device including a newly > deployed one. Of course it does assume that you have a read-only rootfs and > keep your configuration data / logs / other writeable data on a separate > partition or storage medium. However, beyond improvements to support for > having a read-only rootfs we haven't really achieved anything in terms of out- > of-the-box support for this, mainly due to lack of resources. > > However, whilst I haven't had a chance to look at it closely, there has been > some work on this within the community: > > http://sbabic.github.io/swupdate/swupdate.html > https://github.com/sbabic/swupdate > https://github.com/sbabic/meta-swupdate/ > >
I had a quick look at this. It's interesting. If I am reading this correctly it's based on the old -> Bootloader runs Partition A -> Update Partition B, set Bootloader to run Partition B -> On failure stay on partition A and retry update. -> Bootloader runs Partition B -> Update Partition A, set Bootloader to run Partition A -> etc. We've done this type of thing before and it works well. Of course the drawback is the amount of flash you need to achieve it but it is a good robust system. I'd be interested to see how this could work with filesystem deltas say. I don't _think_ that is documented here? ... Thinking a little further what would also really interest me would be to consider using the transactionality of the underlying file-system or block-management layer for the update process. Given nowadays journalling and log-structure file-systems are already designed to fail-back when file/meta-data modifications are interrupted surely we should be able to start a macro-transaction point at the start of the partition update, and if that update doesn't complete with a macro-commit then the f/s layer should be able to automatically roll itself back? Perhaps the same could be done at a block management layer? Cheers, Alex -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
