Bug 40591 - After downgrading to i386 glibc from i686 glibc
Summary: After downgrading to i386 glibc from i686 glibc
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-14 23:50 UTC by Dax Kelson
Modified: 2016-11-24 15:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-01 22:31:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dax Kelson 2001-05-14 23:50:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
I installed Red Hat 7.1 on a Pentium II computer.  I installed the "i386"
kernel.  I moved the harddrive to a computer with an AMD K6 cpu.  No
application would run (even /sbin/init, preventing a boot).

I moved the hard drive back to the pentium II computer, and installed the
"i386" version of glibc like this:

rpm -Uvh glibc-foo-.i386.rpm --force

After I did the above, applications were STILL linked against libs in the
/lib/i686 directory.

The fix was to "mv /lib/i686 /lib/i686-bad; ldconfig"

After that, I moved the harddrive back to the K6 computer and everything

How reproducible:
Didn't try

Additional info:

Comment 1 Jakub Jelinek 2001-06-06 10:16:39 UTC
The important question is: have you tried the disk in the AMD box after
rpm -Uvh glibc-*.i386.rpm --force? The forced upgrade left /lib/i686 in, sure,
but on AMD K6 box (which I believe does not report i686 in uname, right?)
the dynamic linker should not ever use libraries in /lib/i686, just those in

Comment 2 Dax Kelson 2001-06-06 15:56:47 UTC
Yes, I moved it back to the AMD box AFTER I did the "rpm -Uvh glibc-*.i386rpm --force".  And 
it was still broken.  No application would run.  In fact, the box would hang at boot time, because 
/sbin/init wouldn't work.

Here is a SysRq-t during the "hang at boot":

SysRq : Show State
                         free                        sibling
  task             PC    stack   pid father child younger older
init      R current      0     1      0    11  (NOTLB)
Call Trace: [<c01075e0>] [<c0106dc4>]
keventd   S C0246F00     0     2      1        (L-TLB)       3
Call Trace: [<c011e155>] [<c011e070>] [<c0105000>] [<c01054b6>]
kswapd    S C3F040A0     0     3      1        (L-TLB)       4     2
Call Trace: [<c0110c1d>] [<c0110b50>] [<c0111191>] [<c01289a1>]
   [<c0105000>] [<c01054b6>] [<c01288d0>]
kreclaimd  S C0246F00     0     4      1        (L-TLB)       5     3
Call Trace: [<c011112c>] [<c0128a8a>] [<c0105000>] [<c01054b6>]
bdflush   S C0246F00     0     5      1        (L-TLB)       6     4
Call Trace: [<c01323c4>] [<c01054b6>] [<c01322f0>]
kupdated  S C3F040A0     0     6      1        (L-TLB)      10     5
Call Trace: [<c0110c1d>] [<c0110b50>] [<c0132454>] [<c01054b6>]
mdrecoveryd  S C0246F00     0    10      1        (L-TLB)      11     6
Call Trace: [<c01c1887>] [<c01054b6>] [<c01c17e0>]
kreiserfsd  S C3F040A0     0    11      1        (L-TLB)            10
Call Trace: [<c0110c1d>] [<c0110b50>] [<c0111191>] [<c016fb46>]
   [<c01054b6>] [<c016faa0>]

Comment 3 Ulrich Drepper 2003-10-03 09:28:27 UTC
glibc takes its information from the kernel.  If

  LD_SHOW_AUXV=1 /bin/echo

shows i686 for AT_PLATFORM and the machine cannot handle i686 ops, then the
kernel is at fault.

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