Bug 102397 - up2date on Cyrix installs *686* kernel, should install *386*
up2date on Cyrix installs *686* kernel, should install *386*
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-08-14 14:38 EDT by Need Real Name
Modified: 2007-04-18 12:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-18 15:51:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test script to test rpm's arch detection code (171 bytes, text/plain)
2003-08-14 15:02 EDT, Adrian Likins
no flags Details

  None (edit)
Description Need Real Name 2003-08-14 14:38:32 EDT
Description of problem:
up2date chooses to install the wrong kernel when running up2date -fu
Platform is an old Cyrix system that does not have support for PGE.
   After an up2date run, the new boot kernel reports the linke
   Kernel compiled for PPro+, requires PGE feature.
up2date log shows that the 686 kernel was installed (determined by
seeing that up2date deleted the *686* rpms from the /var/spool/up2date
directory after the upgrade.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Get an old Cyrix platform
2. Install stock RedHat 8.0 out of the box
3. configure up2date
4. run up2date -u
5. run up2date -fu
6. reboot
Actual results:

Expected results:

Additional info:
In addition...the correct kernel numbering should be
2.4.20-19.9 (according to the downloaded replacement kernel)
but all references in the rpm database, uname, etc. show
2.4.20-19.8 (this makes things a tad confusing to confirm
the correct kernel is actually installed).

rpm -e *newkernel*
rpm -ivh *replacement kernel*
with appropriate reconfiguration of lilo, etc. works, after
making sure that the *386* version of the kernel is downloaded
from the appropriate locations.

# cat /proc/cpuinfo
processor       : 0
vendor_id       : CyrixInstead
cpu family      : 6
model           : 1
model name      : 6x86MX 2x Core/Bus Clock
stepping        : 3
cpu MHz         : 150.005
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : yes
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 cmov mmx cyrix_arr
bogomips        : 299.00
Comment 1 Adrian Likins 2003-08-14 15:02:43 EDT
Created attachment 93647 [details]
test script to test rpm's arch detection code

This is a test script to test the arch detection code.
Comment 2 Adrian Likins 2003-08-14 15:03:48 EDT
I added a test script as an attechment to this bug. Could you
download it and execute it as:

       python testarch.py

and send me the results?
Comment 3 Adrian Likins 2003-08-14 15:17:43 EDT
(from the bug reporter)

#cat test.py

import rpm

x86_arches = ['i386', 'i486', 'i586', 'i686', 'athlon']

for arch in x86_arches:
         print "score for %s: %s" % (arch, rpm.archscore(arch))

# ./test.py
score for i386: 4
score for i486: 3
score for i586: 2
score for i686: 1
score for athlon: 0
Comment 4 Adrian Likins 2003-08-14 15:18:52 EDT
Looks to be a bug with the arch detection code in rpm. Changing
component to rpm.
Comment 5 Jeff Johnson 2003-08-18 15:51:53 EDT
Probably a bug, but -- without the hardware to test -- rpm
cannot detect the arch correctly, hence WONTFIX.

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