[yocto] RFC: Improving the developer workflow

[Alex J Lennon]

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