Bug 44781

Summary:	illegal instruction on 386 CPU due to glibc compilation mistake
Product:	[Retired] Red Hat Linux	Reporter:	Eric Thomas <bugzilla>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	fweimer, jfalk
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-04-22 01:46:54 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 Eric Thomas 2001-06-16 15:55:44 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5 i686)

Description of problem:
glibc-2.2.2-10.i386.rpm seems to be compiled without respecting the glibc's
FAQ recommendations chapter 1.18:
"And you need to tell gcc to only generate i386 code, just add `-mcpu=i386'
(just -m386 doesn't work) to your CFLAGS."

Without this, the glibc contains non-386 code and makes all non-staticaly
linked binaries to report illegal instruction.

As a specific glibc rpm file for 686 exists, the "386 only" one should
REALLY works on the lowest i386 architecture CPUs (386 indeed :-))

How reproducible:
Always

Steps to Reproduce:
1.install RH 7.1 on a pentium computer
2.rebuild the kernel for a 386 computer as target (coprocessor emultation
etc..)
3.put the hard drive in a 386 computer
4. (try to) boot linux
	

Actual Results:  The kernel loading is ok, the computer is not frozen but
seems stuck when lunching /sbin/init
No error messages

Expected Results:  A completed boot sequence

Additional info:

The boot sequence does not report "illegal instruction" error.
Put back the hard drive in the pentium computer.
In order to manage to boot anyhow on the 386:
- rename /sbin/init as whatever you want
- replace /bin/sh by ash.static
- create /auto file containing "/bin/sh"
Boot linux on the 386 computer.
sh (ash.static) is launched by the kernel. At the prompt, every dynamicaly
linked command you launch ends on (start by) "illegal instruction".

Comment 1 Jakub Jelinek 2001-06-25 07:38:18 UTC

glibc-*.i386.rpm is compiled with -march=i386, it does not contain any
non-i386 instructions.
By pentium above, do you mean a `uname -m`=i586 or i686 machine?
Are you sure rpm -q --qf '%{arch}\n' glibc gives i386, not i686?
Is /lib/i686 directory missing?

Comment 2 Eric Thomas 2001-06-25 22:01:10 UTC

Yes, rpm -q --qf '%{arch}\n' glibc gives i386, but i hadn't noticed that
/lib/i686 directory.

In fact, glibc.i686.rpm has been automatically chosen during the install process
on the pentium computer, no way to force to use a i386 rpm (afaik).
So i manually replaced it with glibc.i386.rpm with the following command:

rpm -Uv --force glibc-2.2.2-10.i386.rpm

But /lib/i686 remains and so

[root@redrum /]# ldd /sbin/init
        libc.so.6 => /lib/i686/libc.so.6 (0x40025000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

If i rpm -qf on /lib/i686/libc.so.6, it is not owned by any package. Shouldn't
this have been removed when i replaced the i686 rpm by the i386 one ?

If i manually remove /lib/i686, the 386 boots without any problem.

Perhaps rpm -Uv --force was not the right way to replace the glibc but it is
difficult to do a rpm -e followed by a rpm -i on this library on a running
system.

Not removing /lib/i686 with rpm -U, bug or feature ?

Comment 3 Ulrich Drepper 2003-04-22 01:46:54 UTC

This is no glibc bug.  It's a user bug.  Using rpm is sometimes challenging. 
Better always use up2date and it'll automatically install the right packages.