Re: [yocto] RFC: Improving the developer workflow

[Mike Looijmans <mike.looijmans@topic.nl>]

On 08/07/2014 03:05 PM, Paul Eggleton wrote:
> On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
>> Historically I, and I suspect others, have done full image updates of
>> the storage medium,  onboard flash or whatever but these images are
>> getting so big now that I am trying to  move away from that and into
>> using package feeds for updates to embedded targets.
>
> 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.

Full-image upgrades are probably most seen in "lab" environments, where 
the software is being developed.

Once deployed to customers, who will not be using a build system, the 
system must rely on packages and online updates.

Embedded systems look more like desktops these days.

- End-users will make changes to the system:
	- "plugins" and other applications.
	- configuration data
	- application data (e.g. loggings, EPG data)
- There is not enough room in the flash for two full images.
- There is usually a virtually indestructable bootloader that can 
recover even from fully erasing the NAND flash.
- Flash filesystems are usually NAND. NAND isn't suitable for read-only 
root filesystems, you want to wear-level across the whole flash.

For the OpenPLi settop boxes we've been using "online upgrades" which 
basically just call "opkg update && opkg upgrade" for many years, and 
there's never been a real disaster. The benefits easily outweigh the 
drawbacks.

When considering system upgrades, too much attention is being spent in 
the "corner cases". It's not really a problem if the box is bricked when 
the power fails during an upgrade. As long as there's a procedure the 
end-user can use to recover the system (on most settop boxes, debricking 
the system is just a matter of inserting a USB stick and flipping the 
power switch).



-- 
Mike Looijmans