Bug 660730 - yum localupdate crashes on setup and glibc-common
Summary: yum localupdate crashes on setup and glibc-common
Keywords:
Status: CLOSED DUPLICATE of bug 652702
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 14
Hardware: Unspecified
OS: Linux
low
high
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-07 17:12 UTC by Juhani Jaakola
Modified: 2014-01-21 23:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-08 07:00:20 UTC


Attachments (Terms of Use)

Description Juhani Jaakola 2010-12-07 17:12:51 UTC
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

Comment 1 seth vidal 2010-12-07 17:17:27 UTC
Does the same error happen for the pkg setup too?

are you seeing any other disk or memory related errors on this system?

Comment 2 James Antill 2010-12-07 17:21:02 UTC
Also can you run:

md5sum glibc*.rpm

Comment 3 Juhani Jaakola 2010-12-07 17:34:04 UTC
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

Comment 4 seth vidal 2010-12-07 17:44:49 UTC
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?

Comment 5 Juhani Jaakola 2010-12-07 17:58:02 UTC
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?

Comment 6 James Antill 2010-12-07 18:08:11 UTC
 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.

Comment 7 Juhani Jaakola 2010-12-07 20:32:07 UTC
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?

Comment 8 Panu Matilainen 2010-12-08 07:00:20 UTC
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 ***


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