Created attachment 1631059 [details] Screenshot of non working Updates (takes forever) Description of problem: PackageKit breaks gnome-software. No more updates and upgrades are available. Installed packages are also not available. Downgrading to PackageKit-1.1.12-5.fc30.x86_64 fixes the problem. Version-Release number of selected component (if applicable): PackageKit-1.1.12-6.fc30.x86_64 How reproducible: Always Steps to Reproduce: 1. Try using gnome-software 2. 3. Actual results: gnome-software is unusable Expected results: gnome-software should be working (especially now for the f31 upgrade) Additional info:
Can you attach some logs, please? Multiple people tested this update and reported it good: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2368fc415f
Created attachment 1631090 [details] log of $ killall gnome-software && gnome-software --verbose >> gnome-software.log (here ist gnome-software hanging forever) P.S: This bug happens on different f30-machines i saw.
Fedora 31 with PackageKit-1.1.12-11.fc31.x86_64 is not affected.
I can't spot anything wrong in the gnome-software log. I assume it must be packagekitd crashing. Can you run pkmon on another terminal while attempting to use gnome-software and see what it says? Anything in system journal (packagekitd crashing or error messages)? Anything non-standard on your system, like modular repos disabled or something along those lines?
Created attachment 1631362 [details] pkmon.log (from starting to hanging of gnome-software)
I don't see anything out of ordinary in the pkmon.log either.
This is strange: I have made a test system with a newly installed fedora 30 and made it up to date. No problems her. But in all (actually four) fedora 30 systems that have been running for some time (at least since the last release), the bug exists, and only downgrading to PackageKit-1.1.12-5.fc30.x86_64 fixes the problem.
Steve, please post the output of "dnf repolist". I don't know if it is the same bug, but I can reproduce this on my system where I have modular repos disabled. Gnome Software shows an infinite spinner in Installed and Updates tab. Turns out PackageKit crashes: Nov 01 13:54:34 phoenix packagekitd[3332]: terminate called after throwing an instance of 'libdnf::ModulePackageContainer::NoModuleException' Nov 01 13:54:34 phoenix packagekitd[3332]: what(): No such module: libgit2 Nov 01 13:54:34 phoenix systemd[1]: packagekit.service: Main process exited, code=killed, status=6/ABRT Nov 01 13:54:34 phoenix systemd[1]: packagekit.service: Failed with result 'signal'. If I enable modular repos (and restart packagekit and kill gnome-software), everything starts working. While having modular repos disable is a non-default configuration, it is not unreasonable to expect many people to have them disabled because of what a mess modularity has been and is. Also, by having them separate from the standard repos it hints that they are not mandatory (I know that Stephen Gallagher claims the opposite).
Created attachment 1631456 [details] backtrace from abrt ABRT claims the crash has "low informational value" and can't be reported. Here's the backtrace file attached from its directory.
Of course, I have modular repos disabled: $ dnf repolist repo id repo name status *fedora Fedora 30 - x86_64 56,697 *rpmfusion-free RPM Fusion for Fedora 30 - Free 616 *rpmfusion-free-updates RPM Fusion for Fedora 30 - Free - Updates 290 *rpmfusion-nonfree RPM Fusion for Fedora 30 - Nonfree 227 *rpmfusion-nonfree-updates RPM Fusion for Fedora 30 - Nonfree - Updates 68 *updates Fedora 30 - x86_64 - Updates 13,746 (This should not make gnome-software unusable) After enable it, PakageKit and/or gnome-software works again.
> Nov 01 13:54:34 phoenix packagekitd[3332]: terminate called after throwing an instance of 'libdnf::ModulePackageContainer::NoModuleException' > Nov 01 13:54:34 phoenix packagekitd[3332]: what(): No such module: libgit2 This is an uncaught exception in libdnf. Instead of crashing, libdnf should report the error through the GError that packagekit passes to it. Moving to libdnf.
libdnf head has a commit to fix a similar issue reported in RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=1761773 https://github.com/rpm-software-management/libdnf/commit/dfa58beddd20fc051ba129d01da7ff19d3b870bb anyone want to check if that helps here?
Hum, something else worries me about this, though - the hack should only do *anything* if we're upgrading and releasever is 31. So why is this happening just by running g-s on F30? It implies the code from the hack is Doin' Stuff when it shouldn't be...
scratch build running: https://koji.fedoraproject.org/koji/taskinfo?taskID=38711657
(In reply to Adam Williamson from comment #13) > Hum, something else worries me about this, though - the hack should only do > *anything* if we're upgrading and releasever is 31. So why is this happening > just by running g-s on F30? It implies the code from the hack is Doin' Stuff > when it shouldn't be... I assume it's gnome-software calling this in the background to download repo metadata and see if an upgrade is available.
so, does that mean when the modular repos are enabled, just running g-s at all after installing the update will reset the libgit2 module? I mean...it's probably not a big deal. But it's not exactly what we intended I don't think.
I am not sure; depends on what exactly dnf_context_reset_modules() does. Does it reset the modules globally, or just for the F31 upgrade context/sack without affecting the currently running distro? If it's the latter then we could try to limit this a bit and only call dnf_context_reset_modules() from packagekit when the user presses "Download" in the gnome-software UI and not when doing the repo metadata download in the background.
> If it's the latter Err, I meant "former" here.
I think it was originally the latter, but it got changed to the former because the latter didn't seem to work (I assume because we never exactly *execute* the transaction we generate during the download phase): https://github.com/rpm-software-management/libdnf/commit/9a44bbb541be4df6e24f249e3f839d94510d3189
(In reply to Adam Williamson from comment #14) > scratch build running: > https://koji.fedoraproject.org/koji/taskinfo?taskID=38711657 These packages doesn't work/fix the bug of gnome-software
d'oh. confirmed here. so we need to catch it somewhere else, obvs...
OK, try this one: https://koji.fedoraproject.org/koji/taskinfo?taskID=38713594 that works for me.
(In reply to Adam Williamson from comment #22) > OK, try this one: > https://koji.fedoraproject.org/koji/taskinfo?taskID=38713594 > > that works for me. Yes, I can confirm that these packages are working with modular repos disabled.
FEDORA-2019-9f137540c5 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9f137540c5
FEDORA-2019-96e3a96a5e has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-96e3a96a5e
libdnf-0.35.5-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9f137540c5
libdnf-0.31.0-9.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-96e3a96a5e
(In reply to Fedora Update System from comment #24) > FEDORA-2019-9f137540c5 has been submitted as an update to Fedora 30. > https://bodhi.fedoraproject.org/updates/FEDORA-2019-9f137540c5 I can confirm this fixes the problem for me as well. Packagekit no longer crashes when modular repos are disabled.
libdnf-0.35.5-5.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
libdnf-0.31.0-10.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dc3b5542ad
libdnf-0.31.0-10.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
don't think this needs a commonbugs note any more.