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.
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
