-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 == 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQTB1YACgkQeiVVYja6o6MvpgCeLbkWSgY5XGI4nJg3skjyu8v+ nQUAoIyvNHpJ8SRytPPKGZ3C8kZ560J9 =zZ+N -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
