5:48 p.m.
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.
5:55 p.m.
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.
--
You're Welcome Zachary Quinto
6 p.m.
On Tue, Oct 4, 2016 at 3:55 PM, Ed Greshko <ed.greshko(a)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.
6:15 p.m.
On 10/05/16 07:00, Gerald B. Cox wrote:
On Tue, Oct 4, 2016 at 3:55 PM, Ed Greshko <ed.greshko(a)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. :-)
--
You're Welcome Zachary Quinto
6:19 p.m.
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(a)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.
--
You're Welcome Zachary Quinto
6:03 p.m.
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
6:42 p.m.
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
9:06 p.m.
On Tue, Oct 4, 2016 at 4:42 PM, Rex Dieter <rdieter(a)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.
5:26 a.m.
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
9:38 a.m.
On Wed, Oct 5, 2016 at 3:26 AM, Patrick O'Callaghan <pocallaghan(a)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.
11:58 a.m.
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
12:18 p.m.
On Wed, Oct 5, 2016 at 9:58 AM, Kevin Kofler <kevin.kofler(a)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.
2821
days inactive
2822
days old
11 comments
6 participants
participants (6)
-
Ed Greshko -
Felix Miata -
Gerald B. Cox -
Kevin Kofler -
Patrick O'Callaghan -
Rex Dieter