There is/was a discussion on the development list today regarding a problem when running dnf upgrade from a terminal window under a DE, e.g. GNOME or KDE. What kind of surprised me was that apparently the "official" Fedora stance is use the GNOME GUI updater which updates via reboot and that it is unsafe to do it from a terminal within GNOME or KDE.
I have never encountered any issue so was trying to obtain some stats about exactly what the risk/benefit is... the only thing I could find was within the following thread:
https://lists.fedoraproject.org/pipermail/users/2015-March/459603.html
"... Updating online works 99.8% of the time. The 0.1% time it will corrupt random bits of your file-system, and 0.1% of the time it will leave you vulnerable to the security issue you thought you just "fixed". The only way to fix this so that online updates are safe is to redesign the centralised shared package model we use for distributing applications. The workaround is to use offline updates..."
Also, as I understand it (and this may have changed) is that within KDE there is no "offline" update solution. Apper basically does it the same as issuing the command from a terminal.
So, what is the recommended KDE solution for this? I stated on the development list I thought rebooting for every update was basically sacrificing system availability for what appears to be a very minor risk. Perhaps I'm missing another point or am completely off base here. That is why I'm wanting to know what other KDE users think of this. I've been entering DNF/YUM UPGRADE from within konsole for many years and have never encountered any corruption issues.
I try to keep up-to-date with things, but I completely missed this, and apparently it was introduced in F18.
On 10/05/16 06:48, Gerald B. Cox wrote:
So, what is the recommended KDE solution for this?
This was posted later in the thread you reference....
"We've pretty much pinned it down, now. The recipe is: hybrid graphics + systemd-udev update == X crash."
And the original reporters had multiple video cards in their system. So, if you don't have that HW you need not worry.
And, even if you have that hardware you can simply do the dnf update from a VT. X may crash but the VT won't and the update will complete properly.
So, offline updates on KDE are unnecessary to workaround the issue for the time being.
On Tue, Oct 4, 2016 at 3:55 PM, Ed Greshko ed.greshko@greshko.com wrote:
So, offline updates on KDE are unnecessary to workaround the issue for the time being.
Ed, yes I understand that... but... That isn't my question. My question relates to the apparent "official" Fedora recommendation to NOT use dnf within a terminal under a DE - but instead to only use the GNOME GUI which does all updates with a reboot required each time.
On 10/05/16 07:00, Gerald B. Cox wrote:
On Tue, Oct 4, 2016 at 3:55 PM, Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
So, offline updates on KDE are unnecessary to workaround the issue for the time being.Ed, yes I understand that... but... That isn't my question. My question relates to the apparent "official" Fedora recommendation to NOT use dnf within a terminal under a DE - but instead to only use the GNOME GUI which does all updates with a reboot required each time.
I read Adam's posts to say the way for KDE folks to do it would be under a VT.
I run systems with no, or very little GNOME bits. I don't even know how easy/hard/recommended it would be to use GNOME's update method under my situation. And, I must say, I wouldn't have any curiosity to find out. :-)
On 10/05/16 07:15, Ed Greshko wrote:
On 10/05/16 07:00, Gerald B. Cox wrote:
On Tue, Oct 4, 2016 at 3:55 PM, Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
So, offline updates on KDE are unnecessary to workaround the issue for the time being.Ed, yes I understand that... but... That isn't my question. My question relates to the apparent "official" Fedora recommendation to NOT use dnf within a terminal under a DE - but instead to only use the GNOME GUI which does all updates with a reboot required each time.
I read Adam's posts to say the way for KDE folks to do it would be under a VT.
I run systems with no, or very little GNOME bits. I don't even know how easy/hard/recommended it would be to use GNOME's update method under my situation. And, I must say, I wouldn't have any curiosity to find out. :-)
Oh, I should say that for the time being I'm ssh'ing into my systems from my tablet and updating using dnf that way. I rather prefer the logs kept by dnf and have run into "confusion" when I mixed in using KDE's "Software Update" and couldn't track down when I updated a particular package.
Gerald B. Cox composed on 2016-10-04 15:48 (UTC-0700):
...I'm wanting to know what other KDE users think of this. I've been entering DNF/YUM UPGRADE from within konsole for many years and have never encountered any corruption issues.
I do my updating manually, after logging out of X, on a vtty as root. If an update causes a DM crash, it usually just restarts itself, and if not, I stop graphical.target and restart it, rebooting if that's what it takes to succeed.
Gerald B. Cox wrote:
So, what is the recommended KDE solution for this?
For now, if you're concerned about the risks involved with regular/online updates, follow the thread's advice and not install updates that way.
Long term, ideally, I'd like to see support for offline updates implemented.
-- Rex
On Tue, Oct 4, 2016 at 4:42 PM, Rex Dieter rdieter@math.unl.edu wrote:
For now, if you're concerned about the risks involved with regular/online updates, follow the thread's advice and not install updates that way.
Long term, ideally, I'd like to see support for offline updates implemented.
I'll wait until there is some type of support built into KDE or DNF - or it is highlighted as a risk to RHEL customers.
On Tue, 2016-10-04 at 18:42 -0500, Rex Dieter wrote:
Gerald B. Cox wrote:
So, what is the recommended KDE solution for this?
For now, if you're concerned about the risks involved with regular/online updates, follow the thread's advice and not install updates that way.
Long term, ideally, I'd like to see support for offline updates implemented.
As I understand it, the current Gnome updater downloads the updates, then reboots into a specially configured kernel, applies the updates, then reboots again.
i.e. it's basically Windows.
poc
On Wed, Oct 5, 2016 at 3:26 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
As I understand it, the current Gnome updater downloads the updates, then reboots into a specially configured kernel, applies the updates, then reboots again.
i.e. it's basically Windows.
Yeah, I get it... the whole thing just strikes me as a bit odd. Here is my last response on the developer list about this:
===========================
Chris, first of all thanks much for posting the links. They basically reinforced my opinion. I have no issue whatsoever with "offline" updates. It is of course a valid approach to a problem. My concern was that the blanket implication about the safety of using DNF within a DE. Even your comment that it is "fine... until it isn't" (which can be said about anything) proves the point.
Packagekit... is "safe until it isn't" - refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1259865 which by the way caused me a bunch of grief because on a lark one day I decided to try it out... sucks to be me I guess.
If offline updates have a place (and yes I believe they do) then why isn't that functionality built into DNF now? I would assume (and yes, I know what happens when people ASS-U-ME - ;-) ) that it is because the DNF team doesn't believe the risk/benefit ratio is high enough to put it in yet and they believe other features/functionality are more beneficial.
That said, they basically already do it with the dnf-system-upgrade plugin; so why not just expand that a bit. Also, while i completely understand that it is much easier to just use a sledgehammer and say "offline upgrades for everything" - we both know that isn't required. Again, there is a place for "offline" updates - and I would like to see that option in DNF - but everything has it's place.
Gerald B. Cox wrote:
Also, as I understand it (and this may have changed) is that within KDE there is no "offline" update solution. Apper basically does it the same as issuing the command from a terminal.
The default updater on Fedora KDE is actually the plasma-pk-updates Plasma widget (plasmoid), which is a separate package. You only update with Apper if you explicitly start Apper from the menu.
But plasma-pk-updates also does not support offline updates.
So, what is the recommended KDE solution for this?
Just update online. Restart after updating, only if and when needed. (For most updates, you are fine if you just do nothing until you shut down the machine at the end of the day.) Offline updates cause more problems than they solve.
If an update crashes X11, that's really a bug in the update. It should not happen. When it happens, the solution is: https://bugzilla.redhat.com/show_bug.cgi?id=1091702 (please add comments there), not the sledgehammer approach of doing all updates offline.
Kevin Kofler
On Wed, Oct 5, 2016 at 9:58 AM, Kevin Kofler kevin.kofler@chello.at wrote:
If an update crashes X11, that's really a bug in the update. It should not happen. When it happens, the solution is: https://bugzilla.redhat.com/show_bug.cgi?id=1091702
(please add comments there), not the sledgehammer approach of doing all updates offline.
Thanks Kevin... I opened uo a RFE Bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1382063
for the the ability to do optional "offline" updates via DNF if desired. The DNF team seems receptive to it, but consider it a low priority - and I would agree with that. Unfortunately, the blanket statement in the development thread implied to me a greater risk that actually exists.
-
Ed Greshko -
Felix Miata -
Gerald B. Cox -
Kevin Kofler -
Patrick O'Callaghan -
Rex Dieter