Bug 1002494

Summary: yum crashes
Product: [Fedora] Fedora Reporter: Daniel <daniel>
Component: yumAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 19CC: admiller, ffesti, firas.alkafri, jzeleny, packaging-team-maint, tim.lauridsen, zpavlas
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-29 11:54:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logbook none

Description Daniel 2013-08-29 10:27:13 UTC
Description of problem:

When installing or updating system, yum crashes and forces in most cases the system to reboot. I used the same machine (i7-3960X, 64 GB RAM, system on software raid) for more than one year now and until July, 20 it worked fine with different versions of Fedora and yum. A week ago I returned, made some "uge update" and then it didn't work anymore.

Yum crashes when getting the file lists from the servers of the repositories via
"/usr/bin/python /usr/libexec/urlgrabber-ext-down", ... etc.

Usually I start the command "yum clean all && yum update -y -x emacs -x emacs-common" or just "yum clean all && yum update -y" since I added the line "exclude=emacs emacs-common" in my /etc/yum.conf.
Strange enough, when stracing the whole procedure it goes through.
I also tried to repair the rpmdb in /var/lib/rpm. Nothing worked.

Today I've tried "strace -o /tmp/logbook yum provides "*/(libgphoto)""
and I've got

(process:2224): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Parsing filelists.xml error: Start tag expected, '<' not found

Traceback (most recent call last):
  File "/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 316, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 126, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 532, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 1503, in doCommand
    return base.provides(extcmds)
  File "/usr/share/yum-cli/cli.py", line 1516, in provides
    callback_has_matchfor=True)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3324, in searchPackageProvides
    where = self.pkgSack.searchProvides(arg)
  File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 422, in searchProvides
    return self._computeAggregateListResult("searchProvides", name)
  File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 595, in _computeAggregateListResult
    sackResult = apply(method, args)
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 1404, in searchProvides
    ret = self.searchPrco(name, "provides")
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 46, in newFunc
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 1397, in searchPrco
    results.extend(self.searchFiles(n))
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 46, in newFunc
    return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 934, in searchFiles
    self.populate(repo, mdtype='filelists')
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 260, in populate
    dobj = repo_cache_function(xml, csum)
  File "/usr/lib64/python2.7/site-packages/sqlitecachec.py", line 54, in getFilelists
    self.repoid))
TypeError: Parsing filelists.xml error: Document is empty


So this may be also a python problem.


Version-Release number of selected component (if applicable):

[root@bl4ckh0l3 ~]# rpm -qa | sort | grep -i yum
PackageKit-yum-0.8.9-6.fc19.x86_64
PackageKit-yum-plugin-0.8.9-6.fc19.x86_64
yum-3.4.3-106.fc19.noarch
yumex-3.0.10-2.fc19.noarch
yum-langpacks-0.3.4-1.fc19.noarch
yum-metadata-parser-1.1.4-8.fc19.x86_64
yum-utils-1.1.31-17.fc19.noarch

Comment 1 Daniel 2013-08-29 10:36:16 UTC
Created attachment 791695 [details]
logbook

Comment 2 Zdeněk Pavlas 2013-08-29 11:14:04 UTC
Thanks, this is probably helpfull.

> stat("/var/cache/yum/x86_64/19/google-chrome/filelists.xml.gz", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> getxattr("/var/cache/yum/x86_64/19/google-chrome/filelists.xml.gz", "user.yum.checksum.sha", "85349e796d9b7fd8421d086976731a17faf1a5fe", 40) = 40

This is it.. When yum verifies the file has correct checksum, it sets an xattr, so it does not have to calculate the checksum later.  But here we see it's empty, but the checksum is set to the correct value.  I feel there might be some FS issue.. didn't fsck complain recently?

> stat("/var/cache/yum/x86_64/19/google-chrome/gen/filelists.xml", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

And the decompressed file is truncated, too.. but since both timestamps match, Yum does not bother decompressing, thus we don't compalin that filelists.xml.gz is not in gzip format, and crash later trying to parse the XML..

I think it might be worth adding a check/warn/unlink when we get correct cached checksum, but the file is empty.

Anyway, just unlink /var/cache/yum/x86_64/19/google-chrome/filelists.xml.gz and this problem should go away.. but we still don't know the root cause (what has truncated it).

Comment 3 Jan Zeleny 2013-08-29 11:54:46 UTC

*** This bug has been marked as a duplicate of bug 920401 ***

Comment 4 Daniel 2013-09-01 23:07:23 UTC
Ahoi Jan & Zdeněk :-)
My problem with yum is not really a yum/python problem. After several days of tracing the error I fond out that presumably a buggy version of xorg-x11-drv-nouveau forced my system to crash (submitted this to bug 1003314).
Thnx anyway!