Improving the offline updates user experience

[Stephen Gallagher]

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.
-------------- 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/20141013/b34064da/attachment-0001.sig>