From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516
Description of problem:
I do not think this is an rpm bug, but a problem in the packages it is upgrading.
1.) Got all updates in the i386 directory on 6/08/2003.
2.) Removed a couple duplicates, keeping the higher versions.
3.) Did rpm -F *.rpm
4.) Upgrade progressed.
5.) pre and post install scripts started reporting failure; segfault messages.
6.) after install completed (with lots of errors), most commands would not work
- they segfaulted.
7.) Rebooted machine via big red button method as shutdown segfaulted
8.) Boot failed because mingetty et al. were segfaulting too
9.) Reloaded box. Repeated from step 1. Same thing happened.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get the contents of the i386 dir on updates as of 6/8/03
2. rpm -F *.rpm
3. Watch your machine die pitifully.
Actual Results: All newly executed programs segfaulted. Like:
> shutdown -r now
You get the idea.
Expected Results: I should have gotten a process list, another xterm, and a
message telling me that I can't reboot the machine because I'm not root,
This is a Very Bad Thing. Spending my evening reloading my box twice (once to
try and reproduce, once to just have a working box) brings back all my bad
memories of running Windows.
Duplicate of bug 88456 . Replacing an i686 glibc package with an i386 one is not
a good idea.
Well than RedHat has suffered from a dumbass attack, and indeed, this is a
problem with rpm in general.
1.) It is not known what architecture a package is compiled for once it is
installed (the real bug that rpm should detect and complain about). Example:
> rpm -qa | grep glibc
No information at all about target architecture.
rpm should detect this and error out.
2.) replacing the i686 packages with the i386 packages SHOULD work, since
anything that can run i686 code can run i386 code. Shouldn't both libraries
export the same functions? If the app is statically linked, it doesn't care, and
if it's dynamically linked, it should just get the new functions at runtime.
3.) I did not realize, and I wonder how many people actually do realize, that
different packages are installed based on architecture. I assumed that with this
release, like with the versions before it, everything was compiled for an i386.
This was obviously incorrect. However, it's news to many people.
1. There are legitimate reasons to replace packages of one sub-architecture with
one of another sub-architecture. Typically it doesn't cause things to blow up
either. So, it shouldn't be impossible to do this, but I guess it should be
harder (for example, an extra command line option, or a confirmation prompt of
2. The i686 glibc packages have NPTL support. NPTL requires glibc to be compiled
for i486 or up, so it's omitted from the i386 glibc packages. IIRC the problem
is that the glibc package was leaving some old files behind when upgrading
i686->i386. AFAIK the glibc packages in Rawhide fix that problem.
3. Different packages have been installed, based on sub-architecture, since Red
Hat 6.0. (In particular: the kernel in 6.0 and up, glibc in 7.0 and up, and
openssl in 7.2 and up.) This is nothing new.
This problem appears resolved. Yes i686 has NPTL, i386 doesn't,
life gets bumpy and weird when doing "rpm -Fvh /yadda/yadda/*"