On Wed, 2016-10-05 at 02:59 +0000, Andrew Toskin wrote:
This is the first I've heard of any recommendation like this. If
running `dnf upgrade` from a graphical console is such a big and
well-known risk, then why isn't it mentioned in the dnf
documentation? I've posted about this on the dnf Bugzilla.
I'm having a hard time finding anything about this in the Fedora Wiki
either. If you could recommend any particular reading that could
explain this some more, I'd appreciate it.
Hmm, well, there isn't necessarily an awful lot of explicit
documentation of this, I guess. I dunno what's in the user guides these
days. When I said we don't recommend updating from a desktop console, I
guess I was thinking mostly of mailing list discussion, IRC, forums
etc. rather than formal documentation. I don't think there really *is*
any How To Update Your System guide, like we have an Upgrading guide.
I tried to read every message in this email thread, but I'm still
clear: It seems the bug that inspired the original post is based on
certain graphics hardware, but you still say it's best not to run
system updates from a graphical session at all anyway. Is most of the
risk related specifically to X and the large software stack that runs
on it, or is it simply a problem of numbers, where more running
processes means more things could crash while dnf installs updates?
I'd say broadly speaking both, but the most disruptive and potentially
catastrophic effect is when the update process itself crashes or is
killed. Because of how RPM transactions work, this generally leaves you
with RPM convinced you have two copies of a bunch of packages
installed, and cleaning that up is kind of tedious. The more processes
are running underneath the dnf process, the more likely the dnf process
is to get knocked out by something else. (I don't know if dnf could
sensibly be changed to mitigate this issue; it's really not my focus. I
just want to try and help real users deal with the software as it
The effect where the update causes running processes to misbehave is
usually less of a big deal and more just a case of 'eh, restart it or
reboot, no big deal'.
Note I didn't write about using tmux or screen for two reasons:
1) I'm not sure exactly how safe that is from the systemd
2) I didn't want to talk about somewhat-advanced topics, I wanted to
keep it simple
but if you do actually know what you're doing with tmux/screen, and
someone can clear up the KillUserProcesses thing (or you just make sure
the server process is launched outside of the user session, I guess),
then I think running an update from a tmux/screen session running on a
terminal in a desktop should be nearly as safe as doing it in a VT.
Fedora Workstation users are apparently recommended to use GNOME
Software's reboot/update feature; what's the recommended way to
update all packages on instances of Fedora Server or Fedora Cloud?
I'm not sure we actually *have* an official recommendation. My take
would be that it depends on your risk tolerance. Obviously on a typical
Server / Cloud install you're not going to be running the update in a
graphical desktop session, so that avoids a lot of the risk right
there. It's still technically a bit safer to use the pkcon-driven
offline update process than just to update in a VT or with dnf-
automatic or a cron job or something, but it's a much smaller
difference, I'd say.
The one thing I absolutely would advise against: don't do an update
over ssh! Unless you use screen or tmux, of course. But just sshing in
and running an update is a great way to potentially hit trouble.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora