Description of problem: Don't even know what this program is. Didn't see anything change. Version-Release number of selected component: dnf-0.4.14-1.fc20 Additional info: reporter: libreport-2.1.12 cmdline: /usr/bin/python /usr/bin/dnf -v makecache timer executable: /usr/bin/dnf kernel: 3.13.3-201.fc20.x86_64 runlevel: N 5 type: Python uid: 0 Truncated backtrace: base.py:138:_add_repo_to_sack:RuntimeException: load_yum_repo() failed: 3. Traceback (most recent call last): File "/usr/bin/dnf", line 35, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 242, in user_main errcode = main(args) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 124, in _main cli.run() File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1450, in run return self.command.run(self.base.extcmds) File "/usr/lib/python2.7/site-packages/dnf/cli/commands.py", line 823, in run self.base.fill_sack() # performs the md sync File "/usr/lib/python2.7/site-packages/dnf/base.py", line 214, in fill_sack self._add_repo_to_sack(r.id) File "/usr/lib/python2.7/site-packages/dnf/base.py", line 138, in _add_repo_to_sack load_presto=repo.deltarpm) RuntimeException: load_yum_repo() failed: 3. Local variables in innermost frame: repo: <Repo rpmfusion-free> hrepo: <_hawkey.Repo object at 0x7ff87c5fbea0> self: <dnf.cli.cli.BaseCli object at 0x1f14dd0> name: 'rpmfusion-free'
Created attachment 869114 [details] File: backtrace
Created attachment 869115 [details] File: environ
Please update to the latest build dnf-0.4.16-2.fc20 which should resolve your reported issue. You can get the binary rpms directly from http://koji.fedoraproject.org/koji/buildinfo?buildID=500714
This doesn't sound right. Why do you want me to go ourside the normal methods of upgrading to get to the stable release?
Hello, can you please attach /var/cache/dnf/x86_64/20/hawkey.log to this bug? Thank you.
*** Bug 1026035 has been marked as a duplicate of this bug. ***
Created attachment 869663 [details] hawkey.log Here it is.
The error seems to be: INFO Feb-25 16:42:42 using cached rpmfusion-free LSERROR Feb-25 16:42:42 type REL_IDARRAY is only supported for STORAGE_SOLVABLE LSERROR Feb-25 16:42:42 unsupported data type '<NULL>' LSERROR Feb-25 16:42:42 unsupported storage type 0 LSERROR Feb-25 16:42:42 unsupported data type '<NULL>' LSERROR Feb-25 16:42:42 unsupported storage type 0 LSERROR Feb-25 16:42:42 unsupported data type '<NULL>' LSERROR Feb-25 16:42:42 unsupported storage type 0 etc. Since the DNF version in comment 0 indicates the hawkey version is no larger then 0.4.9 I think we are seeing a dupe of bug 1047087. We should still improve the logging though to make this easier to confirm: adding hawkey version to the logging output and hashes of loaded cache files. Leaving this open for now. Also if the bug appears with hawkey-0.4.11 please let us know.
*** Bug 1082210 has been marked as a duplicate of this bug. ***
*** Bug 1087556 has been marked as a duplicate of this bug. ***
ericgmb: can you please attach the output of 'rpm -q hawkey' and /var/cache/dnf/x86_64/20/hawkey.log to this bug? Thanks!
hawkey-0.4.12-1.fc20.x86_64
Created attachment 886551 [details] hawkey.log
Thanks! This is odd: INFO Apr-13 16:40:56 using cached rpmfusion-free LSERROR Apr-13 16:40:56 overflow while expanding strings ERROR Apr-13 16:40:56 repo_add_solv() has failed. Michael, this is with a recent hawkey that does the saving atomically. The log also seems to eliminate the possibility of concurrent access to the file. Also, to use the cache we must have matched the checksum. What might we be looking at here? Hardware error? (the solv looks like it wasn't changed in the meantime and loaded OK 3 hours later) I am going to keep this open for now, I think we could use the .solv checksums in the logs. Also---we really should block the ABRT reports from the automatic systemd runs. Who knows what might be going on at the time of the runs (system shutting down, unmounting filesystems etc.).
This is very odd, I don't see how the same solv file can suddenly stop working and then later on be correct again. I also never got any report about something like this in the SUSE bugzilla.
Thanks, probably some weird system stage etc. Will add the things listed in comment 14 anyway.
64dda93 and de35c01 add the logging to improve chances of debugging issues like this in the future. Blocking error propagation from the automatic runs will be done in bug 1081753.
dnf-0.5.1-1.fc20, hawkey-0.4.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20
Package dnf-0.5.1-1.fc20, hawkey-0.4.14-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.5.1-1.fc20 hawkey-0.4.14-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5937/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20 then log in and leave karma (feedback).
*** Bug 1098481 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.