On 06/15/2016 12:31 PM, Stephen Gallagher wrote: > > > The justification for restarting both before and after installation exists and > it does make some sense in certain circumstances. > > Basically, the problem is that any number of things can change in the state of > the system while it has been running that are impossible to predict. For > example, the system's memory (and swap) could be almost all used up, leading to > unpredictable behavior while processing the update and %pre/%post scripts. Also, > a user may have manually played around with the mount table, resulting in some > directory paths being unmounted or mounted over that the upgrade would write > into. By forcing the system to reboot into a limited environment, it puts the > system into something much closer to a known state which is less likely to > experience an unrecoverable error. (Ever had a runaway log fill up a disk during > a dnf update? Not a good thing.) > > > Of course, this comes with its own headaches, since of course if you are using > an encrypted drive, you need to enter your password twice: once to start the > update and once for the post-update reboot. A while ago I was working on a patch > to PackageKit that would skip the second reboot and just `systemd isolate > default.target` after the upgrade unless the kernel (or other early boot package > like dracut) was updated. I never finished it, but I could try to dig it out and > pass it on to someone who is interested in continuing it. > I meant to also include a section here about how this problem is also completely solved by ostree[1] (the technology used by Project Atomic and upcoming Fedora Workstation changes) which works by prepping all of the state of the system while the current system is running. Then the system is rebooted once directly into the new system, atomically. This leaves no room at all for upgrade failures leaving the system unusable. Historically, there was a tradeoff here, because it was difficult to use ostree for upgrades with a custom set of packages on the system, but recently a lot of work has gone into doing package layering as well, so it's well on its way to becoming a complete replacement of the traditional package-by-package updater. [1] https://github.com/projectatomic/rpm-ostree/blob/master/README.md
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
