On 10/23/2016 10:06 AM, Michael Catanzaro wrote: > On Sun, 2016-10-23 at 07:47 +0100, Alexander Bisogiannis wrote: >> I think what they mean is that the update process itself should not >> require rebooting in to this "upgrade mode". >> >> The current method requires two reboots to complete the proccess. >> One to boot in "update mode" and another to boot into the updated >> system. > > This is something that can be fixed down to one reboot with engineering > effort. I believe someone (Stephen?) already has a proof of concept. > This would be good to explore further in the short term. > What I had been experimenting with a few releases ago (F22 or F23, IIRC) was essentially skipping the first reboot and just doing the equivalent of `systemctl isolate system-update.target`, running the update and then rebooting a single time after this. I got some line noise from people about how the reboot is necessary to guarantee that the mount state matches a clean boot, but my thoughts on that are: 1) Anyone who is technically competent enough to be modifying their mount table should be sensible enough to set it back to the right place before upgrading and 2) Who the hell would mess with / and /usr? To me, this edge case is sufficiently small that I'd be perfectly comfortable ignoring it in the default case and just having a double-reboot as an optional choice for anyone that wants to be overly-paranoid. Just to itemize the issues I had with the double-reboot: 1) System down-time: a lot of servers in the wild have very long POST cycles (I have a big server under my desk that takes about six minutes to get through POST). If it has to reboot *twice*, then this is a total of twelve minutes (plus whatever time the actual update took) of downtime on that machine. 2) Best security practice is for users to have encrypted drives. However, for end-users, this means that they get stuck having to manually enter their drive decryption passwords twice during updates (which has the side effect of annoying them because they can't just hit the "update" button, then go grab a coffee while the upgrade runs and then enter the password one time when they come back. As a longer-term change, I'd also like to consider avoiding the post-update reboot, assuming we ran in the systemd-update.target. We have plugins for DNF that can detect which updates affected running processes. If we included something like that in the offline updates processing, we could decide to just `systemctl isolate default.target` after the update if nothing running was modified. The end result would be to avoid two reboots entirely (as well as the POST time that would incur).
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
