Re: yum upgrade stuck

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.

--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux