[yocto] update mechanisms

[Patrick Ohly]

On Fri, 2017-03-10 at 14:35 +0100, Kristian Amlie wrote:
> On 10/03/17 14:02, Patrick Ohly wrote:
> > On Wed, 2017-03-01 at 16:35 -0800, Eystein Måløy Stenberg wrote:
> >> On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote:
> >>> On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
> >>>> Hi Patrick,
> >>>>
> >>>> On 30/11/2016 15:59, Patrick Ohly wrote:
> >>>>> I've started a Wiki page
> >>>>> https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
> >>>>> moment, but might as well be mentioned already now.
> >>>>
> >>>> I have seen Mariano added an entry for SWUpdate, too, thanks  - I would
> >>>> like to edit for better explanation on some parts. Should I try to edit
> >>>> directly the page or is it better to discuss it here ?
> >>>
> >>> Use your own judgment. If its uncontroversial, the feel free to edit the
> >>> page directly, otherwise let's discuss it here.
> >>>
> >>> If feel that putting information directly into the table is too limiting
> >>> (it should be brief), then feel free to start a complete section about
> >>> SWUpdate.
> >>>
> >>> I'll do the same for swupd. Editing the sections should be possible
> >>> without conflicts, we just have to be more careful about editing the
> >>> table concurrently.
> >>
> >> I updated the Mender part of the wiki now that the stable version Mender 
> >> 1.0 is released. These changes should not be controversial, but let me 
> >> know if you disagree. We are planning to keep the Mender section 
> >> up-to-date as we release new versions, as I think this is what you expect.
> > 
> > Yes, that's useful.
> > 
> >> Are there any plans for next steps or is the wiki the "final state" in 
> >> terms of integrating OTA updates in Yocto/OE?
> > 
> > My own conclusion is that it is impossible to integrate a specific OTA
> > update into Yocto/OE (because there's no single solution that fits all
> > requirements) and/or it would be unfair to those solutions that don't
> > get such special testing. In that sense the Wiki page is the final
> > result of the investigation. Anyone interested in picking a solution can
> > go there, consider the pros and cons, and then make a choice.
> 
> Makes sense. We can always revisit this at a later point, if one method
> starts to emerge as the preferred option for most people.
> 
> > However, I see room for some collaborative work that then can happen in
> > Yocto/OE:
> >       * carrying local system configuration changes across system
> >         updates: I find it promising to investigate the "stateless"
> >         concept and have started some exploratory work, see
> >         https://wiki.yoctoproject.org/wiki/Stateless#Status_and_goals_for_.22stateless.22_in_Yocto (more on that soon)
> 
> What's the relation (if any) between this and a read-only rootfs?

/etc needs to be on the read/write partition. What "stateless" adds is
that there's no need to pre-populate that read/write part. That is done
during first boot, potentially even during each boot (no persistent
state at all).

In addition, factory reset can be done by simply wiping out /etc.
When /etc contains a mix of pre-populated files which are essential for
booting and local modifications which must be wiped out, that part
becomes harder.

In an ideal world, the OS would work entirely without files in /etc. We
don't live in that world (yet).

> Also this may be only vaguely related, but I have it in my queue to
> finish the built-in partitioning of rootfs images [1], which will help
> divide the filesystem into a stateful and a stateless part. The wic part
> is done [2], but ext4 images are not covered yet.

This is still useful, for example to pre-populate content than then
never gets touched anymore by the OS. I'm thinking of pre-installed apps
here, where app update/add/remove is done normally done independently of
the OS.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.