Bug 103162 - up2date on via mini-itx for glibc selects wrong arch and causes stack trace
up2date on via mini-itx for glibc selects wrong arch and causes stack trace
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: up2date (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
: 103163 103164 103165 103166 103167 103168 103169 103170 103171 103172 103173 103174 103175 103182 103183 103390 (view as bug list)
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-08-27 06:56 EDT by Paul Nasrat
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version: 3.9.24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-29 07:24:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test script to test arch detection code (146 bytes, text/plain)
2003-08-27 14:46 EDT, Adrian Likins
no flags Details

  None (edit)
Description Paul Nasrat 2003-08-27 06:56:09 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.
Comment 1 Paul Nasrat 2003-08-27 08:52:59 EDT
*** Bug 103183 has been marked as a duplicate of this bug. ***
Comment 2 Paul Nasrat 2003-08-27 08:53:41 EDT
*** Bug 103182 has been marked as a duplicate of this bug. ***
Comment 3 Paul Nasrat 2003-08-27 08:54:20 EDT
*** Bug 103175 has been marked as a duplicate of this bug. ***
Comment 4 Paul Nasrat 2003-08-27 08:54:59 EDT
*** Bug 103174 has been marked as a duplicate of this bug. ***
Comment 5 Paul Nasrat 2003-08-27 08:55:35 EDT
*** Bug 103173 has been marked as a duplicate of this bug. ***
Comment 6 Paul Nasrat 2003-08-27 08:56:18 EDT
*** Bug 103172 has been marked as a duplicate of this bug. ***
Comment 7 Paul Nasrat 2003-08-27 08:56:53 EDT
*** Bug 103171 has been marked as a duplicate of this bug. ***
Comment 8 Paul Nasrat 2003-08-27 08:57:41 EDT
*** Bug 103166 has been marked as a duplicate of this bug. ***
Comment 9 Paul Nasrat 2003-08-27 08:58:39 EDT
*** Bug 103170 has been marked as a duplicate of this bug. ***
Comment 10 Paul Nasrat 2003-08-27 08:59:24 EDT
*** Bug 103163 has been marked as a duplicate of this bug. ***
Comment 11 Paul Nasrat 2003-08-27 09:00:00 EDT
*** Bug 103164 has been marked as a duplicate of this bug. ***
Comment 12 Paul Nasrat 2003-08-27 09:00:46 EDT
*** Bug 103165 has been marked as a duplicate of this bug. ***
Comment 13 Paul Nasrat 2003-08-27 09:01:18 EDT
*** Bug 103167 has been marked as a duplicate of this bug. ***
Comment 14 Paul Nasrat 2003-08-27 09:01:57 EDT
*** Bug 103168 has been marked as a duplicate of this bug. ***
Comment 15 Paul Nasrat 2003-08-27 09:02:36 EDT
*** Bug 103169 has been marked as a duplicate of this bug. ***
Comment 16 Adrian Likins 2003-08-27 14:46:58 EDT
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 14:48:19 EDT
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 14:52:22 EDT
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 15:03:25 EDT
hmm, arch scoring seems to be working okay

must be something in my code, investigating
Comment 20 Adrian Likins 2003-08-27 15:45:31 EDT
I'm guessing that only the ia64 version of glibc-common is installed?

Comment 21 Paul Nasrat 2003-08-27 16:25:53 EDT
[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 19:08:19 EDT
ignore the ia64 comment, I posted to the wrong bug
Comment 23 Adrian Likins 2003-08-29 19:08:34 EDT
*** Bug 103390 has been marked as a duplicate of this bug. ***
Comment 24 Adrian Likins 2003-09-02 13:43:05 EDT
just out of curiousity, whats the contents of /etc/rpm/platform?
Comment 25 Alan Cox 2003-09-02 18:40:54 EDT
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 01:44:42 EDT
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 02:01:26 EDT
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 08:29:40 EDT
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 14:43:44 EDT
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 12:13:30 EDT
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 07:24:19 EST
Closing will try to reproduce shared cache issue and refile

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