[Dev] [RFC] Tizen system rollback

Aliaksei Katovich a.katovich at samsung.com
Mon Dec 2 11:43:26 GMT 2013


hi MyungJoo;

> > 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?
> 
> If you are concerned with a corrupted bootloader. I don't think this feature
> will be able to help you. If it is restricted as low as kernel, it may help.

	Initial idea is to restrict to kernel and above,

> In case of a corrupted 2nd bootloader, it heavily depends on BSP,

	but if 2nd bootloader is possible to update and it would reside on boot
	partition then it should be possible to roll it back all together with
	kernel.

> which is not specified by Tizen. For M0s, we have prepared dual bootloader
> for such cases (as some PCs do have dual BIOS) although I don't think
> they are activated with older version. I didn't check whether this feature is
> activated with which version.
> 
> 
> However, there is an incoming requirement, "Safe Mode" and this feature
> might need to be connected with "Safe Mode" somehow.

	I need to learn more about "Safe Mode". Could you suggest any link to
	feature description?

--
Aliaksei

> 
> 
> Cheers,
> MyungJoo.
> 
> > 
> > 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
> > 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.
> > 
> > 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).
> > 
> > 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).
> > 
> > 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.
> > 
> > 
> > -- 
> > Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> > 
> > 
> > 
> >        
> >   
> >          
> > 


More information about the Dev mailing list