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 trade-offs. But again, I completely agree that some more performance testing should be done. -- Aliaksei > > > -- > Carsten Haitzler (The Rasterman) <tizen at rasterman.com> > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
