On 12/02/2013 08:32 PM, 함명주 wrote:
On Fri, 29 Nov 2013 17:07:18 +0200 Aliaksei Katovich <[email protected]>
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.
no - i'm assume bootloader is never touched. i am assuming a kernel WILL
need updates and thus a "bad kernel update" or for that matter any low
level system init breaks can render a device unbootable. the user should
not be forced to go find a pc, download software for it etc. so they can
reflash to a working device. the device should be able to recover on its
own "in the field" (no network needed).
In case of a corrupted 2nd bootloader, it heavily depends on BSP,
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.
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) <[email protected]>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
