olpc-update and deletion of old images

[Michael Stone]

Dan,

First and foremost, your approach seems reasonable to me.

Second, here are some more detailed background comments:

> When olpc-update updates you from version A to version B, version A
> remains on the system and can be accessed by booting with the 'O' game
> key held down.
> 
> As far as I know, this functionality is rarely used, 

The functionality is now rarely used because olpc-update is not used as
frequently as it used to be and because the OS image testing process is working
well enough that the fail-safe functionality has not been required at scale.

Both of these, combined with the costs you mention, seem to me to be fine
reasons for retiring the feature, so long as you think that they will continue
to hold true for the foreseeable future.

> and has inherent problems. Specifically it requires Sugar developers to be
> able to predict the future. For example, if the datastore changes in a newer
> sugar version, the new sugar version will boot and convert the
> datastore to the new format. But if you then boot the old OS version,
> you won't see anything in your journal, since the old sugar doesn't
> support the new datastore format. (similar problems could occur in
> other parts of the system)

These issues were thought to be acceptable when we thought the failsafe
functionality was important and when OLPC and its partners were prepared to
help Sugar develop in both backward- and forward-compatible ways.

They are obviously less acceptable now.

(Also, for what it's worth, we had a couple of plans on the back-burner for
filing down the sharp edges here. As I recall, they included:

    a) introducing a plugin system for olpc-configure so that
       olpc-configure in the *new* build could inspect what old builds were
       available and could install "best-effort" downgrade scripts as needed.

    b) alternately, using one of the CoW filesystem primitives we were
       experimenting with to snapshot /home as well as the OS.)

> It also brings in more headaches. While the updates are somewhat
> efficient (files that do not change between 2 versions are only stored
> on disk once), there is always a space overhead in having 2 versions
> of the system on disk. And during big updates (e.g. F9 to F11), almost
> every file changes, meaning that little disk space is left after doing
> the update.

Life sometimes requires compromises. Maybe you want to take a backup and to
reflash your system partition instead? (Or to spend for a bigger disk?)

> There is no UI to delete the 2nd stored version, the only way to do it
> at the moment is from the Terminal (not suitable for deployments).

True enough.

As a matter of idle speculation, what sort of UI would be suitable for
deployments?

> My proposal is to modify the initramfs, removing the code that
> supports alternate boot (O game-key). And if it encounters an old
> version stored on disk, it will delete it during the boot process.
>
> Having 2 "copies" remains an integral part of the olpc-update process,
> but the old version would be deleted as soon as its not needed.

Makes sense to me.

Regards,

Michael