update mechanism for new releases

[Martin Langhoff]

On Tue, Jun 23, 2009 at 8:01 PM, Daniel Drake<dsd at laptop.org> wrote:
> Any other thoughts/opinions one way or the other?

My (also inconclusive) thoughts on this. I dislike using a bespoke
update method profoundly and discussed this topic at length with
Scott.

The main point, where olpc-update wins without a shadow of a doubt, is
failure-friendliness. Assuming a fail-safe filesystem, olpc-update can
be interrupted (hard) at any point, might take N runs to complete. And
will only switch to the 'new' image once it's completed in an atomic
operation.

RPM is unfortunately a disaster in this space. If an rpm transaction
fails, there are no sane ways to recover it. On XO-1 a full OS update
transaction with rpm  will take a very long time, so it's highly
likely that it will be interrupted. RPM and yum hackers treat this as
an intractable problem.

There may be ways to make it a bit less bad (dpkg seems to handle
recovery quite a bit better, but surely will have unrecoverable
scenarios too) but it is a long hard road, and the shadow of a
significant % of failed upgrades remains.

This is, IMO, the actual showstopper. If we had a fs that could handle
snapshotting, then we could snapshot the system before starting the
RPM transaction, and have recovery hooks in the boot partition or in
initrd. There's been discussion on fedora-devel about hooking up yum
with btrfs transactions

A few other notes  -- for completeness:

 - Upstream has not historically supported yum-based upgrades, only
anaconda upgrades. Yum OS upgrades are a relatively new (and risky)
thing. We could have an 'anaconda boot' partition to handle upgrades
without external media.

 - Disk space requirements for olpc-update vs yum/rpm are probably
similar, and I suspect that during the upgrade rpm transaction the
footprint is larger for the rpm methods. We could teach olpc-update to
jettison the old image as soon as the new one boots successfully...

 - olpc-update completely sidesteps %pre and %post scripts -- this is
potentially a problem.

 - olpc-update offers downgrades, but our software at higher layers
doesn't support this. The Journal format upgrade broke downgrades in
the last OS upgrade. Sugar 0.84 has another Journal format change,
probably with a similar upgrade-only path.

 - deltarpm-style tools are of little benefit for a whole OS upgrade.
as there is little or no overlap between releases. Where there is
overlap, then olpc-update's hardlinking strategy is also a win of
similar proportions. Deltarpm-style tools usually force you to keep
around the original rpm as well.

 - olpc-update-query needs to be changed to retry more aggressively
once it has received an "upgrade now" message from the OATS. It's in
my TODO list...

hth,



martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff