Upgrades and image manifests

[Alexander Larsson]

On Fri, 2007-06-29 at 09:33 -0400, Dan Williams wrote:
> So the manifest you update to is an interesting piece, and it's easier
> because where you get it from is completely orthogonal to the update
> process.  So, you could:
> 
> 1) as others have suggested, XO periodically contacts the school server
> 2) XO sends it's current image, asks what to update to, if anything
> 3) school server makes policy decision about update
> 4) school server sends back new manifest
> 5) XO verifies manifests signature
> 6) XO downloads changesets
> 
> This is cool, because it doesn't matter _where_ you get the changesets
> from, be it the school server (which should be seeding the changesets
> anyway), or from another XO.  It optimizes for bandwidth, but not at the
> expense of any security.  You already know what changesets are valid
> based on the signature-verified server-provided manifest, and on the
> self-verifying sha1 of the changesets that anyone can provide to you.  
> 
> All in all, simple, straightforward, and not very much code.

Yeah, its quite flexible. One can upgrade between any two images
(forwards, backwards, cross images, etc). 

I've got the code mostly working now, and I managed to update a qemu
instance of build 406 to the devel build 406 using something like:

./updatinator.py -u http://10.x.y.z/updates --get-manifest olpc-ext3 406
./updatinator.py -u http://10.x.y.z/updates -i -m manifests/olpc-ext3.406 --download olpc-devel-ext3 406
./upgrade-manifest -b blobs/ -d /  manifests/olpc-ext3.406 manifests/olpc-devel-ext3.406

Where http://10.x.y.z/updates is an apache server with manifests and
blobs generated with generate-manifests from the -tree OLPC images.

However, then things failed when I upgraded to olpc-devel-ext3.445, due
to out of diskspace. I need to look into using gzip of blobs and
removing blobs once they have been applied (this is harder than it
sounds because blobs can be used multiple times in one manifest).