Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24
On Tue, Oct 4, 2016 at 12:51 PM, Gerald B. Cox <gbcox(a)bzb.us> 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