[Dev] [RFC] Tizen system rollback
aliaksei.katovich at gmail.com
Sat Nov 30 12:41:20 GMT 2013
> On Fri, 29 Nov 2013 17:07:18 +0200 Aliaksei Katovich <a.katovich at samsung.com>
> > 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