Improving the offline updates user experience

[Stephen Gallagher]

On Mon, 2014-10-13 at 11:26 -0400, Stephen Gallagher wrote:
> 
> 
> On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote:
> > 
> > 
> > On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
> > > == The Problem ==
> > > 
> > > It is very common for users to have systems with encrypted root
> > > partitions (or even just /var and /etc). This may be due to a personal
> > > concern for their data or a corporate policy mandating full-disk
> > > encryption. Disk encryption requires a password (or other more
> > > complicated credentials) be be presented just after the kernel is
> > > booted and before the drives can be mounted and their data read.
> > > 
> > > With the current implementation of the offline updates in Fedora, this
> > > leads to a very unpleasant user experience when updating. We offer two
> > > ways to perform offline updates in the default user environment of
> > > Fedora Workstation: "Install updates and reboot" or "Install updates
> > > and shut down".
> > > 
> > > With "Install updates and reboot", the behavior is as follows:
> > > 
> > > 1) The system shuts down and initiates an ACPI reboot.
> > > 2) The system presents the kernel boot menu and then starts the
> > > updater kernel.
> > > 3) The system presents the user with a password prompt for the disk
> > > encryption (possibly more than one, if the system is configured with
> > > different passwords for different partitions).
> > > 4) The offline updates occur.
> > > 5) The system shuts down and initiates an ACPI reboot.
> > > 6) The system presents the kernel boot menu and then starts the
> > > standard (possibly updated) kernel.
> > > 7) The system presents the user with a password prompt for the disk
> > > encryption (possibly more than one, if the system is configured with
> > > different passwords for different partitions).
> > > 8) The system completes booting.
> > > 
> > > During this experience, the user has been required to enter their disk
> > > encryption password *twice*. The same is true for the "Install and
> > > shut down" case, except that the two passwords are separated by some
> > > actual wallclock time.
> > > 
> > > == Proposed Improvements ==
> > > 
> > > We could significantly improve this situation by allowing the system
> > > to drop directly from the interactive system into the updater
> > > environment without doing a full reboot or relaunching the kernel.
> > > 
> > > Lennart, would it be possible to set up a special systemd target for
> > > performing updates that would essentially stop all processes except
> > > for systemd and then apply the updates?
> > > 
> > > In an ideal world, it would then also be possible after update is
> > > completed to restore operation to the standard boot targets of systemd
> > > so that the system comes back up without having to perform a total
> > > reboot. The exceptional case would of course be that in which either
> > > the kernel, libc or systemd[1] needed to be updated, in which case a
> > > reboot could be performed.
> > > 
> > > In this scenario, we can reduce the number of encrypted disk
> > > challenges to at most a single one, and that only if absolutely
> > > minimal plumbing packages saw an update.
> > > 
> > > I'd very much like to hear from the plumbers on this matter.
> > > 
> > > 
> > > [1] I'm told that this might not be necessary; that systemd can
> > > re-exec itself to pick up its own updates. That would reduce the scope
> > > presumably to "only the kernel" forcing reboots.
> > 
> > 
> > I'm bumping this thread to get comments from Lennart (CCed). There's a
> > lot of chatter in the conversation, but I'd very much like to hear an
> > answer to the specific questions I posed in this first email.
> 
> Trying one more time to get Lennart to chime in here.


I spotted on another mailing list that Lennart is using a different
email address these days. I'm now trying to reach him on that one
instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141021/d411e709/attachment.sig>