| Summary: | RuntimeException: load_yum_repo() failed: 3. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mikhail <mikhail.v.gavrilov> | ||||||||
| Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 20 | CC: | akozumpl, jzeleny, mikhail.v.gavrilov, packaging-team-maint, pnemade, rholy | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Unspecified | ||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/de23c1c71f55bd02985909b3923da25b9e7aaf65 | ||||||||||
| Whiteboard: | abrt_hash:0ec7a6727aa3f18beee2100646092dc0f91e7702 | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-03-02 08:51:35 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
Created attachment 818638 [details]
File: backtrace
Created attachment 818639 [details]
File: environ
Created attachment 818691 [details]
hawkey.log
Hi Mikhail, Can you please attach /var/cache/dnf/x86_64/20/hawkey.log? How many times have you seen this reported by ABRT? Thanks! > How many times have you seen this reported by ABRT?
Some times on different machines.
I am baffled by this bug. Can you say there is something special about those machines that experienced the bug (e.g. SELINUX policy, mounting /var/cache as a RAM disk, etc.?) I assume all of the machines are F20, yes? Also---when you run other dnf commands do they pass or show a similar traceback? what libsolv version are you using? (rpm -q libsolv) > I am baffled by this bug. Can you say there is something special about those machines that experienced the bug (e.g. SELINUX policy, mounting /var/cache as a RAM disk, etc.?) Happens only this: https://bugzilla.redhat.com/show_bug.cgi?id=1023749 > I assume all of the machines are F20, yes? yes > rpm -q libsolv libsolv-0.4.0-1.gitd49d319.fc20.x86_64 Very strange to see any problem with DNF because I still prefer YUM. 1) Yum support NTLM proxy 2) Yum much faster download rpm's # time dnf update Nothing to do. real 1m24.155s user 0m21.819s sys 0m9.004s # time yum update No packages marked for update real 0m49.231s user 0m7.114s sys 0m4.268s (In reply to Mikhail from comment #8) > Happens only this: > https://bugzilla.redhat.com/show_bug.cgi?id=1023749 That could be related because the load_yum_repo also tries to write out to a cache file. > Very strange to see any problem with DNF because I still prefer YUM. > 1) Yum support NTLM proxy > 2) Yum much faster download rpm's > > # time dnf update > Nothing to do. > > real 1m24.155s > user 0m21.819s > sys 0m9.004s This shouldn't be surprising if makecache is failing. No RPMs are downloaded here FWIW. Thanks for the information so far. I'll add more logging into hawkey so we can pin it down better. > No RPMs are downloaded here FWIW.
I know, but download speed of metadata same too slow :(
That's mainly because Yum does not (by default) download filelists immediately, but does that on demand. That's 2-3 times faster, but problematic if the repository gets updated in the meantime. To have a fair comparision, you'd have to set "mdpolicy=group:small,filelists" in yum.conf. 3a514f0 and 8a44efd in hawkey-0.4.5 improves logging of the loading functions. Mikhail, when you see this with hawkey-0.4.5, please attach hawkey.log to this bugzilla, along with the tail of /var/log/audit/audit.log. Because it is said in comment 8 that the user does not use DNF much this is probably not a race condition or similar. SELINUX is the smoking gun here. Closing this as a dupe of bug 1071404 which is going to stay more alive I hope. *** This bug has been marked as a duplicate of bug 1071404 *** |
Version-Release number of selected component: dnf-0.4.5-1.fc20 Additional info: reporter: libreport-2.1.9 cmdline: /usr/bin/python /usr/bin/dnf -v makecache timer executable: /usr/bin/dnf kernel: 3.11.6-301.fc20.x86_64+debug runlevel: N 5 type: Python uid: 0 Truncated backtrace: base.py:156:_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 272, 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 133, in _main result, resultmsgs = cli.run() File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1305, in run return self.command.doCommand(self.base.basecmd, self.base.extcmds) File "/usr/lib/python2.7/site-packages/dnf/cli/commands.py", line 1003, in doCommand self.base.activate_sack() # performs the md sync File "/usr/lib/python2.7/site-packages/dnf/base.py", line 228, in activate_sack self._add_repo_to_sack(r.id) File "/usr/lib/python2.7/site-packages/dnf/base.py", line 156, in _add_repo_to_sack self._sack.load_yum_repo(hrepo, build_cache=True, load_filelists=True) RuntimeException: load_yum_repo() failed: 3. Local variables in innermost frame: repo: <Repo fedora> hrepo: <_hawkey.Repo object at 0x11d10a8> self: <dnf.cli.cli.BaseCli object at 0xea9150> name: 'fedora'