Red Hat Bugzilla – Bug 103162
up2date on via mini-itx for glibc selects wrong arch and causes stack trace
Last modified: 2007-04-18 12:57:10 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: Upon trying to use up2date to upgrade XFree86 which requires a newer glibc it selects the incorrect arch for glibc. I have confirmed up2date will install and upgrade a non-multi arch package: up2date lynx (install) up2date mutt (upgrade) [paul@babel paul]$ uname -a Linux babel.eridu 2.4.21-20.1.2024.2.1.nptl #1 Fri Jul 11 05:55:25 EDT 2003 i686 i686 i386 GNU/Linux [paul@babel paul]$ rpm --qf='%{arch}\n' -q glibc i386 [paul@babel paul]$ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 533.357 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1064.96 Version-Release number of selected component (if applicable): up2date-3.9.14-2 How reproducible: Always Steps to Reproduce: 1. Install severn on mini-itx platform 2. Subscribe to rhn 3. Ensure that redhat 9.0.93 updates subchannel is subscribed to in rhn 3. run up2date glibc Actual Results: Traceback (most recent call last): File "/usr/sbin/up2date", line 1148, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 747, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 1014, in batchRun batch.run() File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 76, in run self.__installPackages() File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 145, in __installPackages self.kernelsToInstall = up2date.installPackages(self.packagesToInstall, self.rpmCallback) File "/usr/share/rhn/up2date_client/up2date.py", line 717, in installPackages runTransaction(ts, rpmCallback, rollbacktrans = rollbacktrans) File "/usr/share/rhn/up2date_client/up2date.py", line 622, in runTransaction rpmUtils.runTransaction(ts,rpmCallback, transdir) File "/usr/share/rhn/up2date_client/rpmUtils.py", line 482, in runTransaction "Failed running transaction of packages: %s") % errors, deps=rc) up2date_client.up2dateErrors.TransactionError: RPM error. The message was: Failed running transaction of packages: ('package glibc-2.3.2-71 is intended for a i686 architecture', (0, 'i686', 0L)) Expected Results: i386 package should be selected. The fact it fails on i686 is good Additional info: I imagine this is somewhere in the subarch comparison stuff in rpm.
*** Bug 103183 has been marked as a duplicate of this bug. ***
*** Bug 103182 has been marked as a duplicate of this bug. ***
*** Bug 103175 has been marked as a duplicate of this bug. ***
*** Bug 103174 has been marked as a duplicate of this bug. ***
*** Bug 103173 has been marked as a duplicate of this bug. ***
*** Bug 103172 has been marked as a duplicate of this bug. ***
*** Bug 103171 has been marked as a duplicate of this bug. ***
*** Bug 103166 has been marked as a duplicate of this bug. ***
*** Bug 103170 has been marked as a duplicate of this bug. ***
*** Bug 103163 has been marked as a duplicate of this bug. ***
*** Bug 103164 has been marked as a duplicate of this bug. ***
*** Bug 103165 has been marked as a duplicate of this bug. ***
*** Bug 103167 has been marked as a duplicate of this bug. ***
*** Bug 103168 has been marked as a duplicate of this bug. ***
*** Bug 103169 has been marked as a duplicate of this bug. ***
Created attachment 93985 [details] test script to test arch detection code This is a small python script to test arch detection.
can you grab the attached "testarch.py" and run it on that machine and paste the results into this bug report?
noarch: 4 i386: 3 i486: 2 i586: 1 i686: 0 athlon: 0 blippy: 0 Oh and sorry for all the excess mails
hmm, arch scoring seems to be working okay must be something in my code, investigating
I'm guessing that only the ia64 version of glibc-common is installed?
[paul@babel paul]$ rpm --qf '%{arch}\n' -q glibc-common glibc i386 i386 It's a via eden processor. The only obvious place that has non i386 is kernel [paul@babel paul]$ rpm --qf '%{arch}\n' -q kernel i586 So anaconda has done the right thing, rpm sees the right archs but something between up2date/rhn seems odd
ignore the ia64 comment, I posted to the wrong bug
*** Bug 103390 has been marked as a duplicate of this bug. ***
just out of curiousity, whats the contents of /etc/rpm/platform?
i586-redhat-linux in my case. The newer up2date us showing different behaviour - updates from yum which have an i686 version are not shown at all. If they are added as implied requirements then it gets the i686 and blows up
i586-redhat-linux here too :) I thought this may be related to issues in 103559 so thought I'd test 3.9.22 (Alan why don't you try this with a yum repo rather than rhn) It now doesn't pick up the glibc upgrade: [paul@babel paul]$ rpm -q up2date up2date-3.9.22-2 rpm -q glibc glibc-2.3.2-57 [paul@babel paul]$ sudo up2date -l | grep glibc glibc-common 2.3.2 78 glibc-devel 2.3.2 78 glibc-kernheaders 2.4 8.24 [paul@babel paul]$ sudo up2date --showall | grep glibc glibc-2.3.2-78 glibc-common-2.3.2-78 glibc-debug-2.3.2-78 glibc-devel-2.3.2-78 glibc-kernheaders-2.4-8.24 glibc-profile-2.3.2-78 glibc-utils-2.3.2-78 ls /var/spool/up2date/glibc-2*hdr /var/spool/up2date/glibc-2.3.2-71.i686.hdr /var/spool/up2date/glibc-2.3.2-78.i686.hdr up2date --get glibc fetches 2.3.3-78.i686. Someting seems odd here, it looks as if the i686 addition is fixed but something else is broken redhat-linux-severn-i386-9.0.93-updates.20030902103453 has xml entries for both i386 and i686 glibc for 2.3.2-78.
I can confirm up2date-3.9.24-1 from p.r.c fixes this - via box now correctly selects glibc for i386. Cheers Paul
Works for me now except for one weird case. If I have the cache shared and an i686 package is downloaded the up2date tool tries to use that, if I have the cache blank of the i686.rpm it does the right thing. Alan
shared caches are unsupported (ie, completely untested though off hand I don't know of anything that _should_ break). I'll see if I can duplicate if I get a chance, probabaly something simple.
As this has been parked on modified for a while, I'd like to close this bug. Is shared cache still an issue for up2date 4.1.7, if so I will open a new bug/rfe for that and close this one.
Closing will try to reproduce shared cache issue and refile