XO in-field upgrades

[Alexander Larsson]

On Tue, 2007-06-26 at 17:47 -0400, Mike C. Fletcher wrote:

> I may be missing an operation or two in there, but I *think* that's the 
> intention.  That is, there's an ultimate loading level that sits outside 
> the standard root to make it all work.  That loading level could be in 
> the BIOS or on an initrd, but there does need to be a level to manage 
> the ultimate overlay-based structure AFAIK.  And at normal boot, 
> something has to set up the overlays, regardless of what overlay set is 
> loaded.  That level of access is where the update manager has to sit to 
> be able to do the updates AFAICS.  That is to accomplish a merge or 
> remount of the core fs we need a way to ask the overlay manager to do 
> some work for us at the update-manager level.

Oh I see. So, you update the root, but you can't update all the system
software (like the part that does the switching between roots).

In such a setup, how do you update e.g. the kernel?

> (how does that 
> work for soft links, incidentally, I gather you recreate them rather 
> than hard-linking?)  

They are recreated, same with fifos, directories, and device nodes. At
least this is how update-manifest in updatinator does it, but I don't
think there is any other way really.

With update transaction on the filesystem level (like my jffs2 proposal)
this kind of "outer" manager is not needed. However, with an outer
controller I can see this working. One could even use symlinks to make
this pretty simple:

/rootfs/olpc.5 [contains image version 5]
/rootfs/olpc.6 [contains image version 6, shared hardlinks with olpc.5]
/rootfs/current -> olpc.6 [a symlink]
/rootfs/previous -> olpc.5
/usr -> /rootfs/current/usr
/var -> /rootfs/current/var
/etc -> /rootfs/current/etc

Then, to upgrade almost atomically, one just does:
clone_w_hardlinks (/rootfs/olpc.6, /rootfs/olpc.7)
apply_changes (/rootfs/olpc.7)
ln -sf /rootfs/olpc.6 /rootfs/previous [1]
ln -sf /rootfs/olpc.7 /rootfs/current [2]
rm -rf /rootfs/olpc.5

A power failure during [1], or between 1 and 2 can mess up the
"previous" link, and since symlink isn't an atomic operation if the file
exists a failure during [2] can cause "current" to disappear. However,
we will never have both "previous" and "current" missing.

Using symlinks like this means the jffs2 parser in the firmware (if it
supports symlinks) will even be able to pick up the right kernel.
(Although it will always pick the "current" kernel.)

There is one tricky area with hardlinks though. All hard links of the
same inode share the permission and other metadata with each other. What
if the trees have different metadata for the same file? Or what if
running the "current" image changes metadata for a file shared between
the images?

Hmm, i guess any kind of in-place change to the hardlinked files while
running the image is also mirrored in the other image. I guess this is
where the COW stuff is needed... I guess this means the /usr
-> /rootfs/current/usr symlinks don't cut it, but one needs something
heavier, like overlays or vserver+COW. Sad, it was an interesting idea.