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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
