Improving the offline updates user experience

[Stephen Gallagher]

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.
-------------- 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/20141002/d93c0ca8/attachment.sig>