On Tue, Oct 4, 2016 at 12:51 PM, Gerald B. Cox <gbcox@xxxxxx> wrote: > I understand the theoretical exposure, but I guess what I'm missing is how > offline updates eliminates that risk? The system reboots to system-update.target which is a minimal environment. It's basically the kernel, systemd, rpm and maybe dnf. Then it reboots again, with graphical.target. >There is still a plethora of things > which could > interfere with a normal completion of the update process. No. > Seems to me it > would be more worthwhile to build in better error recovery within DNF than > to always require "offline" - especially > since the incidence of failure (at least anecdotally) just isn't that high. Sufficiently impractical that it's not possible. This is why offline updates exists. It's why work is being done on ostree>rpm-ostree>atomic host, which affects the entire build system, deployments, updates, and eventually all of the mirrors. It's why Microsoft and Apple don't allow anything other than offline updates. It's why openSUSE has spent a ton of resources, and a few bloody noses, getting completely atomic updates working with Btrfs and snapper, with very fine rollback capabilities. There's a reason why so many different experts at system updates have looked at this problem and just say, yeah no, not anymore of that. > Instead of dealing with the problem (failed updates and error recovery) - > this approach just tries to avoid it by always requiring > a reboot. Yes. But it's also considered a stop gap. It's not the permanent state. A better way forward is in development. >Kind of defeats the purpose of being able to update a kernel > without a reboot, if your going to always reboot for other updates - and of > course the majority of updates don't require a reboot. Fedora doesn't enable or use live patching for the kernel. > IMHO the risk/benefit ratio is way off on this approach to the problem - but > hey, that's just me - and I'm a KDE user who isn't using it. I think your risk assessment is deficient and unconvincing. This has been explained in great detail by those working on the various solutions to the problem. Read those, then provide contra arguments if you want. Otherwise this is sortof a noisy conversation. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
