Bug 40591

Summary:	After downgrading to i386 glibc from i686 glibc
Product:	[Retired] Red Hat Linux	Reporter:	Dax Kelson <dkelson>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED RAWHIDE	QA Contact:	Aaron Brown <abrown>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.1	CC:	fweimer
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-11-01 22:31:24 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:

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
worked.

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
/lib.

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>]
[<c011e070>]
kswapd    S C3F040A0     0     3      1        (L-TLB)       4     2
Call Trace: [<c0110c1d>] [<c0110b50>] [<c0111191>] [<c01289a1>]
[<c0105000>]
   [<c0105000>] [<c01054b6>] [<c01288d0>]
kreclaimd  S C0246F00     0     4      1        (L-TLB)       5     3
Call Trace: [<c011112c>] [<c0128a8a>] [<c0105000>] [<c01054b6>]
[<c0128a30>]
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>]
[<c01323d0>]
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>]
[<c01054ad>]
   [<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.