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".
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?
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 ?
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.