PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

I'm working with the reporter right now to investigate and hopefully
get this fixed, but in the meantime - and this is in fact our standard
advice anyway, but it bears repeating - DON'T RUN 'dnf update' INSIDE A
DESKTOP.

Running the update process inside a desktop just gives it all the more
opportunity to crash somehow. If the terminal app crashes, the update
crashes. If the desktop crashes, the update crashes.

I don't want to get in the KDE folks' bad graces, but this likely could
also affect KDE's graphical update system, so I'd advise against using
that for the present too.

If you're using Workstation, the offline update system is expressly
designed to minimize the likelihood of this kind of problem, so please
do consider using it. Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there. Don't do it inside your desktop.

Thanks folks!

[Adam Williamson]

Post by Adam Williamson
Running the update process inside a desktop just gives it all the more
opportunity to crash somehow. If the terminal app crashes, the update
crashes. If the desktop crashes, the update crashes.
I don't want to get in the KDE folks' bad graces, but this likely could
also affect KDE's graphical update system, so I'd advise against using
that for the present too.

Maybe I've just been lucky but I run dnf on a daily basis in a Konsole
terminal window (under KDE) and have never seen this kind of problem. I
don't use the graphical updater(s).

Well, as I said it may be package set or hardware dependent, or just a
case of luck. There've been I think at least five or six reports so far
that I've heard of one way or another, which seemed like enough to send
out a mail shot.

[Andrew Lutomirski]

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

I once hosed a RHEL5 system when an ssh terminal running yum died. Sigh.

[Stephen Gallagher]

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.

[Andrew Lutomirski]

Post by Stephen Gallagher

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.

By that standard, why do we support dnf at all?

$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.

I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave

[Kevin Fenzi]

On Tue, 4 Oct 2016 09:51:16 -0700

Post by Andrew Lutomirski
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

Well, the problem there, what do you mean by 'support'?

In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

Much less so. In the server case you have usually ssh, bash and dnf, in
the desktop case you have X, possibly wayland, tons of graphics
libraries, the terminal application you are using and all it's
libraries, and a shell and dnf. There's just a lot more there to
possibly crash.

kevin

[Stephen John Smoogen]

Post by Kevin Fenzi
On Tue, 4 Oct 2016 09:51:16 -0700

Post by Andrew Lutomirski
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

Well, the problem there, what do you mean by 'support'?
In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

Much less so. In the server case you have usually ssh, bash and dnf, in
the desktop case you have X, possibly wayland, tons of graphics
libraries, the terminal application you are using and all it's
libraries, and a shell and dnf. There's just a lot more there to
possibly crash.

As a systems administrator, I am left with at least 2 different fail states:

1) I reboot the box and have no idea what is going on because it never
came back.
2) I run dnf update and I know it got to sshd or glibc when my
connection to the server went away.

In either case I am hosed and if I am running a cloud of servers..
hosed in scale (or hosed as a service?). The part we really want to do
is try and make it so if we are hosed.. how do we get it to be less
hosed? Because this is going to happen in any case in some form no
matter what.. when it does how do we recover in scale?

[Andrew Lutomirski]

Post by Kevin Fenzi
On Tue, 4 Oct 2016 09:51:16 -0700

Post by Andrew Lutomirski
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

Well, the problem there, what do you mean by 'support'?
In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

Much less so. In the server case you have usually ssh, bash and dnf, in
the desktop case you have X, possibly wayland, tons of graphics
libraries, the terminal application you are using and all it's
libraries, and a shell and dnf. There's just a lot more there to
possibly crash.

My point is that a lot of this exposure could be avoided. Sure,
there's a decent chance that updating packages will crash running
programs. But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade. I've had
Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system. Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.

Post by Kevin Fenzi
kevin
_______________________________________________

So, yes, offline updates or ostree-style updates are better in many
respects, but as long as we provide plain dnf, I think it would be
worth the small amount of effort to make dnf robust against the
terminal dying.

--Andy
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send

[Chris Murphy]

Post by Andrew Lutomirski

Post by Kevin Fenzi
On Tue, 4 Oct 2016 09:51:16 -0700

Post by Andrew Lutomirski
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

Well, the problem there, what do you mean by 'support'?
In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

Much less so. In the server case you have usually ssh, bash and dnf, in
the desktop case you have X, possibly wayland, tons of graphics
libraries, the terminal application you are using and all it's
libraries, and a shell and dnf. There's just a lot more there to
possibly crash.

My point is that a lot of this exposure could be avoided. Sure,
there's a decent chance that updating packages will crash running
programs. But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade.

I think it's avoided by propagating the point adamw started the thread for.

User: Doctor, it hurts when I do this!
DocAdamW: So then don't do that!

Do users need an INFO message when running 'dnf update' to kill off
the myth that without a warning it's expected to be reliable? Maybe.

Post by Andrew Lutomirski
I've had
Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system. Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.

I don't understand how you arrive at this conclusion. dnf is sitting
on the top of a house of cards when it's running in Terminal. If
anything below it dies, dnf dies and by extension so is rpm. Could dnf
be put into it's own session or scope (whatever it's called), and
would that prevent it from dying if the whole GUI died? Even if true,
how does the user know to wait XX minutes before hitting the reset
button? I think it's a rabbit hole, just stop touching the owie.

[Sam Varshavchik]

Post by Chris Murphy
I don't understand how you arrive at this conclusion. dnf is sitting
on the top of a house of cards when it's running in Terminal. If
anything below it dies, dnf dies and by extension so is rpm. Could dnf
be put into it's own session or scope (whatever it's called), and

Has anyone ever heard of sigaction()? Just wondering.

Post by Chris Murphy
would that prevent it from dying if the whole GUI died? Even if true,
how does the user know to wait XX minutes before hitting the reset
button?

I heard of a command called "ps" that might come in useful, in situations
like that.

[Sam Varshavchik]

Post by Andrew Lutomirski
My point is that a lot of this exposure could be avoided. Sure,
there's a decent chance that updating packages will crash running
programs. But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade.

I agree.

As far as I'm concerned, the only possible valid reason for the system to
end up in an inconsistent state would be if the whole thing got SIGKILLed.

And I strongly doubt that an X crash would SIGKILL some process started by
dnf. SIGHUP would be more likely. Perhaps SIGTERM, but neither of those
should result in dnf blowing chunks and messing things up. Either the most
recent transaction should be rolled back, or completed anyway.

The notion that an X crash would result in such situation is quite 

inexplicable. There's simply no valid, logical reason for that, and I'm
quite disappointed to hear that.

Post by Andrew Lutomirski
Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system. Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.

Agreed.

And even if dnf itlsef is SIGKILLed, that may certainly result in a system
being temporarily in an inconsistent state, but I would expect that unless
something like glibc was in the process of being unpacked, it should be
recoverable.

[Gerald B. Cox]

Post by Kevin Fenzi
Well, the problem there, what do you mean by 'support'?
In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

OK, I'm completely confused.

Post by Kevin Fenzi
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.

and I have NEVER used the graphical update since the first release of
Fedora. I've always used yum or dnf. As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it. Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous. What exactly is going on?

As far as rebooting after every update? Huh? Who does that? Are we
Windows? We're suppose to be moving toward the time when you won't need to
reboot for kernel updates. Perhaps this is only a GNOME problem... but
when I used GNOME years ago, I never experienced it. I also have never
seen it with KDE or LxQT.

[Adam Williamson]

Post by Gerald B. Cox
and I have NEVER used the graphical update since the first release of
Fedora. I've always used yum or dnf. As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it. Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous. What exactly is going on?

It's always been dangerous. It works fine all the time until it
doesn't, and then you're left with a pile of broken bits that you get
to spend all afternoon fixing.

It's pretty simple, really: a process running in a terminal inside a
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes. If any of those things happens, your
update process just dies instantly, leaving whatever bits it hadn't
done yet...undone. This is a situation it's technically more or less
impossible to *fully* recover from (it's more or less impossible to
figure out and execute precisely whatever scriptlet actions should have
happened but did not), and is a pain to more-or-less-practically
recover from (you get to hack up some crappy script to detect duplicate
packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
reinstall on the new NEVR...)

I'm not entirely sure if the KDE graphical updater is safer or not, but
I don't think it is, because I think it again effectively just runs the
update transaction inside the KDE session, where it will die partway
through if KDE or X crashes.

The current GNOME update workflow, however, is the most reliable we
have, because it downloads the updates then boots to a minimal systemd
target with as few things running as possible to install the updates,
then boots back to the normal system. This is far, far safer than
running the update inside a desktop.

[Neal Gompa]

On Tue, Oct 4, 2016 at 1:53 PM, Adam Williamson

Post by Adam Williamson

Post by Gerald B. Cox
and I have NEVER used the graphical update since the first release of
Fedora. I've always used yum or dnf. As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it. Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous. What exactly is going on?

It's always been dangerous. It works fine all the time until it
doesn't, and then you're left with a pile of broken bits that you get
to spend all afternoon fixing.
It's pretty simple, really: a process running in a terminal inside a
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes. If any of those things happens, your
update process just dies instantly, leaving whatever bits it hadn't
done yet...undone. This is a situation it's technically more or less
impossible to *fully* recover from (it's more or less impossible to
figure out and execute precisely whatever scriptlet actions should have
happened but did not), and is a pain to more-or-less-practically
recover from (you get to hack up some crappy script to detect duplicate
packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
reinstall on the new NEVR...)
I'm not entirely sure if the KDE graphical updater is safer or not, but
I don't think it is, because I think it again effectively just runs the
update transaction inside the KDE session, where it will die partway
through if KDE or X crashes.
The current GNOME update workflow, however, is the most reliable we
have, because it downloads the updates then boots to a minimal systemd
target with as few things running as possible to install the updates,
then boots back to the normal system. This is far, far safer than
running the update inside a desktop.

I have never heard of anyone reaching out to the KDE PK frontend
developers for supporting this mechanism. As I recall, it required
special development to get working in GNOME Software. Heck, even the
system upgrade stuff required custom development and special plugins
for GNOME Software. If you're going to suggest that people do it this
way, then perhaps you should be reaching out to the Plasma Discover
and Apper developers to ensure that it works from there too...

[Stephen Gallagher]

Post by Neal Gompa
On Tue, Oct 4, 2016 at 1:53 PM, Adam Williamson

Post by Adam Williamson

Post by Gerald B. Cox
and I have NEVER used the graphical update since the first release of
Fedora. I've always used yum or dnf. As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it. Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous. What exactly is going on?

It's always been dangerous. It works fine all the time until it
doesn't, and then you're left with a pile of broken bits that you get
to spend all afternoon fixing.
It's pretty simple, really: a process running in a terminal inside a
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes. If any of those things happens, your
update process just dies instantly, leaving whatever bits it hadn't
done yet...undone. This is a situation it's technically more or less
impossible to *fully* recover from (it's more or less impossible to
figure out and execute precisely whatever scriptlet actions should have
happened but did not), and is a pain to more-or-less-practically
recover from (you get to hack up some crappy script to detect duplicate
packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
reinstall on the new NEVR...)
I'm not entirely sure if the KDE graphical updater is safer or not, but
I don't think it is, because I think it again effectively just runs the
update transaction inside the KDE session, where it will die partway
through if KDE or X crashes.
The current GNOME update workflow, however, is the most reliable we
have, because it downloads the updates then boots to a minimal systemd
target with as few things running as possible to install the updates,
then boots back to the normal system. This is far, far safer than
running the update inside a desktop.

I have never heard of anyone reaching out to the KDE PK frontend
developers for supporting this mechanism. As I recall, it required
special development to get working in GNOME Software. Heck, even the
system upgrade stuff required custom development and special plugins
for GNOME Software. If you're going to suggest that people do it this
way, then perhaps you should be reaching out to the Plasma Discover
and Apper developers to ensure that it works from there too...

The requisite functionality was built in PackageKit specifically to ensure that
it was available for any desktop that wanted to use it. Obviously, since GNOME
Software developers were the ones who developed it, they did the work to make
sure it functions properly there.

Nothing stops KDE or any other mechanism from using this functionality (it's
exposed in the public PackageKit API). See my other replies on this thread for
information on how you could do it from the `pkcon` CLI in a pinch...

[Adam Williamson]

Post by Neal Gompa
I have never heard of anyone reaching out to the KDE PK frontend
developers for supporting this mechanism. As I recall, it required
special development to get working in GNOME Software. Heck, even the
system upgrade stuff required custom development and special plugins
for GNOME Software. If you're going to suggest that people do it this
way, then perhaps you should be reaching out to the Plasma Discover
and Apper developers to ensure that it works from there too...

I'm giving users advice on how not to break their systems. I'm not
really in the business of telling desktops how to code their update
mechanisms.

[Gerald B. Cox]

Post by Adam Williamson
The current GNOME update workflow, however, is the most reliable we
have, because it downloads the updates then boots to a minimal systemd
target with as few things running as possible to install the updates,
then boots back to the normal system. This is far, far safer than
running the update inside a desktop.

Interesting... since I don't use GNOME that is probably why I wasn't aware
of this.

I found this:
https://lists.fedoraproject.org/pipermail/users/2015-March/459603.html

From what I've read so far, KDE does not do "offline" updates.... I'm still
researching so maybe that has changed, but in the above mentioned thread,
KDE did not support it.

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
which could
interfere with a normal completion of the update process. 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. 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.

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.

[Chris Murphy]

Post by Gerald B. Cox
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.

Post by Gerald B. Cox
There is still a plethora of things
which could
interfere with a normal completion of the update process.

No.

Post by Gerald B. Cox
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.

Post by Gerald B. Cox
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.

Post by Gerald B. Cox
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.

Post by Gerald B. Cox
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.

[Gerald B. Cox]

Post by Chris Murphy

Post by Gerald B. Cox
IMHO the risk/benefit ratio is way off on this approach to the problem -

but

Post by Gerald B. Cox
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.

Well, it could be that this is just an issue in the GNOME environment. I
can't really comment on that
because I haven't used it for years. Don't get upset just because I don't
agree with you.. You haven't produced
any hard facts.

[Chris Murphy]

Post by Gerald B. Cox

Post by Chris Murphy

Post by Gerald B. Cox
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.

Well, it could be that this is just an issue in the GNOME environment. I
can't really comment on that
because I haven't used it for years.

It is not a GNOME specific environment, this has already been explained.

Post by Gerald B. Cox
Don't get upset just because I don't
agree with you.. You haven't produced
any hard facts.

You can't make me angry. Meanwhile, you're constantly citing only your
own anecdotal evidence and then extrapolating beyond it to a much
broader population without any hard facts.

Like I said, others have been working on this for a while, and they
have documented it and they've included their hard facts. You just
haven't bothered to make yourself aware of anything beyond your own
experience.

[Gerald B. Cox]

Post by Chris Murphy
Like I said, others have been working on this for a while, and they
have documented it and they've included their hard facts. You just
haven't bothered to make yourself aware of anything beyond your own
experience.

Interesting... I posted a few links - still reading... haven't found
anything that changes my opinion.
If you have a link with some facts and statistics on failure please post.

[Chris Murphy]

Post by Gerald B. Cox

Post by Chris Murphy
Like I said, others have been working on this for a while, and they
have documented it and they've included their hard facts. You just
haven't bothered to make yourself aware of anything beyond your own
experience.

Interesting... I posted a few links - still reading... haven't found
anything that changes my opinion.
If you have a link with some facts and statistics on failure please post.

Let me Google that for you? No thanks. I told you the various projects
that are working on safer system updates, they've written tons about
this on their lists. That's where I learned about this stuff.

[Gerald B. Cox]

Post by Chris Murphy

Post by Gerald B. Cox

Post by Chris Murphy
Like I said, others have been working on this for a while, and they
have documented it and they've included their hard facts. You just
haven't bothered to make yourself aware of anything beyond your own
experience.

Interesting... I posted a few links - still reading... haven't found
anything that changes my opinion.
If you have a link with some facts and statistics on failure please post.

Let me Google that for you? No thanks. I told you the various projects
that are working on safer system updates, they've written tons about
this on their lists. That's where I learned about this stuff.

Chris, I have been googling... and reading quite a bit... what I said was
that
I have yet to find what you are claiming.

[Sam Varshavchik]

Post by Chris Murphy

Post by Gerald B. Cox
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.

Wrong.

I can make any process survive an X shutdown, using an amazing tool called
"tmux".

Why can't dnf do the same?

Post by Chris Murphy
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.

You do not need atomic updates to install a signal handler for SIGHUP or
SIGTERM. And maybe issue a setsid() call, beforehand.

This shouldn't be rocket science.

[Chris Adams]

Post by Sam Varshavchik
I can make any process survive an X shutdown, using an amazing tool
called "tmux".
Why can't dnf do the same?

Because dnf would have to reimplement tmux's (or screen's) TTY handling,
which is far outside the scope of a package manager. If you want to run
dnf under tmux/screen, then run it under tmux/screen.

Post by Sam Varshavchik
You do not need atomic updates to install a signal handler for
SIGHUP or SIGTERM. And maybe issue a setsid() call, beforehand.

That's not enough. dnf prints running information to standard
out/error, which are connected to the terminal via a TTY. As soon as
the terminal process is killed, the TTY is closed, and the next write by
dnf will cause an error.

Now, the error could be ignored, but it is hard to say there's a
legitimate path to follow after such an error. A system-level program
like dnf should generally not ignore such errors. Any RPM script that
writes to standard out/error (they're not supposed to do that, but some
do, sometimes inadvertently) will also fail.

If you want dnf to survive the terminal exiting, run it under something
that handles that, like tmux or screen. Heck, alias dnf to "screen dnf"
(or the tmux equivalent) if you like. Don't try to make dnf reimplement
all that functionality.

[Sam Varshavchik]

Post by Chris Adams

Post by Sam Varshavchik
I can make any process survive an X shutdown, using an amazing tool
called "tmux".
Why can't dnf do the same?

Because dnf would have to reimplement tmux's (or screen's) TTY handling,
which is far outside the scope of a package manager. If you want to run
dnf under tmux/screen, then run it under tmux/screen.

By my rough estimate, the relevant bits of "TTY handling" that are needed to
survive the terminal going away comprise no more than four or five system
calls.

Post by Chris Adams

Post by Sam Varshavchik
You do not need atomic updates to install a signal handler for
SIGHUP or SIGTERM. And maybe issue a setsid() call, beforehand.

That's not enough. dnf prints running information to standard
out/error, which are connected to the terminal via a TTY. As soon as
the terminal process is killed, the TTY is closed, and the next write by
dnf will cause an error.

Mea culpa. I forgot about SIGPIPE, my fault. Ok, let's just add SIGPIPE to
the list of blocked signals.

I'm up to six system calls, now.

Post by Chris Adams
Now, the error could be ignored, but it is hard to say there's a
legitimate path to follow after such an error. A system-level program
like dnf should generally not ignore such errors. Any RPM script that
writes to standard out/error (they're not supposed to do that, but some
do, sometimes inadvertently) will also fail.

Splendid. Have the scripts' stdout redirected to a pipe, that dnf will read,
and attempt to log it to the terminal on its own, and deal with the fallout.

Post by Chris Adams
If you want dnf to survive the terminal exiting, run it under something
that handles that, like tmux or screen. Heck, alias dnf to "screen dnf"
(or the tmux equivalent) if you like. Don't try to make dnf reimplement
all that functionality.

Okee-dokee. That's a reasonable proposition. But only if "reasonable" is
defined in a fairly limited way; namely "work-around for lack of resilience
and fault tolerance in a criticial system update tool".

[Chris Murphy]

Post by Sam Varshavchik

Post by Chris Murphy

Post by Gerald B. Cox
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.

Wrong.
I can make any process survive an X shutdown, using an amazing tool called
"tmux".
Why can't dnf do the same?

I suggested earlier in the thread that it automatically put itself in
its own scope. But I don't know if that solves this problem, and even
if it does it's only one part of a much bigger set of problems that
can cause updates to implode. In this case, sure maybe dnf survives,
but X is gone, the user has no idea what just happened, they have no
idea dnf is still applying their updates in the background, so they
don't know they shouldn't reboot.

When you start making the list of things that have to work exactly
right for system updates in a GUI , you get basically two things:

1. fuck it, we're making the user log out and do the update offline, and;

2. fuck it, we're doing something completely different ala OSTree, ala
Snapper, so the user can do a rollback if things go wrong.

The first is what happens on the other 90% of the world's computers,
including Android system updates. Consider that. The second exists,
right now, and it works and it's a lot better than what the rest of
the world uses.

Strictly speaking Fedora doesn't make you do the first one, but it's
*well* understood for a long time how fragile this is which is why
offline updates was created.

Post by Sam Varshavchik

Post by Chris Murphy
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.

You do not need atomic updates to install a signal handler for SIGHUP or
SIGTERM. And maybe issue a setsid() call, beforehand.
This shouldn't be rocket science.

OK you clearly don't understand the complexity. So go ahead and do
things your way, and when you don't like the result from hitting the
Hurt Me Button, complain and criticize people all you want, wait for
the silence from those who could not give two shits, which means: stop
doing things wrong, start doing them correctly, or fix it all yourself
Mr. Genius. And then go write your own updater.

[Stephen John Smoogen]

OK Everyone.. enough. If you want to keep at it, take it off-list.

[Sam Varshavchik]

Post by Chris Murphy
I suggested earlier in the thread that it automatically put itself in
its own scope. But I don't know if that solves this problem, and even
if it does it's only one part of a much bigger set of problems that
can cause updates to implode. In this case, sure maybe dnf survives,
but X is gone, the user has no idea what just happened, they have no
idea dnf is still applying their updates in the background, so they
don't know they shouldn't reboot.

Well, perhaps I misunderstood the situation at hand. But I'm under the
impression that, right now, dnf just blows up and leaves things in an
inconsistent state.

Maybe this is too much of a radical idea, but it makes sense to me to
address this first, and then maybe worry about what is the best way for dnf
to forge ahead when it realizes that its terminal is gone.

Right now, if I'm in a middle of a dnf update, and I try to start another
dnf operation, the second operation will fail. So dnf is smart enough to
exclusive-lock itself. I also have a dim recollection of some plugin that
said something about blocking system shutdowns, in some context. I'm a bit
hazy on that, but in any case, this is not something that must be solved on
day 1. A non-sophisticated user is not going to drop to a terminal prompt,
and execute dnf manually. I think that it's a reasonable proposition that
someone who does do that, and ends up killing X for some reason, will be
able to figure out if dnf is still running, or not, in the background.

Post by Chris Murphy
When you start making the list of things that have to work exactly
1. fuck it, we're making the user log out and do the update offline, and;
2. fuck it, we're doing something completely different ala OSTree, ala
Snapper, so the user can do a rollback if things go wrong.
The first is what happens on the other 90% of the world's computers,
including Android system updates.

But ordinary regular app updates will happily run on cruise control, without
bringing the system down into single user mode. If Android can do that, I
see no reason why Fedora can't, either. The only time you need to reboot an
Android device is for a kernel-level update.

Post by Chris Murphy
Strictly speaking Fedora doesn't make you do the first one, but it's
*well* understood for a long time how fragile this is which is why
offline updates was created.

Well, this is a surprise to me. I guess my faith in dnf was misplaced.

I spent my time in the trenches. I spent a lot of time writing system
daemons that I expected to recover from SIGKILL automatically. It wasn't
exactly easy, but it was not an impossible task either. I'm not expecting
any medals for that, just mentioning the fact that it's not, and should not
be, considered to be a lost art. As I'm told it is now, apparently.

Post by Chris Murphy

Post by Sam Varshavchik

Post by Chris Murphy
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.

You do not need atomic updates to install a signal handler for SIGHUP or
SIGTERM. And maybe issue a setsid() call, beforehand.
This shouldn't be rocket science.

OK you clearly don't understand the complexity. So go ahead and do

Yes, I do not. But I am more than willing to be educated. Please explain to
me the complexity in `setsid()`, and a few calls to `sigaction()`, and maybe
an occasional `fork()`, here and there. Granted, when bleep hits the fan,
you wouldn't immediately know where things stand without further digging.
But, at least you are not going to end up with an unbootable brick, as long
as you don't panic, and take things one step at a time.

Post by Chris Murphy
things your way, and when you don't like the result from hitting the
Hurt Me Button, complain and criticize people all you want, wait for
the silence from those who could not give two shits, which means: stop
doing things wrong, start doing them correctly, or fix it all yourself
Mr. Genius. And then go write your own updater.

You know, actually I did, about ten years ago, I think – don't recall the
exact timeframe. Nothing earth-shattering; just the same basic functionality
as rpm: basic install/update/delete, and some dependency tracking.

And, by the way, an atomic package commit. If the process was SIGKILL-ed in
a middle of a transaction – which might've involved a multi-package
update – the install would finish automatically, when it got restarted. I
spent some time on that because I recall that at the time rpm would do that
too. I am certain that at least some point when you started rpm after
something blew up, it would yell at you that a previous transaction hasn't
been finished, and offered to clean it up for you.

So, it seems that this doesn't happen anymore. I guess that's the price of
progress.

[Adam Williamson]

But ordinary regular app updates will happily run on cruise control, without 
bringing the system down into single user mode. If Android can do that, I 
see no reason why Fedora can't, either. The only time you need to reboot an 
Android device is for a kernel-level update.

No, in fact, it's for any *system level* update. Any change to the
underlying system (as opposed to an app) requires the full reboot
treatment. Only updates to app packages don't.

The reason Android can do fairly good app updates is precisely because
it does exactly what Flatpak and Snappy are trying to do for Linux:
hard separation between app space and system space. Flatpak and Snappy
didn't just spring fully formed from a vacuum, they're very obviously
the product of someone using Android and/or iOS and going 'huh, maybe
we should do that'.

We can't realistically do it with the 'distribution is just a big pile
of RPMs' model. GNOME folks thought we could, for a while, then
realized they were wrong.

[Gerald B. Cox]

Post by Chris Murphy
Strictly speaking Fedora doesn't make you do the first one, but it's

Post by Chris Murphy
*well* understood for a long time how fragile this is which is why
offline updates was created.

Well, this is a surprise to me. I guess my faith in dnf was misplaced.

Here also. The DNF team has done an excellent job in obfuscating the
horror IMO because (knock on wood) I've always been very impressed
with the features and functionality. Seems a shame that all those nice
bells and whistles will now be hidden behind some gui or pkcon.

I've been scrambling reading threads trying to understand what exactly is
the exposure here. The only thing I could find that quantified the risk
was in this kde thread:

https://goo.gl/m87COz

*"...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..."*

[Adam Williamson]

Post by Gerald B. Cox
I've been scrambling reading threads trying to understand what exactly is
the exposure here. The only thing I could find that quantified the risk
https://goo.gl/m87COz

You're never really going to be able to 'quantify the risk', because we
don't have solid enough data. We don't know exactly how many millions
of people are running Fedora in how many millions of configurations and
just how many of them have ever had a dnf update failure. We don't even
know any single one of those things. You're kind of on a hiding to
nothing there. Point is, live update processes can and do go wrong. We
certainly have enough records of that. Dig through bugzilla and you'll
find plenty. I can think of ~4 cases that actually *did* get reported
and precisely identified since F21. The more stuff running under the
update process, the more likely problems are to happen.

All dnf's 'nice features' aren't really there for a system update, are
they? You can use all of its nice features for doing other things. When
you update the system, all you want is...an updated system. pkcon and
GNOME's offline update flow achieve that just fine.

[Sam Varshavchik]

Post by Adam Williamson
All dnf's 'nice features' aren't really there for a system update, are
they?

Well what are they there for, then?

Post by Adam Williamson
You can use all of its nice features for doing other things.

Like what? I thought that the only thing dnf does is update the system. Oh,
yeah, sure you can query metadata on available packages too.

Post by Adam Williamson
When
you update the system, all you want is...an updated system. pkcon and
GNOME's offline update flow achieve that just fine.

Hmmm
 Right now, running "pkcon get-updates" claims "There are no updates
available at this time.", meanwhile "dnf upgrade" shows 68 packages that can
be updated. "pkcon refresh" doesn't change anything.

[Adam Williamson]

Post by Sam Varshavchik

Post by Adam Williamson
All dnf's 'nice features' aren't really there for a system update, are
they?

Well what are they there for, then?

Querying the package database and installing new packages. A system
update, on the other hand, is...it's not *configurable*, really. You
say 'update my system, please!' and you get an updated system. That's
kind of it. I'm just struggling to think which of the 'features and
functionality' of dnf Gerald was talking about in the context of doing
a system update. I think the most I'd ever use would be --enablerepo /
--disablerepo , and --nogpgcheck (and hopefully we'll never need that
one again anyway, now).

But I was talking to Gerald, not you. I'm not really sure why you keep
jumping in and prolonging this thread - you apparently didn't hit the
bug, and you certainly know enough about the tech to drive your own
personal updates however you choose. What exactly is your goal here?

Post by Sam Varshavchik
Hmmm… Right now, running "pkcon get-updates" claims "There are no
updates  
available at this time.", meanwhile "dnf upgrade" shows 68 packages
that can  
be updated. "pkcon refresh" doesn't change anything.

I don't actually have much experience of driving it through pkcon, I've
only ever used the GNOME Software route, where the refresh button more
or less seems to do what it claims. I don't use the offline updates
stuff on my own servers, I'm okay with just letting dnf-automatic do
them. My personal fuzzy evaluation is that the you get about 90% of the
safety gain going from 'run in a terminal in X' to 'run in a VT',
offline updates get you another 10%, and I'm okay with that tradeoff
for my machines because they're just not terribly important. If I was
running a gajillion dollar server farm I'd probably have different
considerations.

[Gerald B. Cox]

Post by Adam Williamson
Querying the package database and installing new packages. A system
update, on the other hand, is...it's not *configurable*, really. You
say 'update my system, please!' and you get an updated system. That's
kind of it. I'm just struggling to think which of the 'features and
functionality' of dnf Gerald was talking about in the context of doing
a system update.

Adam, one of my favorite commands (which has kept me out of trouble) is
"dnf history". Chris
posted some excellent links so I'm going to say more there.

[Adam Williamson]

Post by Gerald B. Cox

Post by Adam Williamson
Querying the package database and installing new packages. A system
update, on the other hand, is...it's not *configurable*, really. You
say 'update my system, please!' and you get an updated system. That's
kind of it. I'm just struggling to think which of the 'features and
functionality' of dnf Gerald was talking about in the context of doing
a system update.

Adam, one of my favorite commands (which has kept me out of trouble) is
"dnf history". Chris
posted some excellent links so I'm going to say more there.

Ah, that is a point: I *really really hate* that transaction history is
not shared between dnf and PackageKit, so 'dnf history' doesn't show
transactions that were run by pkcon or GNOME Software. That drives me
clean up the damn wall.

[Jeff Fearn]

Post by Sam Varshavchik

Post by Adam Williamson
All dnf's 'nice features' aren't really there for a system update, are
they?

Well what are they there for, then?

Post by Adam Williamson
You can use all of its nice features for doing other things.

Like what? I thought that the only thing dnf does is update the system.
Oh, yeah, sure you can query metadata on available packages too.

I think there is a misunderstanding here on the use of "system".

I believe Adam is saying that upgrading packages for the underlying OS
is where the problem is, but you can upgrade packages in other layers of
the OS fine.

e.g. upgrading glibc can be an issue, upgrading vi should be fine.

Upgrading emacs is undefined.

Cheers, Jeff.

[Adam Williamson]

Post by Jeff Fearn

Post by Sam Varshavchik

Post by Adam Williamson
All dnf's 'nice features' aren't really there for a system update, are
they?

Well what are they there for, then?

Post by Adam Williamson
You can use all of its nice features for doing other things.

Like what? I thought that the only thing dnf does is update the system.
Oh, yeah, sure you can query metadata on available packages too.

I think there is a misunderstanding here on the use of "system".
I believe Adam is saying that upgrading packages for the underlying OS
is where the problem is, but you can upgrade packages in other layers of
the OS fine.
e.g. upgrading glibc can be an issue, upgrading vi should be fine.
Upgrading emacs is undefined.

No, that's not what I meant. I was replying to Gerald's post (though I
missed quoting the relevant bit, which led to some confusion):

"The DNF team has done an excellent job in obfuscating the
horror IMO because (knock on wood) I've always been very impressed
with the features and functionality.  Seems a shame that all those nice
bells and whistles will now be hidden behind some gui or pkcon."

I was just confused as to what 'features and functionality' would be
'hidden' by a GUI or pkcon in the case of doing a system update, since
I can't really think what 'features and functionality' you really use
when running dnf update.

[Adam Williamson]

Post by Gerald B. Cox
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
which could
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.

Post by Gerald B. Cox
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'.

Post by Gerald B. Cox
than
to always require "offline" - especially
since the incidence of failure (at least anecdotally) just isn't that
high.

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.)

Post by Gerald B. Cox
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.

Post by Gerald B. Cox
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.

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
ratio.

[Sam Varshavchik]

Post by Adam Williamson
It's pretty simple, really: a process running in a terminal inside a
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes.

It should take me about five minutes to write a process that will continue
happily along if its terminal, desktop, or X crashes. Especially if the
process doesn't need to talk to X in the first place. Like dnf.

I'm quite astonished to read this. Something is wrong, here. Either I have
suffered a stroke, today, or I seriously misunderstood some POSIX
fundamentals, for the last twenty years.

For chrissakes, there's a bleeping program in Fedora called "tmux" that has
managed to accomplished the herculean feat of surviving X shutting down.

I just performed a simple experiment.

1. Opened a terminal window

2. Executed tmux

3. In a tmux session executed "cat >/dev/null"

4. Logged out from the desktop, and only because CTRL-ALT-BACKSPACE has been
disabled "for our convenience", but to the tmux sesssion running in a
terminal this is indistinguishable from losing the X session unexpectedly.

5. Guess what? After logging back in, opening a terminal window, and
executed "tmux attach", I found my "cat" program happily waiting to dump
more stuff into /dev/null.

Really, the silly excuse that, somehow, X shutting down is a valid reason to
dnf to blow chunks is embarassing. This whole thread is mind-boggling.

I'll be more than happy to eat crow, if proven wrong by pointing out some
detail that I missed; but if I consider anything short of a direct SIGKILL
to a dnf process (or the entire system crashing due to power loss, etc)
ending up with an inconsistent state, to be a BUG.

No, really, I challenge anyone to reproduce this amazing feat of tmux
surviving an unexpected X shutdown and then tell me why dnf cannot do the
same.

[Adam Williamson]

Post by Sam Varshavchik
I'm quite astonished to read this. Something is wrong, here. Either I have
suffered a stroke, today, or I seriously misunderstood some POSIX
fundamentals, for the last twenty years.

Oh fer Pete's sake, would you please ratchet down the rhetoric and stop
posting the same thing over and over again? You've made your position
clear and now you're just polluting the thread. I'm trying to advise
real users on how to ensure they don't suffer real problems, not start
an epic argument about how to write update tools. I'm sure the dnf
developers are happy to take submissions through the usual channels.

[Chris Murphy]

Post by Gerald B. Cox

Post by Kevin Fenzi
Well, the problem there, what do you mean by 'support'?
In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"

OK, I'm completely confused.

Post by Kevin Fenzi
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.

That was a suggested change to inform the user.

It's an OK idea. With "atomic" deployments (those that are rpm-ostree
based) the 'dnf update' command hard fails. You're expected to use
'rpm-ostree upgrade' which itself would be integrated into the
graphical updater.

Post by Gerald B. Cox
and I have NEVER used the graphical update since the first release of
Fedora. I've always used yum or dnf. As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it. Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous. What exactly is going on?

This is old news. It's come up on this list numerous times. It's the
*entire* reason why offline updates exists. Not doing them offline is
know to entail all kinds of non-deterministic risks.

Post by Gerald B. Cox
As far as rebooting after every update? Huh? Who does that?

Strictly speaking it's not necessary for every update, there's just no
mechanism for knowing for sure what updates entail more risk than
others. You'll notice that once an application is installed, whether
by dnf or Gnome Software, it's considered part of the system. There's
no separation of OS upgrades from application updates. The former
entail a lot more risk than the latter. In the near future, I expect
flatpak applications can be updated in place, once complete you'd get
a prompt to relaunch the application to use the update one, or
something like that.

Post by Gerald B. Cox
Are we
Windows?

Yes, we're Windows. Is that what you want to hear? I don't understand
why you think this is a question to be taken seriously rather than
ridiculous.

And by the way, macOS does the same thing. The main difference there
is application updates rarely require reboots, because applications
are self contained. You do have to quit them for the update to get
applied though.

[Michael Cronenworth]

Post by Chris Murphy
Strictly speaking it's not necessary for every update, there's just no
mechanism for knowing for sure what updates entail more risk than
others. You'll notice that once an application is installed, whether
by dnf or Gnome Software, it's considered part of the system. There's
no separation of OS upgrades from application updates. The former
entail a lot more risk than the latter. In the near future, I expect
flatpak applications can be updated in place, once complete you'd get
a prompt to relaunch the application to use the update one, or
something like that.

dnf install python3-dnf-plugins-extras-tracer
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an e

[Chris Murphy]

Post by Michael Cronenworth

Post by Chris Murphy
Strictly speaking it's not necessary for every update, there's just no
mechanism for knowing for sure what updates entail more risk than
others. You'll notice that once an application is installed, whether
by dnf or Gnome Software, it's considered part of the system. There's
no separation of OS upgrades from application updates. The former
entail a lot more risk than the latter. In the near future, I expect
flatpak applications can be updated in place, once complete you'd get
a prompt to relaunch the application to use the update one, or
something like that.

dnf install python3-dnf-plugins-extras-tracer

That's cool but it's not the default behavior, and it also doesn't
come in advance as part of all the information what will be updated.
It'd be useful to know what needs restarting, including if a reboot is
needed.

Looks like this might also be useful, but isn't included by default.
http://dnf-plugins-core.readthedocs.io/en/latest/needs_restarting.html

[Gerald B. Cox]

Post by Chris Murphy

Post by Gerald B. Cox
Are we
Windows?

Yes, we're Windows. Is that what you want to hear? I don't understand
why you think this is a question to be taken seriously rather than
ridiculous.

No, it was a rhetorical question. See my other response. Basically, IMHO
this
"solution" fails a simple risk/benefit analysis. Instead of dealing with
the root issue which
is error recovery it attempts to circumvent it at the expense of system
availability.

[Stephen John Smoogen]

Post by Gerald B. Cox

Post by Chris Murphy

Post by Gerald B. Cox
Are we
Windows?

Yes, we're Windows. Is that what you want to hear? I don't understand
why you think this is a question to be taken seriously rather than
ridiculous.

No, it was a rhetorical question. See my other response. Basically, IMHO
this
"solution" fails a simple risk/benefit analysis. Instead of dealing with
the root issue which
is error recovery it attempts to circumvent it at the expense of system
availability.

This problem is not easily solvable by dnf or yum or anything else.
You are standing on the branch of a tree. When you do an update you
are cutting off branches of a tree and growing new ones. Sometimes you
are cutting the trunk of the tree. The problem is that if you are
cutting your own branch or the tree trunk.. you are sunk.

The problem is that modern software has a lot of branches. The tree
looks like this
https://twitter.com/NaturelsWeird/status/783006609765269504

Maybe that branch you cut doesn't look like it has anything to do with
the one you are standing on.. but maybe it did and now you are hosed.

This has been a problem for as long as Red Hat Linux existed with a
remote shell and people would end up with crashed systems because sshd
died when an update was done. There were all kinds of 'hacks' to make
it work mostly but there were still conditions where you could crash
out your system. It also showed up every now and then on X updates
which could also be 'hacked' around but was still racy. As the tree
gets more complicated.. the more the hacks are moving from an 95%
solution to a 0.95 * 0.95 * 0.95 ... and ending up with it being a 60%
solution and just getting worse over time.

Post by Gerald B. Cox
_______________________________________________

[Sam Varshavchik]

it.  Apparently I've missed something along the way because now people are
implying that using the command line tools from within GNOME or KDE are
dangerous.  What exactly is going on?

Somewhere along the way, it seems that quite a few sharks have been jumped
over.

Sad.

[Ms Sanchez]

Kevin, now you mention Wayland... Could it be possible to be a Wayland
related issue? I have Nvidia but no Wayland and never an issue updating
from desktop.


Cheers,

Sylvia


_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproj

[Chris Murphy]

Post by Andrew Lutomirski
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.

Well it's not always risky, it depends on what's being updated. If
it's applications, it's pretty safe unless they're running. There is a
qualitative difference between server and workstation, so the warning
may be misleading if it exists on server also.

Post by Andrew Lutomirski
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.

Yeah this is really debatable for best practices to expect users to
know these things. You can argue if they're using dnf they should know
better, and just accept that things can blow up, or help track them
down so if possible this stuff can get fixed.

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

PackageKit is installed on server, so while I haven't tested it, it
seems plausible it could be used for system updates. But I think the
risk here is much less because dnf is a bit more isolated by not
running in a GUI Terminal in a user session. But even here, a reboot
is expected for many things, there's just no guarantee of state
otherwise.

I think the thing that's unique with current offline updates compared
to other platforms I use is the double reboot. The reboot to get to
offline updates target where the update happens, and then a reboot to
get back to graphical target. That does seem suboptimal to me, where
other platforms just log out the user session, and drop to their
reduced function "updates" state to do the update, and then there's
one reboot.

Anyway, my opinion is that Workstation folks should use Gnome Software
to do their updates, and if there's something wonky there, we need to
get it fixed. That's the default and primary update method. Within
something like 5 minutes of first boot after an installation,
PackageKit is already downloading updated packages. Unless that's
disabled, a 'dnf update' is going to unnecessarily download those
packages in duplicate.

[Stephen Gallagher]

Post by Andrew Lutomirski

Post by Stephen Gallagher

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.

By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

```
sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger **
sudo systemctl reboot
```

[Stephen Gallagher]

Post by Stephen Gallagher

Post by Andrew Lutomirski

Post by Stephen Gallagher

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.

By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.

```
sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger **
sudo systemctl reboot
```

That "**" should have been "&& \"

[Björn Persson]

Post by Stephen Gallagher

Post by Stephen Gallagher

Post by Andrew Lutomirski
For server use, I'm not convinced that the offline update
mechanism is supported (at the very least, I have no idea how to
trigger it), and servers have the same issue.

```
sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger **
sudo systemctl reboot
```

That "**" should have been "&& \"

If there isn't a single command to do all of that, that can compete
with "yum update" in simplicity, then that shows that offline updating
isn't being seriously promoted for servers.

Björn Persson

[Ms Sanchez]

I never needed to reboot. I just keep working on my stuff, when I'm
done I turn the laptop off. Is there any reason to reboot right after
updating?


Cheers,

Sylvia


_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscri

[Peter Larsen]

Post by Ms Sanchez
I never needed to reboot. I just keep working on my stuff, when I'm
done I turn the laptop off. Is there any reason to reboot right after
updating?

That's actually a very common misunderstanding. People think that "yum/dnf update" leaves their system in a new updated stage. But it doesn't (completely). It never has. Only after a reboot are all your patches applied and active. Existing/running processes are rarely if ever reloaded. So when you update libraries, kernels etc. your system will keep running with the old versions of those libraries loaded. Remember, in Linux a inode is never deleted until the very last process has released it. So any read file handles will keep a file, even one you cannot see with ls, available.

The only real complete update you can do is one that does a full reboot. We do have a few tricks with DNF which will attempt to let you know what needs restarting. But you'll find that a good part of our updates requires a restart of most if not all your system, in order for the updates to become fully active.

This problem often shows itself on long running servers by a system not coming back up/online after a reboot. And nobody understand why - but it's pretty simple. Nobody tested that things worked after an update, and in most cases that requires a reboot. If you kernel, glibc or network control system gets updated, you'll need to reboot to reload them. Or of course take your network offline with everything running on your box (good luck!).

So it may look like that "it works just fine" but it's a deception. It's still running the older versions of libraries etc for most processes. If you start looking at what's actually running after your update, you'll find that a good part of your updated packages aren't running (yet) - and old versions are still active. If you're attempting to apply security updates, this is an important distinction and vital to be compliant. For us ordinary users, it's mostly an annoyance as features we wanted, aren't there right after an update, or programs starts failing after an update, as they attempt to dynamicly load in modules and find them "changed", at times not even compatible with the running older version, and things end up "strange". I've seen fonts go nuts, backgrounds disappear, general themes not working etc. after an update on a workstation, simply because the structure got changed - CSSes looking for files that no longer are there, etc.

//
Peter
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedo

[Chris Murphy]

Post by Stephen Gallagher

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.

It's not really workable without an atomic and out of tree update
method, otherwise libraries are still yanked out from under running
processes at some point. I've done this with nspawn (and chroot),
taking snapshots of root, then applying the update to the snapshot,
changing the bootloader to boot the updated snapshot. This is tedious
but it's reliable in that pretty much anything bad can happen and it's
only the fs tree being updated that can be broken. And only one reboot
is needed.

The long term solution is rpm-ostree based Workstation where the
currently running fs tree isn't touched either.

[Björn Persson]

Post by Chris Murphy
It's not really workable without an atomic and out of tree update
method, otherwise libraries are still yanked out from under running
processes at some point.

Running programs and their loaded libraries count as open files. Unixy
filesystems don't delete open files. They change the directory entry to
point to the new file and keep the old file around until it's closed.
Therefore libraries are *not* yanked out from under running processes.

What tends to break is badly designed GUI programs that apparently
don't keep their files open but still expect different files to be from
the exact same version. Firefox and Seamonkey seem to do something like
that. They tend to break in funny ways when updated. Many other GUI
programs have no problems with getting updated while running.

Björn Persson

[Neal Gompa]

Post by Andrew Lutomirski

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)? This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.
I once hosed a RHEL5 system when an ssh terminal running yum died. Sigh.

This is pretty much what dnfdaemon does. However, dnfdaemon is only
used by yumex-dnf[1] and dnfdragora[2].

To the best of my knowledge, there are no CLI clients for it.

[1]: https://github.com/timlau/yumex-dnf
[2]: https://github.com/anaselli/dnfdragora

[Adam Williamson]

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,

LXQT in my case, so more X than GNOME crash
is there a bug I can subscribe to?

Not yet (AFAIK), I'm trying to walk the reporter who's currently in
#fedora-qa through filing one. abrt is showing an X crash for him,
indeed. If you have hit this and you still have the system live, you
should be able to find the X crash in abrt and report it.

Post by Adam Williamson
Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there. Don't do it inside your desktop.

or better (IMHO) - run it using `screen` ;-)

I think whether that's better or not depends on exactly how the
screen/tmux server process was run...

[Ian Pilcher]

Post by Adam Williamson

or better (IMHO) - run it using `screen` ;-)

I think whether that's better or not depends on exactly how the
screen/tmux server process was run...

Can you clarify? In what circumstances would the dnf command running
within a screen session not survive an X/desktop crash?

[Tomasz Torcz]

Post by Ian Pilcher

Post by Adam Williamson

or better (IMHO) - run it using `screen` ;-)

I think whether that's better or not depends on exactly how the
screen/tmux server process was run...

Can you clarify? In what circumstances would the dnf command running
within a screen session not survive an X/desktop crash?

KillUserProcesses=yes

[Ian Pilcher]

Post by Tomasz Torcz

Post by Ian Pilcher
Can you clarify? In what circumstances would the dnf command running
within a screen session not survive an X/desktop crash?

KillUserProcesses=yes

Ouch! Forgot about that.

[Martin Kolman]

Can you clarify?  In what circumstances would the dnf command
running
within a screen session not survive an X/desktop crash?

   KillUserProcesses=yes

Ouch!  Forgot about that.

BTW, was there any progress in making screen & tmux aware of this, so
that screen and tmux sessions are not killed when the user logs out or
- as in this case - the graphical session crashes ?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to dev

[Matthew Miller]

Post by Martin Kolman

   KillUserProcesses=yes

Ouch!  Forgot about that.

BTW, was there any progress in making screen & tmux aware of this, so
that screen and tmux sessions are not killed when the user logs out or
- as in this case - the graphical session crashes ?

Some, but not complete, so change was deferred to F26. See
https://bugzilla.redhat.com/show_bug.cgi?id=1357426

[Chris Murphy]

On Tue, Oct 4, 2016 at 9:56 AM, Patrick O'Callaghan

Post by Adam Williamson
Running the update process inside a desktop just gives it all the more
opportunity to crash somehow. If the terminal app crashes, the update
crashes. If the desktop crashes, the update crashes.
I don't want to get in the KDE folks' bad graces, but this likely could
also affect KDE's graphical update system, so I'd advise against using
that for the present too.

Maybe I've just been lucky but I run dnf on a daily basis in a Konsole
terminal window (under KDE) and have never seen this kind of problem. I
don't use the graphical updater(s).

I do it also but I also take a snapshot of root first, and then I
expect without warning that the GUI could just vanish and munge a
bunch of things. It's a use case I expect to not work, even though it
Works For Me™.

[Adam Williamson]

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,

LXQT in my case, so more X than GNOME crash
is there a bug I can subscribe to?

Seems the bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1341327

[stan]

On Tue, 04 Oct 2016 08:51:07 -0700

Post by Adam Williamson
I'm working with the reporter right now to investigate and hopefully
get this fixed, but in the meantime - and this is in fact our standard
advice anyway, but it bears repeating - DON'T RUN 'dnf update' INSIDE
A DESKTOP.

I think I can confirm this advice. I always run dnf manually from the
command line, in a VT logged in as root. And I can run X while doing
this and I've never had a dnf update issue. I don't use the
graphical update tools, and always have PackageKit disabled to prevent
duplicate downloads of updates.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe sen

[Luya Tshimbalanga]

Thanks for the warning. Fortunately I frequently run update with Gnome Software.
Does that issue also affect "pkcon update" command as well?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave

[Chris Murphy]

On Tue, Oct 4, 2016 at 1:34 PM, Luya Tshimbalanga

Post by Luya Tshimbalanga
Thanks for the warning. Fortunately I frequently run update with Gnome Software.
Does that issue also affect "pkcon update" command as well?

Likely. It's avoided if you use --only-download, enable the offline
update trigger and reboot.

[Luya Tshimbalanga]

Post by Chris Murphy
Likely. It's avoided if you use --only-download, enable the offline
update trigger and reboot.

Thanks for the tips.

Luya
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

[Adam Williamson]

Post by Luya Tshimbalanga
Thanks for the warning. Fortunately I frequently run update with Gnome Software.
Does that issue also affect "pkcon update" command as well?

Yes, it would. The issue does have an element of hardware dependence
also. What we've worked out so far (with thanks to Zbyszek) is
basically this:

1. When you update systemd-udev , it restarts systemd-udev-trigger.service
in %post
2. That calls `udevadm trigger --type=devices --action=add`
3. That seems to result in the video adapter effectively being replugged
at the udev level

Now on *most* systems, this seems to just cause X to (metaphorically)
blink, go "what the hell happened there?", shrug, and carry on. If your
system is one of these, you won't really notice anything. On affected
systems, however - which so far seems to be something like 'some
systems with NVIDIA adapters, possibly ones with NVIDIA/Intel hybrid
graphics' - it causes X to crash.

If you want to check if your system is affected you can just run
'systemctl restart systemd-udev-trigger.service' as root with a desktop
running, and see if it crashes. Make sure you don't have anything
running unsaved. :P

[Luya Tshimbalanga]

I confirm my system, an AMD/AMD hybrid graphics powered laptop, is affected by executing 'systemctl restart systemd-udev-trigger.service' as root on desktop. The desktop session crashed and the login screen comes afterwards.
The same command on a dedicated NVIDIA graphics card is fairly harmless.

It seems the issue is affecting all hardware with hybrid graphics.

Luya
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-lea

[Adam Williamson]

Post by Luya Tshimbalanga
I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
affected by executing 'systemctl restart systemd-udev-
trigger.service' as root on desktop. The desktop session crashed and
the login screen comes afterwards.
The same command on a dedicated NVIDIA graphics card is fairly
harmless.
It seems the issue is affecting all hardware with hybrid graphics.

That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.

[Luya Tshimbalanga]

Post by Adam Williamson
That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.

No problem. Glad the data helps.

Luya
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.f

[Luya Tshimbalanga]

Post by Adam Williamson
That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.

No problem. Glad the data helps.

Luya
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.f

[Chris Murphy]

On Tue, Oct 4, 2016 at 2:39 PM, Adam Williamson

Post by Adam Williamson

Post by Luya Tshimbalanga
I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
affected by executing 'systemctl restart systemd-udev-
trigger.service' as root on desktop. The desktop session crashed and
the login screen comes afterwards.
The same command on a dedicated NVIDIA graphics card is fairly harmless.
It seems the issue is affecting all hardware with hybrid graphics.

That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.

I have AMD/Intel hybrid graphics and the problem doesn't happen. This
is F24, GNOME on Wayland.

[Adam Williamson]

Post by Chris Murphy
On Tue, Oct 4, 2016 at 2:39 PM, Adam Williamson

Post by Adam Williamson

Post by Luya Tshimbalanga
I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
affected by executing 'systemctl restart systemd-udev-
trigger.service' as root on desktop. The desktop session crashed and
the login screen comes afterwards.
The same command on a dedicated NVIDIA graphics card is fairly harmless.
It seems the issue is affecting all hardware with hybrid graphics.

That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.

I have AMD/Intel hybrid graphics and the problem doesn't happen. This
is F24, GNOME on Wayland.

Well, the bug is an X crash, so it's not surprising it doesn't exist in
Wayland. ;) Good job Wayland for not crashing, I guess...

[Tom Hughes]

Post by Adam Williamson
Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

I had it happen this morning in fact.

When it happens X crashes and you're left with duplicate package entries
that a distro-sync will normally fix though this morning was a bit more
fun because systemd was included and the distro-sync didn't want to
remove the duplicate.

It only ever happens on one of my machines, so it's obviously something
about the environment, possibly the graphics card as that's the only
machine I do this on that has nvidia graphics?

The weird thing is that there was nothing particularly X related in the
update that caused it this morning. In fact systemd was probably about
the most low level thing that was in the update.

Tom

[Adam Williamson]

Post by Tom Hughes
It only ever happens on one of my machines, so it's obviously something
about the environment, possibly the graphics card as that's the only
machine I do this on that has nvidia graphics?
The weird thing is that there was nothing particularly X related in the
update that caused it this morning. In fact systemd was probably about
the most low level thing that was in the update.

We've pretty much pinned it down, now. The recipe is: hybrid graphics +
systemd-udev update == X crash. That is, if there's a systemd-udev
update in the dnf transaction, and the system has hybrid graphics, and
X is running while the update runs, X will crash. If you're running the
update in a VT, X will crash but the update will complete OK. If you
run the update inside X, the update process will die when X crashes and
your system will be left messed up.

I'm gonna write up a blog post and spread the word about this a bit,
I'll send the link shortly; if people could spread it around that'd be
great.

The bug reports are
https://bugzilla.redhat.com/show_bug.cgi?id=1341327 (for the X side)
and
https://bugzilla.redhat.com/show_bug.cgi?id=1378974 (for the systemd
side). We are going to try and ensure the bug doesn't affect F25 Beta
installs. An update is pending for F24, but ironically (since the
service restart is in %postun not %post), the transaction to apply the
update will *suffer from* the problem; the update will only ensure that
*subsequent* updates no longer trigger the problem.

Thanks for the data everyone!

[Tom Hughes]

Post by Adam Williamson
We've pretty much pinned it down, now. The recipe is: hybrid graphics +
systemd-udev update == X crash. That is, if there's a systemd-udev
update in the dnf transaction, and the system has hybrid graphics, and
X is running while the update runs, X will crash. If you're running the
update in a VT, X will crash but the update will complete OK. If you
run the update inside X, the update process will die when X crashes and
your system will be left messed up.

My machine at work where this happens isn't hybrid. It has three
monitors spread over two Nvidia cards though, driven by nouveau rather
than the proprietary drivers.

Tom

[Adam Williamson]

Post by Tom Hughes

Post by Adam Williamson
We've pretty much pinned it down, now. The recipe is: hybrid graphics +
systemd-udev update == X crash. That is, if there's a systemd-udev
update in the dnf transaction, and the system has hybrid graphics, and
X is running while the update runs, X will crash. If you're running the
update in a VT, X will crash but the update will complete OK. If you
run the update inside X, the update process will die when X crashes and
your system will be left messed up.

My machine at work where this happens isn't hybrid. It has three
monitors spread over two Nvidia cards though, driven by nouveau rather
than the proprietary drivers.

OK, so probably strictly speaking this is triggered by having multiple
adapters. 'Hybrid graphics' is by far the most common case of that
these days, though. Thanks for the note, I'll revise my blog post (that
I'm writing ATM).

[Jens Lody]

Am Tue, 04 Oct 2016 14:22:34 -0700

Post by Adam Williamson

Post by Tom Hughes

Post by Adam Williamson
We've pretty much pinned it down, now. The recipe is: hybrid
graphics + systemd-udev update == X crash. That is, if there's a
systemd-udev update in the dnf transaction, and the system has
hybrid graphics, and X is running while the update runs, X will
crash. If you're running the update in a VT, X will crash but the
update will complete OK. If you run the update inside X, the
update process will die when X crashes and your system will be
left messed up.

My machine at work where this happens isn't hybrid. It has three
monitors spread over two Nvidia cards though, driven by nouveau
rather than the proprietary drivers.

OK, so probably strictly speaking this is triggered by having multiple
adapters. 'Hybrid graphics' is by far the most common case of that
these days, though. Thanks for the note, I'll revise my blog post
(that I'm writing ATM).

I did not see such crashes on my hybrid laptop with F24, X and
gnome-shell.
I mostly use the intel gpu, but some games run on the
nvidia-gpu with nouveau-driver.
I tried the "systemctl restart systemd-udev-trigger.service"-approach
from a "normal" terminal and from a terminal under nouveau and there
was not even a flashing of the monitor visible. I do not have a
secondary (or third ...) monitor connected, just the default laptop
screen.

Jens

[Adam Williamson]

Post by Jens Lody
Am Tue, 04 Oct 2016 14:22:34 -0700

Post by Adam Williamson

Post by Tom Hughes

Post by Adam Williamson
We've pretty much pinned it down, now. The recipe is: hybrid
graphics + systemd-udev update == X crash. That is, if there's a
systemd-udev update in the dnf transaction, and the system has
hybrid graphics, and X is running while the update runs, X will
crash. If you're running the update in a VT, X will crash but the
update will complete OK. If you run the update inside X, the
update process will die when X crashes and your system will be
left messed up.

My machine at work where this happens isn't hybrid. It has three
monitors spread over two Nvidia cards though, driven by nouveau
rather than the proprietary drivers.

OK, so probably strictly speaking this is triggered by having multiple
adapters. 'Hybrid graphics' is by far the most common case of that
these days, though. Thanks for the note, I'll revise my blog post
(that I'm writing ATM).

I did not see such crashes on my hybrid laptop with F24, X and
gnome-shell.
I mostly use the intel gpu, but some games run on the
nvidia-gpu with nouveau-driver.
I tried the "systemctl restart systemd-udev-trigger.service"-approach
from a "normal" terminal and from a terminal under nouveau and there
was not even a flashing of the monitor visible. I do not have a
secondary (or third ...) monitor connected, just the default laptop
screen.

OK, that's the second report of an unaffected hybrid system (cmurf said
the same thing).

So basically we can say that at least several systems with multiple
adapters are affected, and no-one has yet reported a system with a
single adapter being affected so far as I can tell. But not *all*
multiple adapter systems are affected. We don't know what the
difference is yet. Still, safest thing is just to assume that if you
have a multiple adapter system you may be affected.

[Adam Williamson]

Post by Adam Williamson
I'm gonna write up a blog post and spread the word about this a bit,
I'll send the link shortly; if people could spread it around that'd be
great.

Blog post:

https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/

If folks can spread that around, it'd be great. Please let me know of
any errors or inaccuracies you spot.

[Björn Persson]

Post by Adam Williamson
If you're using Workstation, the offline update system is expressly
designed to minimize the likelihood of this kind of problem, so please
do consider using it.

In CentOS or Debian I can afford to reboot for every update. With
Fedora's rapid stream of updates that's simply not workable.

Post by Adam Williamson
Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there.

In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

So if this bug is specific to F24 and multiple GPUs, then I guess I'm
lucky to be still using F23 and having only one GPU.

Björn Persson

[Adam Williamson]

Post by Björn Persson

Post by Adam Williamson
If you're using Workstation, the offline update system is expressly
designed to minimize the likelihood of this kind of problem, so please
do consider using it.

In CentOS or Debian I can afford to reboot for every update. With
Fedora's rapid stream of updates that's simply not workable.

Then just don't apply every update. There's no law that says you have
to...if there's a pending security update you get a different and more
urgent notification, btw.

Post by Björn Persson

Post by Adam Williamson
Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there.

In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

You can look at the list from a desktop terminal but actually run the
transaction from the VT, or you can run inside screen or tmux and use
their scrollback features...

[Björn Persson]

Post by Adam Williamson

Post by Björn Persson

Post by Adam Williamson
If you're using Workstation, the offline update system is
expressly designed to minimize the likelihood of this kind of
problem, so please do consider using it.

In CentOS or Debian I can afford to reboot for every update. With
Fedora's rapid stream of updates that's simply not workable.

Then just don't apply every update. There's no law that says you have
to...if there's a pending security update you get a different and more
urgent notification, btw.

I don't get any notifications at all. I just try to remember to run Yum
periodically, and there I'm not told which updates are security updates.

I used to subscribe to the package-announce list, but I had to drop that
when some broken program started sending invalid mails to the list, and
the list server kicked me out for rejecting invalid mail. It was never a
very good notification mechanism anyway, as I always had to wait a day
or two for the packages to appear on the mirrors before I could update.

Many years ago there was sometimes a tray applet that could notify me
about pending updates, but it disappeared. If something similar exists
now, then I don't know its name so I don't know what to install.
Perhaps there is some notification mechanism in Gnome 3; I wouldn't
know. I'm not aunt Tillie so I don't use Gnome 3.

Björn Persson

[Matthew Miller]

Post by Björn Persson
I don't get any notifications at all. I just try to remember to run Yum
periodically, and there I'm not told which updates are security updates.

If you install fedora-motd, it'll update /etc/motd with pending update
info when you log in over ssh. And, while it's not really documented as
such, just running `motdgen` will give you output like:

09:22:04 up 11 days, 22:13, 1 user, load average: 0.03, 0.12, 0.22
Updates Information Summary: available
2 Security notice(s)
1 Bugfix notice(s)
4 Enhancement notice(s)

This is a fairly new thing and could use input and further development.

[stan]

On Wed, 5 Oct 2016 00:20:25 +0200

Post by Björn Persson
In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

An alternative to Adam's suggestions.

It takes a couple of logins as root, but running
dnf update > /tmp/dnf_out 2> /tmp/dnf_ror
in one terminal and then doing a
less /tmp/dnf_*
in another allows a view of the updates before approving or denying
them. When you see the (y or N) in the less output, go back to the
console running the program and make your selection. A little clumsy,
but works fine.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to

[Björn Persson]

Post by stan
On Wed, 5 Oct 2016 00:20:25 +0200

Post by Björn Persson
In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

An alternative to Adam's suggestions.
It takes a couple of logins as root, but running
dnf update > /tmp/dnf_out 2> /tmp/dnf_ror
in one terminal and then doing a
less /tmp/dnf_*
in another allows a view of the updates before approving or denying
them. When you see the (y or N) in the less output, go back to the
console running the program and make your selection. A little clumsy,
but works fine.

It's pretty obvious that improvement is needed when people start to
suggest *that* kind of hack-arounds.

Björn Persson

[Chris Murphy]

Post by Björn Persson

Post by Adam Williamson
If you're using Workstation, the offline update system is expressly
designed to minimize the likelihood of this kind of problem, so please
do consider using it.

In CentOS or Debian I can afford to reboot for every update. With
Fedora's rapid stream of updates that's simply not workable.

I don't know what the trigger is, but GNOME Software doesn't ask you
to do updates more than once a week. If you do 'dnf update' daily,
yeah it'll find something to update most of the time.

Once a week is still pretty frequent, but Software doesn't insist that
you install the updates once they're available and downloaded. It does
it on the next reboot which you can do whenever you'd reboot anyway.

Post by Björn Persson

Post by Adam Williamson
Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there.

In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

It can be piped to more.

[Andrew Toskin]

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.

https://bugzilla.redhat.com/show_bug.cgi?id=1381785

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.

I tried to read every message in this email thread, but I'm still not 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? 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?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproje

[Chris Murphy]

OK this is from just one thread, pretty much exactly two years ago.
It's a long thread so these are just extractions I think are useful in
getting a few different data points about the rationalization of
offline updates, and context for the use case where they're most well
suited (or not).

And really the bottom line is, dnf update is fine the vast majority of
the time, except when it isn't. Failures are somewhere in between a
bug and not at all surprising. And people have been working hard on
solving this for years.

https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/YAWUZXOTCHWGPZ4RKKN22YSB575IEDIJ/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/NUJIJEZN5RV6E6DH7P2EM35OJUC3NM75/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/4HHSIHSQM7HSQRT3KPLLF5MC7FVVTXAJ/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/36PTCP2G2I4FKZQSYNT4YLR22557ARBA/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/ZARJIYPOJKUACXFYWFHMSU4WHPDB4IPK/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/6GIGWVDIKHGBEGWS7CWDRI5OSCS7NLYF/
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/ODNPCPTWNVFRGBGC2IQUA5VSSKGESAMV/


There are a bunch of other threads scattered about on multiple lists
about and why OSTree. About and why LVM thinp snapshots, Btrfs, and
Snapper. Why Chrome OS, Android, and also even CoreOS went with the
A/B partitioning layout they did.

[Chris Murphy]

Post by Chris Murphy
OK this is from just one thread, pretty much exactly two years ago.
It's a long thread so these are just extractions I think are useful in
getting a few different data points about the rationalization of
offline updates, and context for the use case where they're most well
suited (or not).
And really the bottom line is, dnf update is fine the vast majority of
the time, except when it isn't. Failures are somewhere in between a
bug and not at all surprising. And people have been working hard on
solving this for years.

One more for that thread is good as well...

https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/GH5WJZGD3O55IBGAM7IOUB4ZAHCHVUSI/

[Gerald B. Cox]

Post by Chris Murphy
And really the bottom line is, dnf update is fine the vast majority of
the time, except when it isn't. Failures are somewhere in between a
bug and not at all surprising. And people have been working hard on
solving this for years.

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]

Post by Gerald B. Cox
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.

I created a RFE bug requesting that the upgrade function in DNF be changed
to incorporate "offline" upgrades as an option. If it is really
an issue, DNF should handle it.
https://bugzilla.redhat.com/show_bug.cgi?id=1382063

[Dan Book]

Post by Gerald B. Cox
I created a RFE bug requesting that the upgrade function in DNF be changed
to incorporate "offline" upgrades as an option. If it is really
an issue, DNF should handle it.
https://bugzilla.redhat.com/show_bug.cgi?id=1382063

This would be really nice to have. I'd like to add that at least the MATE
and Cinnamon spins, possibly others, do not include PackageKit and instead
expect users to update using yumex-dnf or dnf itself. So ideally an offline
update mechanism can be added to dnf, and then exposed in yumex-dnf. But we
may have to consider installing PackageKit in those spins. My concern with
this is that PackageKit and dnf do not share history and many users are
used to using dnf.

[Adam Williamson]

Post by Andrew Toskin
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1381785
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.

Post by Andrew Toskin
I tried to read every message in this email thread, but I'm still not
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
currently exists.)

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
KillUserProcesses change
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.

Post by Andrew Toskin
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.

[Bruno Wolff III]

On Tue, Oct 04, 2016 at 20:42:11 -0700,

Post by Adam Williamson
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
currently exists.)

package-cleanup --cleandupes still works on f25, though I am not sure what the
proper dnf version of this is. (I needed this about a week ago when an
issue triggered by a kernel problem I don't fully understand caused an
update to be terminated.) You can usually get the updates to finish and then
clean up the duplicates. Sometimes it gets trickier.

Post by Adam Williamson
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.

This isn't as bad as you might think. While I mean to use screen, I often
forget and very rarely have problems as restarting sshd doesn't shut down
existing ssh sessions.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscr

[Kevin Fenzi]

On Wed, 5 Oct 2016 10:56:35 -0500

Post by Bruno Wolff III
On Tue, Oct 04, 2016 at 20:42:11 -0700,

Post by Adam Williamson
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 currently exists.)

package-cleanup --cleandupes still works on f25, though I am not sure
what the proper dnf version of this is. (I needed this about a week
ago when an issue triggered by a kernel problem I don't fully
understand caused an update to be terminated.) You can usually get
the updates to finish and then clean up the duplicates. Sometimes it
gets trickier.

From 'man yum2dnf':

Detailed table for package-cleanup replacement:

┌─────────────────────────────┬─────────────────────────────┐
│package-cleanup --dupes │ dnf repoquery --duplicated │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --leaves │ dnf repoquery --unneeded │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --orphans │ dnf repoquery --extras │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --oldkernels │ dnf repoquery --installonly │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --problems │ dnf repoquery --unsatisfied │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --cleandupes │ dnf remove --duplicated │
├─────────────────────────────┌──────────────────────────────
│package-cleanup --oldkernels │ dnf remove --oldinstallonly │
└─────────────────────────────┮─────────────────────────────┘

Post by Bruno Wolff III

Post by Adam Williamson
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.

This isn't as bad as you might think. While I mean to use screen, I
often forget and very rarely have problems as restarting sshd doesn't
shut down existing ssh sessions.

Right, thats the thing... 99.9% of the time you are just fine. :)

kevin

[Japheth Cleaver]

Post by Kevin Fenzi
On Wed, 5 Oct 2016 10:56:35 -0500

Post by Bruno Wolff III
On Tue, Oct 04, 2016 at 20:42:11 -0700,

Post by Adam Williamson
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.

This isn't as bad as you might think. While I mean to use screen, I
often forget and very rarely have problems as restarting sshd doesn't
shut down existing ssh sessions.

Right, thats the thing... 99.9% of the time you are just fine. :)
kevin

After a check-update preview, I can count the number of times "yum -y
update &" has ever failed me over the years on one hand.

-jc

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-