Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 40591 - After downgrading to i386 glibc from i686 glibc
After downgrading to i386 glibc from i686 glibc
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-05-14 19:50 EDT by Dax Kelson
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description Dax Kelson 2001-05-14 19:50:38 EDT
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 06:16:39 EDT
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 11:56:47 EDT
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 05:28:27 EDT
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.