update mechanism for new releases

Alexander Boström abo at stacken.kth.se
Tue Jun 23 16:35:31 EDT 2009

Den 2009-06-23 20:01, Daniel Drake skrev:

> Even though olpc-update isn't great for doing big distro updates
> (because of storing 2 copies of changed files, in this case almost all
> of them), it worked in those situations. I've never attempted an
> RPM-based update from e.g. Fedora 10 to Fedora 11.

Preupgrade+Anaconda would be better.

The big question with yum updates and Anaconda upgrades is how to do it 
safely. The system must remain bootable at all times.

It would be neat (perhaps required?) if Anaconda upgrades would do a 
transaction-type upgrade, where you have the option to roll back if 
something goes wrong in the middle. People keep asking for that for 
regular yum updates, but that's not really possible since you can't roll 
back a generic running system. (How do you roll back the OS without also 
rolling back /var/lib/mysql and /home at the same time? No thanks.) With 
Anaconda, you know nothing else is running alongside the upgrade so if 
you have a snapshot mechanism for the filesystem or block device then 
maybe it would be possible...

> "yum update" has historically not worked very well on the XO. It hits
> OOM, it fills up yum's cache and then aborts, it gets confused between
> i586 and i686, etc.

This option would certainly requires lots of testing to make sure it 
works well.

> It introduces new questions of security, signing, etc. Deployments will
> want to sign their rpm updates that they push out, so we now need a

Maybe olpc-update can be extended to manage /etc/pki/rpm-gpg/ and rpm 

> For the XO-1 possibility it raises the question of how existing laptops
> could be migrated to this new system, without losing their user data.

Use olpc-update to push a new image that contains preupgrade?


More information about the Devel mailing list