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

Adam Williamson awilliam at
Sat Jan 25 23:12:38 UTC 2014

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

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

More information about the devel mailing list