Hide Forgot
Description of problem: I had to upgrade several PCs from Fedora 13 to 14, so I used yumdownloader to download latest updates, and after upgrading with the Fedora 14 DVD I used "yum localupdate glibc-*.rpm" to install the latest updates. But in this case yum crashes: Updating: glibc i686 2.12.90-19 /glibc-2.12.90-19.i686 13 M glibc-common i686 2.12.90-19 /glibc-common-2.12.90-19.i686 107 M glibc-devel i686 2.12.90-19 /glibc-devel-2.12.90-19.i686 958 k glibc-headers i686 2.12.90-19 /glibc-headers-2.12.90-19.i686 2.1 M Transaction Summary ================================================================================ Upgrade 4 Package(s) Total size: 123 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : glibc-2.12.90-19.i686 1/8 Error: Cannot open file glibc-common-2.12.90-19.i686.rpm: [Errno 2] No such file or directory: 'glibc-common-2.12.90-19.i686.rpm' TypeError: an integer is required error: python callback <bound method RPMTransaction.callback of <yum.rpmtrans.RPMTransaction instance at 0xad4436c>> failed, aborting! After the crash the system has both the old and new packages of those packages before the crashing package. So in this case my system contained both the old and new versions of package glibc. If I try to localupdate a large set of packages which contains package "setup", the localupdate will fail on "setup". But if I localupdate only "setup", then the localupdate succeeds! Version-Release number of selected component (if applicable): yum-3.2.28-5.fc14.noarch rpm-4.8.1-5.fc14.i686 How reproducible: - Every time on three PCs which I have upgraded Steps to Reproduce: 1. yum localupdate glibc-*.rpm (after upgrading from Fedora 13 with the DVD) Actual results: - See above Expected results: - localupdate should succeed Additional info: - This happened also when I used "yum localupdate" after upgrading from Fedora 12 to 13
Does the same error happen for the pkg setup too? are you seeing any other disk or memory related errors on this system?
Also can you run: md5sum glibc*.rpm
I have used only yum, not the other tools. I have experienced this error on three different PCs. Those PCs do not have any disk or memory related errors. The rpm files must be OK, because I can recover from the crash by issuing "yum shell" and then erasing the old version of glibc and localupdating the four glibc-*.rpm files in one transaction. But here are the md5sums anyway: $ md5sum glibc-*.rpm a63c119960c01722aafa175ec59b6971 glibc-2.12.90-19.i686.rpm d3b6fac8dc31cda06de9d59ce22740fe glibc-common-2.12.90-19.i686.rpm dccb79d129aad7c7f543bb2532606134 glibc-devel-2.12.90-19.i686.rpm 3d11ab50843df7de45fb7b157ab77557 glibc-headers-2.12.90-19.i686.rpm
so the error only happens when you have 2 versions of glibc listed as 'installed' in the rpmdb? can you run: rpm -qa glibc on one of the affected systems?
No, please see the original bug description. Initially (before executing "yum localupdate glibc-*.rpm") I have only one version of glibc. After the crash I have two versions of glibc (the original one and the new one) because yum has no chance of cleaning up the old version after it has crashed. After I execute "yum shell" and erase the old glibc and localupdate the new four glibc* packages, I have only one glibc installed. So the problem is, why does "yum localupdate glibc-*.rpm" crash? And why does localupdate of "setup" crash when it is part of a localupdate of several rpm files?
The problem is we are having a hard time seeing what the problem might be, basically you seem to be saying: 1. Run: yum localupdate foo bar baz == fails 2. Run: yum shell, remove old-fool; update foo bar baz == succeeds ...but, for the failing code in question, both of the above should produce identical results. Which leaves us trying to make assumptions about what changed between #1 and #2. If you can reproduce this, it might be worth putting a bunch of debugging in rpmtrans.py:_instOpenFile ... and seeing what, if any, differences there are.
Let me clarify: First I execute "yum localupdate glibc-*.rpm", which fails. This leaves my RPM database in an inconsistent state: if I re-execute the command, it prints error message "glibc-<new version> is already installed" (or something like that, I don't remember exactly any more). In order to recover from that, I have to execute "yum shell". So the "yum shell" is just my way of getting out of inconsistent state that "yum localupdate glibc-*.rpm" left me. I have yet another machine to upgrade, how exactly do you want me to modify rpmtrans.py?
This is a dupe of bug 652702, but the case here points out the reproducer nicely: it only happens when the update argument(s) are non-absolute local paths, which explains why it wasn't blowing up for everybody. *** This bug has been marked as a duplicate of bug 652702 ***