[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-factory
Subject:    Re: [opensuse-factory] Update while active graphical desktop session made logout impossible
From:       Guido Berhoerster <gber () opensuse ! org>
Date:       2012-12-21 20:13:32
Message-ID: 20121221201331.GC26941 () hal ! local ! invalid
[Download RAW message or body]

* Lars Müller <lmuelle@suse.com> [2012-12-21 19:29]:
> On Thu, Dec 20, 2012 at 09:20:53PM +0100, Guido Berhoerster wrote:
> > * Lars Müller <lmuelle@suse.com> [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

[prev in list] [next in list] [prev in thread] [next in thread]