Peru Upgrade process.

[C. Scott Ananian]

On Sat, Jun 7, 2008 at 12:57 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> I don't really know enough to comment correctly on this debate, but it
> sure seems like the much-maligned USB autoreinstallation system meets all
> the requirements.  It is non-interactive, beyond requiring a reboot, and
> it preserves the user's data by copying off the contents of /home/olpc,
> performing the upgrade, and then copying back the contents of /home/olpc.

http://dev.laptop.org/ticket/3880

No one has done the required work in the 8 months since this was
initially discussed, dwmw2 no longer works for us to hack on
mtd-utils, and the solutions Michael and I have discussed to address
the problem in 8.2 won't help the machines with 656 and 703 already in
the field.

I'm also a little cranky because when we fought over this last time it
was argued in elevated voices that we simply *couldn't* have any
system which required manually plugging a USB key into every machine,
because the manual labor was too high, we couldn't supply that number
of USB keys, etc, etc.  So I implemented a rather nice system for
doing network upgrades.  Now I'm being told that we can't possibly do
network upgrades, etc, etc.

People seem to be viewing the autoinstallation key with rosy glasses
at the moment, but I had to support it at the time, and trust me, that
mechanism was just as derided for being overly complicated.  (Just
take a look at http://wiki.laptop.org/go/Autoreinstallation !) Having
to transition from linux (for backup) to OFW (for reflash) to linux
(for restore) was very fragile and error-prone.   I have partial code
to do the whole process from w/in a linux ramdisk w/o rebooting into
OFW, but properly doing the reflash required hacking nandwrite from
mtd-utils to understand something like the fs.zip format, and I never
got any help on that.  I think someone was recently working on
upcalling into OFW from within linux?  Is that a workable solution?

Some options:

a) For 656, we can probably package a little Pippy application on a
USB key that will invoke os.system('sudo olpc-update --usb').  That
will make the olpc-update mechanism a point-and-multiple-click
process.  I hope to have an "Update" activity for 8.2 which will
handle this in a similar way, but my time is not unlimited.

b) I'm trying to get partition support for 8.2, which would let us use
the 'secure reflash' process to rewrite just the root partition,
leaving /home untouched http://dev.laptop.org/ticket/616 .  This would
also answer wad's concerns for the future.  Upgrades from an
unpartitioned to a partitioned layout would still be a bitch.

c) provide clear well-written instructions for using the existing &
tested process.

d) In order to sign the existing autoreinstallation script, one would
at a minimum need to upgrade the olpc.fth to do the same validation on
the linux image from USB that secure boot does, so the the
autoreinstallation key couldn't be used to bypass initial activation.
(Mitch could probably help with this.) The autoreinstallation script
also kept a permanent backup of the user's content, which was a
Feature (in that it's still the only backup mechanism we had/have),
but a Bug (in that the USB key eventually filled up and then no more
upgrades could occur unless you emptied it).  That would need to be
addressed.  Finally, if you really want this for foolproof 656->703
updates, autoreinstallation would have to be combined with the
customization key code to install activities.
  --scott

-- 
                         ( http://cscott.net/ )