Bug 103078
| Summary: | Unable to install Severn on Cyrix P166 (rpm segfaulting) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | Leonard den Ottolander <leonard-rh-bugzilla> | ||||||
| Component: | rpm | Assignee: | Jeff Johnson <jbj> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | beta1 | CC: | hdegoede, nobody+pnasrat | ||||||
| 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-08-26 19:49:52 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: | |||||||||
| Attachments: |
|
||||||||
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 instructions? 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 neither. ;) 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 @@ /*@unchecked@*/ static int rpmsw_initialized = 0; -#if defined(__i386__) +#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 fedora-devel post. 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. |
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): rpm-4.2.1-0.30 (not sure if I used the above or rpm-4.2.1-0.11 on installation) How reproducible: Try to invoke rpm on a Cyrix P166 Actual results: rpm segfaulting