yum upgrade stuck

jd1008 jd1008 at gmail.com
Mon Sep 21 00:16:35 UTC 2015



On 09/20/2015 05:30 PM, Michael Schwendt wrote:
> On Sat, 19 Sep 2015 19:41:48 -0700, Gordon Messmer wrote:
>
>> On 09/19/2015 11:51 AM, jd1008 wrote:
>>> --> Processing Conflict: mutter-3.16.2-1.fc22.x86_64 conflicts
>>> gnome-shell < 3.16.1
>>> ...
>>> How do I resolve this?
>> Hard to say, since gnome-shell should be in the upgrade set.  Your
>> system is in a weird state.
> Has any trouble-shooting been done to examine that "weird state"?
Not sure how to proceed on that. When yum get's stuck like that,
it does not give any technical details on why it is stuck trying to
resolve the conflict. Even the -v flag (which I have not tried yet)
might not reveal the underlying cause of the hang), but I will try
it.
>
> gnome-shell >= 3.16.1 clearly is available for F22 in updates, but
> that doesn't matter much, if there are duplicates installed, for
> example.
None! No dups at all.
>
> Typically, one submits a couple of rpm/dnf/repoquery based queries
> to examine what is installed and what is available. Has that been
> done yet?
Yes. No duplicates at all - but how would that help in understanding the
cause of the hang?
>
>> As has been suggested several times
>> already, I think you will be best off doing a clean install.
> Only if there is no interest in fixing an otherwise still working
> installation. ;-)
I do not mean to draw any fire here, so please withhold you ire  :) :)
Just my $.02's worth of some thoughts ....

So far it seems to me that yum and dnf's internal operations,
being run by interpreted languages with many modules, it makes it
difficult, to say the least, to run a trace, such that one can see where
the failures occur (in what function, with what args), and where the
hangs occur, and what the values of the args are at the hang or failure 
points.
This is why I think binaries that are not stripped and not compiled with any
optimization, are ideal for implementing within them verbose debugging,
especially at critical points, within the source code.

Such debugging is ideal, but I understand, not always practical.



More information about the users mailing list