Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

[Adam Williamson]

On Sat, 2014-01-25 at 23:26 +0100, Tomasz Torcz wrote:
> On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
> > On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
> > > > 
> > > > If there is a directory that contains update and non-update related file
> > > > changes, that's a problem. If there's segmentation, then this can be done.  
> > > 
> > >   Note that this situation is perfectly handled by Offline Updates.
> > > After reboot, there aren't collateral changes to filesystem, only upgrade-related
> > > ones. So if there's a need for revert, the previous state is clearly defined.
> > 
> > Sorry, but this is simply not true.
> > 
> > 
> > The ONLY way to do that is if you do not care at all about user's data
> > and simply accept that a rollback will also remove user data.
> > 
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incompatible ways.
> 
>   What user data?  There is no user data touched/created during offline upgrade.

No, but you may have to use the system somewhat before you can find out
there was a problem with the upgrade, and at *that* point, your user
data may now be tied to the new versions of system apps, as Simo
describes.

So, it goes like this:

* Do an offline update that includes Foo v2.0
* Boot the updated system, run Foo, it migrates its configuration to
some new scheme
* Realize there was something wrong with the update, roll it back
* Run Foo again, find it doesn't work because it's been migrated to the
new config scheme which the old version of Foo doesn't work with
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net