[Dev] [RFC] Tizen system rollback

Aliaksei Katovich aliaksei.katovich at gmail.com
Sat Nov 30 12:41:20 GMT 2013

hi Carsten;

> On Fri, 29 Nov 2013 17:07:18 +0200 Aliaksei Katovich <a.katovich at samsung.com>
> said:
> > hi all;
> > 
> > 	I would like to bring to your attention Tizen system rollback feature.
> > 	The idea is to provide possibility to roll back Tizen based system to
> > 	one of several known working configurations. Most obvious use-cases
> > are:
> > 
> > 	* system update or upgrade failed;
> > 	* there are regressions introduced by system update;
> > 	* User does not like features added by system update;
> > 	* User wants to restore device to first time configuration;
> > 	* User wants to restore device to factory defaults.
> > 
> > 	Proposed architecture is based on device-mapper thin-provisioning
> > 	capabilities. Please find more details in attached document.
> > 
> > 	Before starting actual implementation of this feature I would like to
> > 	hear your opinion about presented architecture and the idea in
> > general.
> > 
> > Thanks,
> > Aliaksei
> for updates rendering things unbootable (kernel or low level system) what if an
> update renders the os unable to even boot? kernel doesn't even work? shouldn't
> we have a secondary rescue-os install with a "never updated kernel + miniature
> userspace", which is only JUST big enough to boot, prompt the user that
> something "bad" happened, maybe ask if they which to go back to stable, factory
> or initial, then do the rollback, reboot and continue booting normally?

As I mentioned in paper this could be solved by having factory restore point
created _once_ at the very first boot: this _should_ guarantee working kernel.
So no need to install extra rescue-os imho.

Also all rescue attempts should be done automatically by system, i.e. all
possible restore points are checked before factory one is reached.

The only user interaction during boot phase I see is notifying users in case
"nothing helps, please contact service point".

> this would require the real OS to somehow indicate it has booted successfully
> in a way that stays around in memory - eg some fixed memory region to store a
> signature with a counter. bootloader needs to know about this memory region and

'boot' partition on storage?

> check signature on reboot as well as init the memory to some default known
> state. if the boot fails to set this memory to "all ok" any re-boot through the
> bootloader would switch to booting the rescue os.

Recovery mechanism is described in the document :)

> this would allow the same rollback mechanism to be used everywhere with only
> some minimal support from the bootloader (to know when to automatically switch
> to the rescue os).

So factory kernel + factory initramfs + factory snapshot should do the magic.

> btrfs also comes with performance characteristics that may or may not be
> desirable. there is also tux3 i think that does snapshots (and thus rollbacks).

The only problem with filesystems is that you become heavily dependent on its
infrastructure limiting yourself with alternatives when need comes.

> devicemapper seems at a first glance the best option as it works below the fs
> level thus keeping the choice of fs still open, but it may have performance
> affects that could range from minimal to severe.

Yes, there is a risk of having some performance degradation. However I do not
think of it as being as dramatic as "severe" :) All in all, it's all about

But again, I completely agree that some more performance testing should be done.


> -- 
> Carsten Haitzler (The Rasterman) <tizen at rasterman.com>

More information about the Dev mailing list