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
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'.
to always require "offline" - especially
since the incidence of failure (at least anecdotally) just isn't that
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
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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net