[yocto] [OE-core] RFC: Improving the developer workflow

[Tim O' Callaghan]

Hi,

Another approach I would like to suggest is the one that CoreOS has in place, that they call fastpatch. 

https://coreos.com/using-coreos/updates/

Essentially two root partitions, and boot to switch between the new image while leaving the old one intact as the last known good. It avoids the complexity of an overlay, and it fits with the current yocto filesystem image based approach. With this approach, forward/backward application configuration compatibility can be maintained with an extra bbclass to mix in to the recipes of local application configurations based on OS release version, so that they can be updated by the init scripts.

Tim.

-----Original Message-----
From: openembedded-core-bounces at lists.openembedded.org [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of Alex J Lennon
Sent: vrijdag 8 augustus 2014 17:58
To: Paul Eggleton
Cc: yocto at yoctoproject.org; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [yocto] RFC: Improving the developer workflow

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 at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core