* Lars Müller
On Thu, Dec 20, 2012 at 09:20:53PM +0100, Guido Berhoerster wrote:
* Lars Müller
[2012-12-20 19:52]: a recent update to KDE made it impossible to the user to logout or to shutdown the system.
Therefore I suggest to change our default way how updates are applied.
a) Always download the updates in advance in the background
We could even be more elegant and throttle the download speed if other processes use the same link.
b) Apply the updates on shutdown
Doing b) after the user finished the X sesison ensures we never lock her in.
Via a new setting is a /etc/sysconfig/ file we're able to change the default. For example to apply updates always at system startup or to keep the update process at the same way as it currently is.
Maybe we're already able to achieve this and I missed the configuration option. But our current default settings lead to the described desktop lock situation.
Please no, lets not copy this awful design from Windows/OSX.
With intention I didn't wrote: others are able to keep it simple and stupid and made this work since ages.
Please make a better and as simple suggestion to circumvent the described issue.
I disagree, what I suggested is both a conceptually simple and proven solution e.g. on Solaris 11 (as others have pointed out again) and simple to implement since most of the bits and pieces for it already exist and just need to be connected for a solution.
We already have the multiversion feature you must enable by hand in /etc/zypp/zypp.conf for the kernel and then you still need multiversion.kernels = latest,latest-1,running and grub2 to get a simple and more reliable setup without much extra cost.
That is not comparable, we are talking about a snapshot of the complete system not just a kernel, there is a multitude of things that can make a system unbootable.
Something like this is easy to use and understandable by our userbase.
I am sure our userbase is able to handle that and to the contrary that it will make things easier. It would probably not even be noticed by most people who just apply the updates and reboot. However, if something goes wrong there's a much easier path to recovery than we have now. And it also provides benefits to server users.
Rather get some inspiration from beadm and utilize snapper to create a snapshot of the system fs, mount and chroot into it, apply the updates, and finally make it the default to boot into on the next reboot.
btrfs is nice to have. But I don't like to push btrfs as mandatory.
btrfs isn't the only way though probably the most performant and straightforward way to implement this. Given that it is supposed to replace ext4 as the default fs I don't find it unreasonable to require it if one want to use this functionality. But AFAICS it might also be possible to make use of the new device mapper thin-provisioning which is independent of the used fs or simply reserve a sparse partition/LV although the latter would be rather inefficient.
That not only avoids the downsides such as annoyingly long shutdown times for desktop users or long downtimes for servers but it has also the advantage that it makes updates safe. If something goes wrong during the update no harm is done and if the updated boot environment does not boot or is broken you can simply reboot into the pre-update environment. Of course that'd require a fs with writable snapshots like btrfs and would put some constraints on the fs layout but since this can remain an optional feature that should not be a problem.
The feature I suggested isn't optional.
Well it should be the default but not mandatory for people who know what they're doing, I surely don't want shutdown/reboots to take minutes. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org