On 11/21/2011 6:57 PM, Roger Luedecke wrote:
Actually, I think we cuold have a more elegant solution than either. Similar to the new kernel backup thingamajig scheme we just implemented, we could have it check during boot to make sure there wasn't an interruption in the updates and if so have it roll back those changes. This would mean having to keep copies of the packages changed; but in the back of my mind I think we could do it in a way that wouldn't require keeping every RPM ever DL'd.
That's basically reinventing Solaris boot environments which might become possible with btrfs. The basic idea is to snapshot the current root fs, clone it, mount the clone and apply the updates within the context of the clone. Then offer both the updated clone and the original environment in the grub boot menu, if everything went ok you boot into the updated clone and eventually promote it, otherwise you boot back into the original fs and destroy the clone again. To me the only sane way of applying package updates and an area where Linux is sorely lacking. I'm not sure we would need to be so complicated, but I think the idea is good. Certainly this does give a very strong push for the usecase of btrfs in a basic desktop users environment. I think it could be a bit simpler though. Simply have a script that checks to see if there was an interruption, and if so have it reestablish the pre-update files and related configurations. I'm not sure that cloning the root fs and such is necessary, though it would offer an even greater chance of recovery. Ultimately the question I think is how hard would it be to implement the more robust solution, and what sort of
On Tuesday, November 22, 2011 12:03:24 AM Guido Berhoerster wrote: problems this could bring to an end user. IF I understand properly (probably not :P) we would need (or at least it would be very advisable) to have a default system proposal that has a separate '/sys' partition in order to secure the kernel elements. /me is starting to get lost now.
Interruptions are not the only reason updates may fail or be regretted even if they completed. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org