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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
