Bug 103162

Summary: up2date on via mini-itx for glibc selects wrong arch and causes stack trace
Product: [Retired] Red Hat Raw Hide Reporter: Paul Nasrat <nobody+pnasrat>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED CURRENTRELEASE QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: alan
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 3.9.24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-29 12:24:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100643    
Attachments:
Description Flags
test script to test arch detection code none

Description Paul Nasrat 2003-08-27 10:56:09 UTC
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.

Comment 1 Paul Nasrat 2003-08-27 12:52:59 UTC
*** Bug 103183 has been marked as a duplicate of this bug. ***

Comment 2 Paul Nasrat 2003-08-27 12:53:41 UTC
*** Bug 103182 has been marked as a duplicate of this bug. ***

Comment 3 Paul Nasrat 2003-08-27 12:54:20 UTC
*** Bug 103175 has been marked as a duplicate of this bug. ***

Comment 4 Paul Nasrat 2003-08-27 12:54:59 UTC
*** Bug 103174 has been marked as a duplicate of this bug. ***

Comment 5 Paul Nasrat 2003-08-27 12:55:35 UTC
*** Bug 103173 has been marked as a duplicate of this bug. ***

Comment 6 Paul Nasrat 2003-08-27 12:56:18 UTC
*** Bug 103172 has been marked as a duplicate of this bug. ***

Comment 7 Paul Nasrat 2003-08-27 12:56:53 UTC
*** Bug 103171 has been marked as a duplicate of this bug. ***

Comment 8 Paul Nasrat 2003-08-27 12:57:41 UTC
*** Bug 103166 has been marked as a duplicate of this bug. ***

Comment 9 Paul Nasrat 2003-08-27 12:58:39 UTC
*** Bug 103170 has been marked as a duplicate of this bug. ***

Comment 10 Paul Nasrat 2003-08-27 12:59:24 UTC
*** Bug 103163 has been marked as a duplicate of this bug. ***

Comment 11 Paul Nasrat 2003-08-27 13:00:00 UTC
*** Bug 103164 has been marked as a duplicate of this bug. ***

Comment 12 Paul Nasrat 2003-08-27 13:00:46 UTC
*** Bug 103165 has been marked as a duplicate of this bug. ***

Comment 13 Paul Nasrat 2003-08-27 13:01:18 UTC
*** Bug 103167 has been marked as a duplicate of this bug. ***

Comment 14 Paul Nasrat 2003-08-27 13:01:57 UTC
*** Bug 103168 has been marked as a duplicate of this bug. ***

Comment 15 Paul Nasrat 2003-08-27 13:02:36 UTC
*** Bug 103169 has been marked as a duplicate of this bug. ***

Comment 16 Adrian Likins 2003-08-27 18:46:58 UTC
Created attachment 93985 [details]
test script to test arch detection code

This is a small python script to test arch detection.

Comment 17 Adrian Likins 2003-08-27 18:48:19 UTC
can you grab the attached "testarch.py" and run it on that machine
and paste the results into this bug report?

Comment 18 Paul Nasrat 2003-08-27 18:52:22 UTC
noarch: 4
i386: 3
i486: 2
i586: 1
i686: 0
athlon: 0
blippy: 0

Oh and sorry for all the excess mails

Comment 19 Adrian Likins 2003-08-27 19:03:25 UTC
hmm, arch scoring seems to be working okay

must be something in my code, investigating

Comment 20 Adrian Likins 2003-08-27 19:45:31 UTC
I'm guessing that only the ia64 version of glibc-common is installed?



Comment 21 Paul Nasrat 2003-08-27 20:25:53 UTC
[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

Comment 22 Adrian Likins 2003-08-29 23:08:19 UTC
ignore the ia64 comment, I posted to the wrong bug

Comment 23 Adrian Likins 2003-08-29 23:08:34 UTC
*** Bug 103390 has been marked as a duplicate of this bug. ***

Comment 24 Adrian Likins 2003-09-02 17:43:05 UTC
just out of curiousity, whats the contents of /etc/rpm/platform?

Comment 25 Alan Cox 2003-09-02 22:40:54 UTC
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


Comment 26 Paul Nasrat 2003-09-03 05:44:42 UTC
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.

Comment 27 Paul Nasrat 2003-09-06 06:01:26 UTC
I can confirm up2date-3.9.24-1 from p.r.c fixes this - via box now correctly
selects glibc for i386.

Cheers

Paul



Comment 28 Alan Cox 2003-09-06 12:29:40 UTC
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


Comment 29 Adrian Likins 2003-09-09 18:43:44 UTC
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. 

Comment 30 Paul Nasrat 2003-10-22 16:13:30 UTC
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.

  

Comment 31 Paul Nasrat 2003-10-29 12:24:19 UTC
Closing will try to reproduce shared cache issue and refile