XO in-field upgrades

[Alexander Larsson]

On Sun, 2007-06-24 at 13:24 -0400, C. Scott Ananian wrote:
> On 6/24/07, Ivan Krstić <krstic at solarsail.hcs.harvard.edu> wrote:
> > I should have a concrete spec ready for discussion later today.
> 
> I will wait with bated breath. =)
> 
> Some concrete concerns -- I've got some answers to these, but I'll try
> to just present the questions at this point:
>   a) Robustness -- what can break our upgrade mechanism?  Do we have a
> fallback?  What dependencies does the upgrade mechanism have?
>   b) Current vserver code requires restarting the containers when
> files inside the container are modified by the root context.  There is
> also a relinking process necessary.  Have we thought through these
> interactions?

I haven't really seen a viable way to use vserver for updating the root
filesystem. Is there a proposal for how this would work? 

I had a different idea to do a very robust root filesystem update. Given
the layout and format of jffs2 (the filesystem we're using) it is very
easy to add filessystem transaction support. That is, we'd have a way to
trigger a transaction at the start of an update, then we just do all the
changes we want (including just updating the kernel image file). Then
when the update is done, we commit the transaction. If at any time we
lose power or anything like that, none of the changes after the
transaction start will be visible on the next boot. And also, if we have
any problems during update (e.g. out of flash) we an rollback and abort.