Bug 1002494 - yum crashes
yum crashes
Status: CLOSED DUPLICATE of bug 920401
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
19
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-29 06:27 EDT by Daniel
Modified: 2013-09-01 19:07 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-29 07:54:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logbook (6.62 MB, application/x-gzip)
2013-08-29 06:36 EDT, Daniel
no flags Details

  None (edit)
Description Daniel 2013-08-29 06:27:13 EDT
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 06:36:16 EDT
Created attachment 791695 [details]
logbook
Comment 2 Zdeněk Pavlas 2013-08-29 07:14:04 EDT
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 07:54:46 EDT

*** This bug has been marked as a duplicate of bug 920401 ***
Comment 4 Daniel 2013-09-01 19:07:23 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.