Red Hat Bugzilla – Bug 103078
Unable to install Severn on Cyrix P166 (rpm segfaulting)
Last modified: 2007-04-18 12:57:08 EDT
Description of problem:
I was unable to install Severn on an old Cyrix P166. It would terminate
the installation immediately after package selection without any error
other than "exited abnormally".
At that point tty3 shows:
* everything references package nptl-devel which doesn't exist
* moving (1) to step selectlangpackages
* moving (1) to step package-selection
* moving (1) to step handleX11pkgs
* moving (1) to step checkdeps
No errors are reported at tty4.
So I proceeded to install 7.3 on the system and do a Severn installation
using rpm --root from there. This renders a functional system (apart from
some missing config files), but with an incorrect rpmdb. After that I supplied a
correct rpmdb created using rpm --justdb on an other Severn system. Even
after substituting the rpmdb I was seeing segfaults / non-exec exploits on
every invocation of rpm.
To make sure this has nothing to do with the installation being performed
from a 7.3 system I exported a new partition from the Cyrix Severn system
and installed a new system from another Severn system, again using rpm --
root /mnt/nfs_cyrix. I am still seeing segfaults on every invocation of
rpm, also when using the latest 9 kernel and the latest rawhide rpm.
Backtraces on core files created by invocations of rpm -qa
(/usr/lib/rpm/rpmq) and rpm -i <pack> (/bin/rpm) show rpmShowRC to be the
location of the crash:
For rpm -qa:
#0 0x0094b164 in rpmShowRC () from /usr/lib/librpm-4.2.so
For rpm -i:
#0 0x00997164 in rpmShowRC () from /usr/lib/librpm-4.2.so
Version-Release number of selected component (if applicable):
(not sure if I used the above or rpm-4.2.1-0.11 on installation)
Try to invoke rpm on a Cyrix P166
Created attachment 93935 [details]
core file created on invocation of rpm -qa
Created attachment 93936 [details]
core file created on invocaton of rpm -i <somefile>
Almost certainly rpm has problems on Cyrix P166.
AFAUCT, the cpuid instruction used to detect athlon
may be the problem. I suspect that doing
echo "i386-redhat-linux" > /etc/rpm/platform
will avoid that.
Then there's bswap that may need removal. Make sure rpm
is compiled with -march=i386 -mcpu=i686 )or equiv)
Next is NPTL, i386 kernel's have not. Find every
occurence of --enable-posixmutexes (in autogen.sh and
rpm.spec) and nuke.
Then there's beecrypt, which has asm optimizations.
I've been told (but have not checked) that the
md5/sha1/dsa/rsa code paths are clean, i.e. will
work on i386.
With the above changes, rpm used to work on i386.
Again, there's little reason to support i386 execution of rpm
too little to justify the fixes listed above. All the changes
are known and desirable.
Those are my marching orders, nothing personal.
Creating /etc/rpm/platform as you say indeed renders an "Illegal instruction"
instead of a segfault when invoking rpm.
There's two things I don't understand: First, I thought this Cyrix is i686
compatible; second, are you telling the default rpm is *not* built using i386
I don't believe Cyrix P166.
Yes, I just described the non-i386 instructions now in rpm, and what to
do about them if you choose.
Yes your explantation was clear. I am just surprised that a package containing
non-i386 instructions is shipped as an i386.rpm. If it uses i686 instructions,
shouldn't it be shipped as i686.rpm instead?
(By the way I thought the Cyrix was i586 compatible, not i686. Anyway, its
RPM probably also needs to have db4 built without nptl. See bug #91933
for a patch.
For anyone browsing this bug who doesn't realize this:
Despite the "P" in the name, that CPU is really a 486-equivalent at
a slightly higher clock speed, not a pentium-equivalent.
I finally got the correct answer to this question from Arkadiusz
Miskiewicz from PLD (http://www.pld-linux.org/).
The problem is that this Cyrix does not have a TSC flag (the same
applies to WinChips (CentaurHauls)).
Apply the following patch and create an /etc/rpm/platform:
--- rpm-4.2.1/rpmio/rpmsw.c.orig 2003-04-10 20:09:13.000000000 +0200
+++ rpm-4.2.1/rpmio/rpmsw.c 2003-11-17 21:55:44.649426712 +0100
@@ -27,7 +27,7 @@
static int rpmsw_initialized = 0;
+#if 0 && defined(__i386__)
/* Swiped from glibc-2.3.2 sysdeps/i386/i686/hp-timing.h */
#defineHP_TIMING_ZERO(Var)(Var) = (0)
# echo "i386-redhat-linux" > /etc/rpm/platform
Erm, I just stumbled over this bug following a thread of bugs of a
Why won't this be fixed? I understand that building without NPTL
really is not an option, but in this case the problem isn't NPTL, but
the fact that rpm doesn't handle the cpu-detection correct. It tries
to use TSC which isn't there and it barfs out on the cpu dedection, so
IMHO this is really a bug and should be reopened.
Also since rpm MUST have NPTL, shouldn't rpm (and all other rpm's
which must have NPTL) be .i486.rpm?
BTW this is just my 2Â¢ I don't have a cpu which cuffers from this.