On Tue, 2016-10-04 at 11:51 -0700, Gerald B. Cox wrote: > > I understand the theoretical exposure, but I guess what I'm missing is how > offline updates eliminates that risk? There is still a plethora of things > which could > interfere with a normal completion of the update process. It doesn't eliminate it, it minimizes it. It makes the 'plethora' much smaller. Basically, I think, unless pid 1 crashes or dnf itself crashes, the update is going to complete. > Seems to me it > would be more worthwhile to build in better error recovery within DNF I'm not sure that's a path that'd really get anywhere terribly profitable. You could probably make some kinds of improvements to it, I guess, but I'm not sure it's ever going to be possible to say 'meh, no big deal if the updater crashes halfway through the update'. > than > to always require "offline" - especially > since the incidence of failure (at least anecdotally) just isn't that > high. The point is that it doesn't *have* to be high for it to be a problem. Having this happen one time is one time too many. (But FWIW, it seems like in this case the crash is pretty much reliably reproducible on at least one affected system, and would happen *any* time systemd-udev is updated.) > Instead of dealing with the problem (failed updates and error > recovery) - this approach just tries to avoid it by always requiring > a reboot. 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. I think you're kind of conflating two things here. The offline update thing isn't about 'make sure there's a reboot so the updates are fully applied'. The first reboot is to get to the clean minimal environment where the update can be safely run, the second reboot is to get back *out* of that environment. It's not really 'avoid[ing the problem] by always requiring a reboot', it's avoiding the problem by running the update in a minimal environment, which happens to *imply* a couple of reboots (though we've had discussions about ways it could be done with just one reboot). Some people do seem to place great stock in the 'update without rebooting' thing, but it's fundamentally not entirely safe with RPM updates. Even the offline update approach isn't 100% safe, though it's a lot closer than updating in X and a little closer than updating from a VT. Fedora, AFAIK, doesn't have any kind of focus on the whole 'update the kernel without rebooting' thing, so I'm not sure why you're bringing that up. If anything, the potential future Fedora is working towards is one where the system is deployed and updated via ostree and apps are deployed and updated via flatpak or DOCKAH DOCKAH DOCKAH. That's a design where it's feasible to talk about safe updates without reboots. > 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. If you have an affected system, then the risk of running an update that includes systemd-udev from inside X is 100%. That's a pretty high ratio. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
