On 09/08/2014 09:13, Mike Looijmans wrote:
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.


Agreeing with much you say Mike, I was under the impression that there are block management layers now which will wear level across partitions?

So you could have your read only partition but still wear levelled across the NAND ?

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).



For us on this latest project - and indeed the past few projects - it is a major problem (and cost) if the device is bricked. These devices are not user-maintainable and we'd be sending engineers out around the world to fix.

Not a good impression to make with the customers either.

Whether we're a usual use case I don't know.

Cheers,

Alex

--

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.