Bug 88456 - glibc-2.3.2-27.9.i686.rpm does not rpm -Fvh properly.
glibc-2.3.2-27.9.i686.rpm does not rpm -Fvh properly.
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
: 88709 88771 90198 90817 102569 107819 108756 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-04-10 01:48 EDT by Hisashi T Fujinaka
Modified: 2016-11-24 10:15 EST (History)
32 users (show)

See Also:
Fixed In Version: 2.3.2-27.9.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-20 12:24:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hisashi T Fujinaka 2003-04-10 01:48:17 EDT
Description of problem:
installing glibc-2.3.2-27.9.i686.rpm with rpm -Fvh (with glibc-common) causes
system to be useless (anything linked with glibc dumps core).

Version-Release number of selected component (if applicable):
See above.

How reproducible:
rpm -Fvh glibc*, when sshed in. Also reported by a friend (not verified) that it
always happens, even on console.

Steps to Reproduce:
1. ftp the rpm files
2. rpm -Fvh glibc*
3. cry
Actual results:
core dumps. can't chroot from rescue disk (obviously).

Expected results:
not trashing my system.

Additional info:
Comment 1 Need Real Name 2003-04-10 03:20:48 EDT
I'm having the same issues when I do an rpm -Fvh glibc* It updates glibc-common
just fine but about half way through glibc I get the following:

INIT: id "x" respawning too fast: disabled for 5 minutes
error: %post(glibc- scriptlet failed, exit status 121

After that the system is useless.

Segmentation fault...... 
Comment 2 Sammy 2003-04-10 15:06:10 EDT
From what version are you updating? If you are updating from 8.0 the new libraries 
use tls e.g. like version change. I had the same problem. What I did was to make 
a compatible boot CD (RedHat 9), boot from that, choose linux rescue. Have all your rpms 
there, including popt, rpm, glibc rpms. Then do rpm -Fvh --root=/mnt/sysimage *.rpm 
(assuming that your systme was mounted under /mnt/sysimage by linux rescue, which 
is the default). If all the way at the end you get an error because in writing something 
rpm is not using the --root=/mnt/sysimage option but wants direct /var/lib/rpm instead. 
Go to your /var/lib/rpm, rm -f db_*, edit /etc/rpm/macros and insert the line: 
%__dbi_cdb create private cdb mpool mp_mmapsize=16Mb mp_size=1Mb 
then do rpm --rebuilddb. Hope this helps....... 
Other alternative is to buy RedHat 9 CD's and do a graphical upgrade. After that the 
upgrades should work with no problem. 
Comment 3 Need Real Name 2003-04-10 15:25:09 EDT
This is on a fresh install of rh9. Everything else is updated, then when I do an
rpm -Fvh glibc* on the system is when I see the error posted previously.
Comment 4 Łukasz Trąbiński 2003-04-10 20:09:36 EDT
I'm confirm it. I have just made rpm -Fhv * on updates directory (i386)  and I
had got "core dumped" during upgradeing. Now, I have to boot from cdrom and
rescue my system. :( System is RH 9.0, last week, i have made upgrade from RH
For RH team, please make tests for new RPMS  packages first...
Comment 5 Rene van Paassen 2003-04-11 03:38:28 EDT
Had the same problem, fresh 9 install on an ASUS laptop, PII 366, 
did the rpm -Fvh on updates directory.

Tried a rescue but could not figure out how to rpm install on the mounted disk; 
a chroot obviously fails because glibc is broken

Tried an update with 9 on the broken system too, could "update" all glibc
components except glibc itself, ended up re-installing
Comment 6 Need Real Name 2003-04-11 06:59:14 EDT
same thing just happened to a freind that used up2date to update a rh8 box. His
system is useless....
Comment 7 risc 2003-04-11 07:54:20 EDT
I've traced this back to an rpm replacing ld.so.conf with a blank file, and
backing up the original as ld.so.conf.rpmsave - I replaced the new one with the
original and all was fixed.
Comment 8 Matt Wilson 2003-04-11 11:08:13 EDT
You're "upgrading" from the i686 glibc to the i386 glibc.  The upgrade
ordering puts the "new" i386 glibc on the system, runs the %post,
which fails because there are some files in /lib/i686 and
/usr/lib/i686 left over from the "old" i686 glibc which are used in
the %post.  Once the %post fails, the "old" i686 glibc never gets
removed, so you're stuck with things using the wrong libraries and
you'll get segfaults all the time.
This is how to correct the problem:
$ export LD_ASSUME_KERNEL=2.2.5
$ su
Password: [enter root password]
# rpm -q glibc
# rpm -e glibc-2.3.2-11.9
(substitute the glibc for the "old" version, whatever you have
At this point dynamically linked apps will work again, and I would
STRONGLY suggest that you upgrade to the i686 version of the glibc
packages by using:

# rpm -Uvh --replacepkgs --replacefiles glibc-2.3.2-27.9.i686.rpm
Comment 9 Jakub Jelinek 2003-04-11 11:15:40 EDT
FYI on i686 boxes (ie. [ `rpm -q --qf '%{arch}\n' glibc` == i686 ] before upgrade) you should always use -Fvh line like:
rpm -Fvh *2.3.2-27.9.i686.rpm {glibc-[a-z],nscd}*2.3.2-27.9.i386.rpm
rpm -Fvh i686/*2.3.2-27.9.i686.rpm i386/{glibc-[a-z],nscd}*2.3.2-27.9.i386.rpm
Anyway, I'll add code to i386.rpm /usr/sbin/glibc_post_upgrade to effectively rm -rf /lib/i686
(well, at that point rm obviously cannot be used, so it will have to be readdir/unlink).
Comment 10 Hisashi T Fujinaka 2003-04-11 11:23:04 EDT
Ah, I reported this incorrectly. What I really did was:

cd whatever-path/i686
rpm -Fvh glibc-2.3.2-27.9.i686.rpm ../i386/glib-common-2.3.2-27.9.i686.rpm

and the error occurred.

So I'm not sure the solution is the one described.
Comment 11 Jakub Jelinek 2003-04-11 11:45:59 EDT
Hisashi, can you from the rescue do:
cd /mnt/sysimage (or wherever you have your / mounted to)
ls -l lib/ld* lib/i686 lib/tls
usr/bin/strace usr/sbin/chroot /bin/echo | less
Comment 12 Hisashi T Fujinaka 2003-04-11 11:55:24 EDT
I am unsure what you want. I fixed my system (not included in the original bug
report -- I am the original submitter, I think) by booting the rescue disk,
forcing the install of the old glibc defining the root directory, and then
running the update again.

At first I thought the problem was because I tried the update remotely (the
update restarts sshd, which I was running).

Here' some of the info you asked for:

anna:/ % ls -l lib/ld* lib/i686 lib/tls
-rwxr-xr-x    1 root     root       104560 Apr  7 16:25 lib/ld-2.3.2.so
lrwxrwxrwx    1 root     root           11 Apr  9 17:47 lib/ld-linux.so.2 ->

total 1868
-rwxr-xr-x    1 root     root      1548424 Apr  7 16:25 libc-2.3.2.so
lrwxrwxrwx    1 root     root           13 Apr  9 17:47 libc.so.6 -> libc-2.3.2.so
-rwxr-xr-x    1 root     root       212020 Apr  7 16:25 libm-2.3.2.so
lrwxrwxrwx    1 root     root           13 Apr  9 17:47 libm.so.6 -> libm-2.3.2.so
-rwxr-xr-x    1 root     root        93268 Apr  7 16:25 libpthread-0.10.so
lrwxrwxrwx    1 root     root           18 Apr  9 17:47 libpthread.so.0 ->
-rwxr-xr-x    1 root     root        37592 Apr  7 16:25 librt-2.3.2.so
lrwxrwxrwx    1 root     root           14 Apr  9 17:47 librt.so.1 -> librt-2.3.2.so

total 1868
-rwxr-xr-x    1 root     root      1536292 Apr  7 16:25 libc-2.3.2.so
lrwxrwxrwx    1 root     root           13 Apr  9 17:47 libc.so.6 -> libc-2.3.2.so
-rwxr-xr-x    1 root     root       212020 Apr  7 16:25 libm-2.3.2.so
lrwxrwxrwx    1 root     root           13 Apr  9 17:47 libm.so.6 -> libm-2.3.2.so
-rwxr-xr-x    1 root     root        80340 Apr  7 16:25 libpthread-0.34.so
lrwxrwxrwx    1 root     root           18 Apr  9 17:47 libpthread.so.0 ->
-rwxr-xr-x    1 root     root        37080 Apr  7 16:25 librt-2.3.2.so
lrwxrwxrwx    1 root     root           14 Apr  9 17:47 librt.so.1 -> librt-2.3.2.so
-rwxr-xr-x    1 root     root        21572 Apr  7 16:25 libthread_db-1.0.so
lrwxrwxrwx    1 root     root           19 Apr  9 17:47 libthread_db.so.1 ->
Comment 13 Jakub Jelinek 2003-04-11 12:06:25 EDT
Well, when you have your system already fixed, that information is not useful.
Anyway, sshd condrestart should restart just the sshd master daemon, not already
running connections. When I was updating my workstation, I was running it through
ssh connection and saw no problems at all.
Comment 14 Mike Bird 2003-04-11 14:32:48 EDT
Encountered this problem upgrading from RH8.0 to latest RH9 without first
upgrading to stock RH9.  There's an incompatibility between glibc-2.3.2-27.9 and

Fortunately I had SSH and some working RH9 systems, so I forced the replacement
files over from the working system with something like the following (use at
your own risk, this is from memory):

for d in /bin /usr/bin /usr/lib; do rsync -va -e ssh $d/*rpm* broken.host:$d/; done

After that, RPM could be used on the broken system again, including rpm -hUv on
the rpm-4.2-0.69 to fill in various ancillary files not copied via rsync.

Suggest RHBA-2003:136-07 be withdrawn until this is fixed.
Comment 15 Rob Cermak 2003-04-11 16:01:43 EDT
(1) post mortem using: linux recover

(a) /mnt/sysimage/etc/ld.so.config was intact

(b) rpm --root=/mnt/sysimage -qa | grep glibc

showed that glibc-common was updated, but both
glibc packages exist in the rpm database.
  OLD: glibc-2.3.2-11.9
  NEW: glibc-2.3.2-27.9

Looks like something failed in the update process.

(2) removed glibc-2.3.2-11.9
    rpm --root=/mnt/sysimage -e glibc-2.3.2-11.9
    reinstalled glibc-2.3.2-27.9 : if you happen to have
      in on the failed system somewhere ; burn it to CD
    rpm --root=/mnt/sysimage -Uvh --replacepkgs --replacefiles glibpkg

The glibc is the i386 package, not the i686 package.

(3) test it out
    chroot /mnt/sysimage

You will know if the system fixed if the chroot does not segfault.

(a) chroot worked  
(b) rebooting: its doing fsck's on the journaled filesystems,
    seems like we are back in operation.

Comment 16 Jakub Jelinek 2003-04-12 04:29:40 EDT
*** Bug 88709 has been marked as a duplicate of this bug. ***
Comment 17 Jakub Jelinek 2003-04-12 04:32:58 EDT
With upgrading from RHL8 directly to RHL9 glibc. The problem is that rpm used
to be statically linked in RHL8 and earlier. There is no binary compatibility
with statically linked applications (which use NSS/iconv/dlopen/locale)
accross versions. So you should have upgraded rpm first (in RHL9 it is not
statically linked) and then glibc, or use rpm outside of your installed root
(e.g. through upgrade process).
Comment 18 Mike Bird 2003-04-12 13:40:30 EDT
It would be a lot safer if the requirement to upgrade rpm before glibc was
stored in the relevant .rpm's along with other dependencies.
Comment 19 Hisashi T Fujinaka 2003-04-12 14:04:58 EDT
The RH8 -> RH9 is a separate bug, isn't it?

And I checked my secure log. The actual command that caused everything to die:

Apr  9 15:51:41 anna sudo:    htodd : TTY=pts/2 ; PWD=/misc/updates/9/i686 ; USER=root ; COMMAND=/bin/rpm -Fvh glibc-2.3.2-27.9.i686.rpm ../i386/glibc-2.3.2-27.9.i386.rpm ../i386/glibc-common-2.3.2-27.9.i386.rpm ../i386/glibc-debug-2.3.2-27.9.i386.rpm ../i386/glibc-devel-2.3.2-27.9.i386.rpm ../i386/glibc-profile-2.3.2-27.9.i386.rpm ../i386/glibc-utils-2.3.2-27.9.i386.rpm

Since that time, I've rpm -e'd debug and profile.
Comment 20 Tjaun 2003-04-12 23:51:18 EDT
I face the same problem while updating the glibc. But now it works fine after 
following Rob Cermak step-by-step instruction to solve the problem.

Comment 21 Jakub Jelinek 2003-04-13 17:10:52 EDT
*** Bug 88771 has been marked as a duplicate of this bug. ***
Comment 22 Steven Shiau 2003-04-13 23:22:41 EDT
I confirmed the same problem when I updated RH9.
Due to some reasones, I have to use the i386 packages (especially glibc)
in i686 machines. This was ok when I use it in Redhat 8.0, but when I
tried the same way in redhat 9 (by using apt-get upgrade, and set the
Architecture "i386" in /etc/apt/apt.conf, it installed the
updates/glibc-2.3.2-27.9.i386.rpm for me), it failed when it boots to
So I use the rescue disk, boot it, then reinstall glibc i686 package,
it' ok again.

What can I do for this if I have to use the glibc i386 package now ?
not upgrade ? 
Any better idea ?
Comment 23 Joachim Backes 2003-04-14 01:36:49 EDT
Having the same problem after installing a fresh RH 9.0 and then applying
glibc-2.3.2-27.9.i386.rpm to my system. An interim solution was to take the
_files_ (not the RPMS) of the RH 9 origin glibc and to copy these files to their
places belonging to. The system was then running again, but not 100% correctly
(it seems that the rpm program itself was a little bit damaged).

I had to re-install RH 9 completely.
Comment 24 anthony_w 2003-04-16 09:16:40 EDT
My experience was as follows:

3 installs all gave the same result:

System unuseable after upgrading the glibc....i386.rpm on the system.

Failure of the "post scriptlet" with error 121

glibc-common installed fine.

The fix was to re-install....

Several suggestions have been made about the cause.

1. Is it required to use the glibc...i686.rpm version?
2. What about Athelon systems?
3. Are we looking at a totally different problem like a
   broken glibc?

Comment 25 William W. Austin 2003-04-20 14:17:39 EDT
I am seeing almost the exact same problem -- without having used the i686 version.

I have a machine (2.1GHz athlon, 1GB ram, single cpu) on which I installed rh 9
yesterday.  I ftp'ed the updated files and an rpm -Fvh on the new glibc files. 
ALL were the i386's no i686's (and for some reason rh has not provided any
athlon versions this time???).

After the update, I did not check to see whether /etc/ld.so.conf was of length 0.

However, after a reboot, I got the same INIT: id "x" respawning too fast:
disabled for 5 minutes problem described above.

In my case, the routine suggested above by Rob Cermak did not work.  Even after
the 3rd  re-attempt.  I even took the tape (doesn't everyone back up their
system immediately after a new install and before adding *anything* ??? :-),
pulled the ld.so.conf and ld.so.cache off it and copied them back onto this
system -- and the problem *STILL* lived through the reinstall procedure.  After
 3 tries (rpm , force, root mnt/sysimage, etc.) rpm -qa "glibc*" with root
/mnt/sysimage looks OK; however, any attempt to chroot /mnt/sysimage fails with
a segfault.

I am currently in the process of solving the problem by reinstalling EVERYTHING
as ANOTHER fresh install ... agin; however, (a) I think there is a
****SERIOUS**** problem in the updated glibc rpm's and (b) I think they should
be pulled from the website until the bug is found.
Comment 26 Need Real Name 2003-04-20 15:24:03 EDT
I agree that the RPM's should be pulled and fixed ones put in place, but that
would require that redhat admit that they released buggy updates and I doubt
that will happen. This is obviously causing problems for people and most likely
pushing people away from redhat. I suggest that a serious update like this be
tested a little more before being released to break all kinds of systems. I know
someone that used up2date and it still hosed his system. Concetrate guys, and
get it together.
Comment 27 G. Reno 2003-04-20 20:34:28 EDT
  This bug is a showstopper for us.  We stopped all upgrades to RH9 and
prohibited all updates to systems already upgraded to RH9 until this is fixed.  
  How could such critical functionality with regard to a critical component not
be noticed during testing?  I'd like to see the test results!
  Well, I guess it can happen even to the best of us.  What we'll be looking for
now is how quickly RedHat gets this fixed.
Comment 28 Jakub Jelinek 2003-04-21 04:43:21 EDT
The errata had a bug, I believe we clearly admitted that and made sure
it will be fixed in the future versions (including possible RHL9 glibc errata
when/if that becomes neccessary). But I strongly disagree with calling this
bug a showstopper. It occurs only when an admin does errnously perform an
i686 -> i386 "upgrade", which is something which shouldn't be done, isn't supported
nor has been tested. The only valid reason for i686 -> i386 glibc replacement
is when you're installing a disk on i686+ box for an non-i686+ system and plan to
move the harddisk there later on. This is very rare thing to do.
up2date will choose the right architecture for you and if you're using rpm
by hand, you better do that too, because otherwise you're crippling your system.
As for why there is no .athlon.rpm, there is no measurable gain in it. If somebody writes
Athlon optimized str*/mem* operations, maybe, but anyway, the gain in using
.i686.rpm over .i386.rpm will be always way bigger than any gains of .athlon.rpm
over .i686.rpm might ever be.
Comment 29 Need Real Name 2003-04-21 05:20:09 EDT
Don't you think that it would be a good idea to add something to the rpm's that
would not allow this sort of update? It seems like the right thing to do here
since so many people are having problems, and it may even help Redhat keep some
customers (clue). I really think you have the wrong attitude about this.
Comment 30 William W. Austin 2003-04-21 08:09:32 EDT
I can remember at least one (and I think more than one) cases where RedHat
officially said that they had made an error on rpm's -- this is *NOT* M$, people.

That being said (hey I *like* this release and I finally get the posix threads
I've been whining about for years...), I would have to take exception to the
statment that:

> It occurs only when an admin does errnously perform an
> i686 -> i386 "upgrade", which is something which shouldn't be done, isn't
> supported nor has been tested. 

As I posted above, it happened to me on an ATHLON system on which the only rpm
downloaded was the i386 version, so installing the i686 version was a literal
impossibility.  QED, the bug can hit in other circumstances.

OTOH, I have previously built the athlon glibc (under 8.0 and 7.3) and saw only
minimal improvements (if any) from them -- when I asked, I was only curious.
Comment 31 Jakub Jelinek 2003-04-21 08:20:08 EDT
And that's the problem. The installed of course installed the .i686.rpm glibc
on your box and you were trying to "upgrade" it to .i386.rpm version you've
downloaded. Athlon has i686 ISA, including cmov. Try:
uname -m; cat /proc/cpuinfo | grep ^flags.*:.*cmov
Comment 32 Hisashi T Fujinaka 2003-04-21 10:58:26 EDT
jakub has repeatedly stated this is only when you install glibc for i386 over
glibc or i686. However, at least two people, including me, think it's triggered
when you're just doing a i686 -> i686 upgrade.

I've posted the command I ran in comment #19. Can someone check to see if I made
that mistake?
Comment 33 Piotr Wojciechowski 2003-04-22 15:28:18 EDT
Ok. But what to do in this rare situation (i686->i386) when i made an upgrade
from RH8 to RH9 on Athlon machine and then put HDD to old Pentium (of cource
reinstalling glibc to i386 package) and reciving "illegal instruction" error
trying to run httpd or wget? It happends on standard glibc from RH9 and from
RH9-updates too. Any ideas, solutions?
Comment 34 Rob Cermak 2003-04-22 15:43:04 EDT
The fact is that things that normally worked (for a few years) do not now and it
is a showstopper.  If semantics are now going to be strict (i386, i686 vs
athlon) whether it be kernel or glibc, the package manager (rpm) must perform
this check.   As with comment #33, we have made the mistake of loading a i386
kernel on an athlon box (rpm will let you do it; no warnings), it will still
boot so you can switch back a load the proper arch.  The fix for #33 is to make
sure you boot with a i386 kernel so it will properly operate on the pentium
chip.  At this point, there is NO check for i386, i686 or athlon in the kernel
or glibc package.   A separate bug (enhancement for rpm) should be opened with
this bug listed as a dependency and should block any future development beyond RH9.
Comment 35 Mobeen Azhar 2003-04-22 21:23:04 EDT
I am seeing an instance of the same problem and it has nothing to do with
switching back and forth between i686 and i386 rpms (although I am sure that
does produce a problem as listed in the other comments).  Here is what I did:

1)  Had a nicely running RH 8.0 box.  Performed an upgrade using RH 9.0 CDs
bought from the local computer store.

2)  Once the RH 9.0 upgrade was complete, rebooted the box.  No problems at this
point.  The box came up fine.

3)  Ran up2date --list.  Amongst other things, it listed newer kernel and glibc

4)  Downloaded kernel-source-2.4.20-9.i386.rpm.  Installed this rpm and followed
standard (RH manuals) procudures to build a new kernel.  Nothing fancy was done
here, just deselected hardware components I do not have and such.  Saw no
options during make menuconfig regarding tls, nptl, or threads in general. 
Built and installed the kernel with no issues.

5)  Downloaded and installed glibc-2.3.2-27.9.i386.rpm and
glibc-common-2.3.2-27.9.i386.rpm.  Rebooted the box with no problems.

6)  Downloaded and installed db4-4.0.14-20.src.rpm.  Tried to do a rpmbuild
--rmsource --clean -bb db4.spec.

7)  The rpmbuild bombed complaining about not finding POSIX mutexes.

This started an adventure that has been going on for three days so far with no
solution.  As far as I can tell, the system does not have support for nptl.  I
have googled and gargled and himmed and hawed to no avail.  I tried all the
suggestions I could possibly apply to the system mentioned in the previous
comments of this bug report to no avail.  At this point, there is not nptl on
this system.  Period.

On another machine, I installed RH 9.0 from scratch.  Everything works fine on
it so far but I have not had a chance to apply the glibc and kernel updated that
I applied to the machine used in the above testing.  I will try to do that
tomorrow and see what happens.

On the first machine (the one with the updated glibc and kernel), I even went so
far as to install the older glibc rpms ( the ones that ship with RH 9.0). 
However, even after doing so (I did not back rev. the kernel though), I still
have the problem with the DB4 rpmbuild complaining about missing POSIX mutexes.

I verified in db4.spec that the message about missing POSIX mutexes is being
generated when the configure is passed --enable-threads.  If I remove that,
rpmbuild succeeds.

The above pretty much proves that RedHat has broken npls in some fashion.  I do
not see how this can be negated.  I will ascertain whether this is broken in the
post RH 9.0 release glibc or kernel updates, or whether it is broken whenever a
RH 8.0 is updated to RH 9.0.

In the meantime I have put on hold a major migration we were about to perform
from existing FBSD boxes to RH.  I will see whether I have any hair left by the
time the nptl issue is resolved to go forward with the RH migration.

Comment 36 Chris Ricker 2003-04-23 12:11:33 EDT
FWIW (comment #34), I opened a request a few days ago for rpm to consider
%{arch} when upgrading. See Bug 88623. That would prevent (most? all?) of the
problems people experienced here....
Comment 37 Rick Crelia 2003-04-23 16:39:00 EDT
While this is not a showstopper (Rob Cermak's recovery recipe worked perfectly
for me), it is a huge pain in the ass. IMHO, RedHat should yank the glibc rpm's
until rpm itself is modified or a much more salient errata is filed to prevent
this from happening to others.
Comment 38 Need Real Name 2003-04-23 19:25:29 EDT
Looks like Redhat does not want to hear about this anymore as jakub has removed
himself from this post, and put the priority to low. That really blows, and in
my opinion it's the same thing I said before about redhat admitting to a buggy
update. Posting a couple comments on bugzilla is much better than pulling the
update and replacing it with something that works properly. This would cause
publicity issues for redhat. I hope you guys learned your lesson here, and
didn't drop too many customers in the process. Concentrate guys, and try to do a
little more testing. Or better yet, make a new release when the release is ready
not when marketing tells you to. A new glibc a week after release. Give me a
Comment 39 Need Real Name 2003-04-23 19:29:53 EDT
My bad I see jakub is still with us here.
Comment 40 Mobeen Azhar 2003-04-24 18:13:54 EDT
ra1, I am testing, in preparation for replacing a bunch of FBSD boxes to Linux :)

Anyway, I think I have found the crux of the problem.

Here are some empirical facts:

1)  rpm -qil -p glibc-2.3.2-27.9.i386.rpm | grep tls 
produces no results at all.

2)  rpm -qil -p glibc-2.3.2-27.9.i686.rpm | grep tls
produces eleven references to directories (/lib/tls) and files.

This shows that RedHat does not have NPTL support in the i386 build of glibc. 
Period, no two ways around it.  I would say this is a bug, a major bug, and a
show stopper by any definition, especially since every ad. for RH 9.0 screams
about NPTL support.

Looking at glibc-9.spec from glibc-2.3.2-27.9.src.rpm, I see a line reading:
%define nptlarches i686 athlon
This shows that nptl is not being compiled for any architectures other than i686
and athlon.

The above is what is causing nptl to have issues on all glibc's other than i686
and athlon architecture builds.

This is a very major issue because packages other than glibc are not setup this
way.  For example, looking at the spec. file of a typical package that is used
by many other packages - DB4 (used by RPM, Cyrus, etc. etc), here is what I see:

%define nptl_arches %{ix86}.

This means that a DB4 build from source rpm will break on any architecture other
than i686.  The binary RPM for db4 from RedHat for the i386 architecture also
appears to be built using nptl support!

This leads to the following questions:

1)  Why is NPTL support in glibc restricted to the i686 and athlon architectures?

2)  Is there any harm in editing the glic-9.spec file and adding nptl support to
all x86 architectures?

3)  Why do the nptl requirements for glibc not match nptl requirements in other
packages from RedHat ?

In light of the above I think this is a serious bug and needs to rectified as
soon as possible.  Otherwise people will continue to see mysterious breakdowns
with various packages.

Comment 41 Kyle Bateman 2003-04-24 23:15:49 EDT
This bug _IS_ a showstopper for us.  Jakub mentions in #28 that the only reason
someone would go from 686->386 is if you plan on moving your hard disk later on.
 This is not true.

We have a server whose filesystem serves 40+ diskless clients via nfs.  For this
application, the server _MUST_ have a i386 glibc so as to be compatible with all
kinds of CPU architectures of clients.

I notice that the Aptus product from Shaolinmicro.com relies on this same
principle.  In short, anyone using diskless or shared nfs root filesystem will
not be able to use RH9 until there is a way to install 386 over top of 686 glibc.

It would be very helpful to us if the 386 post scriptlet could manage to
successfully remove the 686 rpm.  I think this is a much better approach than
trying to disallow rpm from updating an rpm with a different architecture.
Comment 42 Jakub Jelinek 2003-04-25 03:25:50 EDT
To Mobeen Azhar:
NPTL cannot be supported on i386, since it lacks essential instructions
(compare and swap particularly).
Comment 43 Kyle Bateman 2003-04-25 10:55:42 EDT
OK, here's a workaround based on the steps in #8 that seems to work (for those
like me who need an i386 glibc on their 686 machine):

> export LD_ASSUME_KERNEL=2.2.5
> rpm -Uvh --force glibc-2.3.2-27.9.i386.rpm      #post scriptlet fails
> rm -r /lib/i686 /lib/tls
> ldconfig

Then, just to make sure, I did again:
> rpm -Uvh --force glibc-2.3.2-27.9.i386.rpm       #no scriptlet failure
> ldconfig

BTW, some of you guys (ras1) are too hard on Jakub and RH.  Did you _buy_ your
last RH release or did you download it for free?  We have to remember this is
still open source here and we have to work together to make things happen for
the best.
Comment 44 Mobeen Azhar 2003-04-25 13:45:41 EDT
Jakub, if NPTL cannot be supported on i386, then RPM packagers at RedHat need to
know so that they do not assume that it is supported on x86.

Can NPTL be supported on i586? My system is acutally i586 but I do not see a
binary i586 RPM for glibc.  The src. RPM only build NPTL support for i686 and

What do you suggest for people on non-i686 and non-athlon architectures?  Do we
have to manually build all affected RPMS (such as DB4) after editing the spec
files to remove posix thread support?

Kyle, I am not trying to be too hard on Jakob or RH.  I know the guys are doing
wonderful work.  If nothing else, I am working very hard to get the RH distro.
of Linux into a place that is heavily Solaris and NetWare right now.  Already
got Novell's eDirectory with production replicas on RH boxes.  And yes, I have
bought paid copies of RH since 7.0 _and_ pay for subscription to rhn.
Comment 45 Richard Gill 2003-05-06 04:47:38 EDT
I would just like to add that IMHO this IS a showstopper. I had RH8.0 running to
great satisfaction. Upgraded to RH9, to greater satisfaction still. The rhn
applet thingy told me a week or too later to upgrade certain glibc packages
(specifying precisely which) and according to the rhn pages this was a BUG which
had SECURITY consequences. So I picked up the rpm's which rhn recommended to me
and installed them and blew up my machine. As a newbie user and great redhat fan
I'm not very aware of the more subtle aspects of i386 vs i686 and I certainly
never heard about NPTL. I have two paid subscriptions for two other machines and
in this case I admit I was donwloading iso's and doing things by hand a) for the
learning experience and b) because I'm only using this machine for three months.

All in all it was a very useful learning experience for me but I hope also for
Comment 46 Ulrich Drepper 2003-05-06 19:51:59 EDT
*** Bug 90198 has been marked as a duplicate of this bug. ***
Comment 47 James Watson 2003-05-07 11:55:49 EDT
Let me get this straight...

The RH9 installer auto-detected my processor and chose the i686 rpm's for me,
right?  Is this a new feature of rh9, or have past versions done this as well?

Are there 686 versions of all rpm's or just a few key ones (like glibc & kernel)?

Now, assuming I do my updates manually, what is the algorithm I should use to
decide what updates to install?  Should I look in the i686 directory first, then
check the i386 directory (omitting anything that was also in the i686 directory)?

Can I force the installer to just use the i386 packages so I can avoid this mess
in the future?

How can I check the architecture of currently-installed packages?

Comment 48 Need Real Name 2003-05-07 16:18:45 EDT
It's not obvious how to check the architecture of installed pacakges.  You have
to use --queryformat

$ rpm -q --queryformat '%{NAME} %{VERSION} %{ARCH}\n'  emacs kernel
emacs 21.3 i386
kernel 2.4.20 i686
Comment 49 Jerry Cornelius 2003-05-11 00:24:46 EDT
Regarding this solution:

------- Additional Comment #15 From Rob Cermak on 2003-04-11 16:01 -------

(1) post mortem using: linux recover

(b) rebooting: its doing fsck's on the journaled filesystems,
    seems like we are back in operation.

This solution worked perfectly for me.  My situation was a clean install of
Redhat 9 and an immeadiate updating of packages.  It went fubar, I found this
thread and used Rob's solution.  Rob is obviously a fscking genius.

Dear Redhat:  I will never ever pay for your products.  I will be migrating to
Slackware or Debian.  This bug has been found since early April and the update
packages you have at http://updates.redhat.com/9/en/os/i386/ still preserve the
bug for all time's sake apparently.  This is exactly what drove me from
Microsoft.  And getting into bed with IBM ain't gonna save you.
Comment 50 Richard Gill 2003-05-28 03:21:55 EDT
Rob Cermak's solution worked wonderfully for me.
I'd like to put on record here how the bug arose for
me. It was NOT through doing anything particularly 
stupid or non-standard.

The initial situation was glibc-2.3.2-11.9.i686.rpm,
as part of my RH9 (a smooth update from a clean install 
of RH8.0 two months previously, everything kept up2date).
The rhn applet advised me to update glibc-2.3.2-11.9 to 
glibc-2.3.2-27.9.  I found glibc-2.3.2-27-9 on rhn, 
there was no choice of architecture and the recommendation
was glibc-2.3.2-27-9.i386.rpm. In fact I did not even realise
the old version was i686 and anyway I had come to understand that
"i386" means "i386 and above" so even if I had noticed, I would not
have been concerned.
Comment 51 Matthew Caron 2003-06-08 16:47:59 EDT
(Copied over from bug 96995, which is a duplicate of this bug)

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. Therefore, no one knows which
was installed.

This should be tracked, checked for, and rpm should protect people from it.

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.
Sure, the internal bits are different, but that's what data abstraction is for.

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.
Comment 52 Ulrich Drepper 2003-06-09 23:36:51 EDT
*** Bug 90817 has been marked as a duplicate of this bug. ***
Comment 53 William Hooper 2003-06-20 18:58:20 EDT
Matthew Caron, please do some research before you call someone a dumbass:

1) From comment #48
$ rpm -q --qf "%{name}-%{version}-%{release}-%{arch}\n" glibc

2) It's a bug.  It has been reported as a bug.  The maintainer has acknowledge 
the bug (comments #9 and #28, probably more).  Get over it.

3) According to updates.redhat.com there have be arch specific rpms (for the 
kernel if nothing else) since RH 6.0.

Take it to a mailing list.  Bugzilla isn't the place for this.  I hope Red Hat 
gets and excuse to update glibc pretty soon so they can close this.
Comment 54 Savitha Rao 2003-06-25 09:30:13 EDT
I completed the fresh installation of RH9 and then updated all glibc-2.3.2-
11.9 including common,devel,etc also nptl with glib version 2.3.2-
27.9.i686.rpms and it working fine for me.

rpm -Uvh --replacefiles --replcapkgs --nodeps glibc-2.3.2-27.9.i686.rpms. 
Comment 55 Steven Shiau 2003-07-09 23:29:52 EDT
Since RH still "stay calm" so far... If I want to have my own glibc update, how
can I do for the glibc-9.spec in
redhat/9/en/i386/updates/glibc-2.3.2-27.9.src.rpm when I rebuild that srpm ?
Which part shouild I modify so that it will not happen like this ?
Comment 56 Jean Aumont 2003-07-30 02:06:06 EDT
Hi everyone,

After reading all the previous comments, 3 questions come to my mind:

1) Can we upgrade safely to the I386 library from the I686 library?
   (Hi want to support a park of I486 with NFS root)

2) Does the I386 contains the NPTL ?
   If not what are the application impacted by this ?

3) Could we get an option in the RedHat installer to force to
   installation of I386 library/package only?

Thanks for your help!!!

I do not think that this bug should get a low Priority and a low Severity.
The glibc library is the fundation of most applications. 
Priority and Severity shoud be set to high for this bug.
Also, wether we use the I386 or the I686 library, application should run
Comment 57 Josh Cogliati 2003-08-15 11:50:53 EDT
From glibc bugfix errata: https://rhn.redhat.com/errata/RHBA-2003-136.html 

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade. Only those
RPMs which are currently installed will be updated. Those RPMs which are
not installed but included in the list will not be updated. Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.


I would like to point out the fact that this DOES NOT MENTION i386 versus i686.
Sorry for yelling, but this problem seems to be a frequent problem (I just had
to fix it and was a little peeved that it had not been fixed even though I had
the same i686 -> i386 problem in redhat 7.1).  Any package that will make the
system completely inoperable if upgraded incorrectly should include a warning
somewhere about this problem.  Since rpm does not warn about this problem then
the errata for glibc should.  

In my humble opinion, one or both of two things should happen:

1. Every redhat glibc errata should have a statement along the lines of this:
*Warning:* updating from i686 -> i386 versions will cause the system to be
broken.  Use rpm -q --qf "%{name}-%{version}-%{release}-%{arch}\n" glibc
to determine the architecture of the installed glibc and use the same
architecture for the new version.

2. rpm should check if there is an architecture downgrade and should not do it
unless the user specifies something like --architecturedowngrade

Lastly, a bug that will keep bash and init from running until I physically go to
the machine and boot off of a cdrom is high severity so far as I am concerned.
Comment 58 Steven Shiau 2003-08-24 08:34:12 EDT
To Jakub Jelinek:
When will you try to fix this bug ? It's been 4 months since
glibc-2.3.2-27.9.i386.rpm is released.
Please fix this asap, we do appreciate that.
Comment 59 Jussi Torhonen 2003-08-28 02:53:07 EDT
Before installing glibc fixes from Errata, check the existing glibc versions and
the arch used:

rpm -qa --queryformat "%{arch}\t%{name}-%{version}-%{release}\n"

The following URL has pretty good recovery procedure, if you happened to install
grong glibc version and seg.faulted the whole system:

Comment 60 Richard Gill 2003-10-02 14:43:40 EDT
It's all very well that if everything goes wrong and you can still get onto internet you can find 
out how to recover; and it's also all very well that the problem could have been avoided 
altogether by using a whole load of sophisticated options to rpm, but I think it's clear that  
this problem is still causing a lot of trouble to some unlucky new redhat users who were 
basically just doing things by the book ... and this means that something should be done  
about it! I recently perversely installed redhat 9 on a new machine and upgraded all  
the packages which were recommended by up2date and the same thing happended again... 
this time I knew what to do. I did use the redhat 9 distribution as it first came out, maybe 
the current iso's have some things changed... 
Comment 61 Steven Shiau 2003-10-03 03:15:10 EDT
The bug fix is shown in 2.3.2-28,
where Jakub Jelinek <jakub@redhat.com> wrote:
- remove /lib/i686 directory before running ldconfig in glibc post
  during i686 -> i386 glibc "upgrades" (#88456)
It's fixed, but the rpm is not in the RH9 updates.
Well, in that case, I am trying to use glibc in rawhide
(glibc-2.3.2-78.src.rpm) or severn (glibc-2.3.2-57.src.rpm) to rebuild
it, but failed. Both I got the same error:
++ sed 's/^linuxthreads-\([0-9.]*\) .*$/\1/' ../linuxthreads/Banner
sed: relocation error: ./libc.so.6: symbol __libc_stack_end, version
GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
+ gcc -static -L. -Os ../redhat/glibc_post_upgrade.c -o
glibc_post_upgrade -DARCH_386 '-DVERSION="2.3.2"' '-DPVERSION=""'
gcc: relocation error: ./libc.so.6: symbol __libc_stack_end, version
GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
error: Bad exit status from /home/steven/rpmbuild/tmp/rpm-tmp.78959 (%build)

RPM build errors:
    Bad exit status from /home/steven/rpmbuild/tmp/rpm-tmp.78959 (%build)

Is that possible I can rebuild this fixed version in RH9 ?

Comment 62 KB 2003-10-23 22:08:55 EDT
This worked for me all fixed !!

Used knoppix, boot to runlevel 2, mkdir /newroot mounted /dev/hda3 /newroot
deleted all __db* on /newroot

$ export LD_ASSUME_KERNEL=2.2.5
$ su
Password: [enter root password]
# rpm -q glibc
# rpm -e glibc-2.3.2-11.9

# rpm -Uvh --replacepkgs --replacefiles glibc-*
Comment 63 KB 2003-10-23 22:14:29 EDT
This worked for me all fixed !!

Used knoppix, boot to runlevel 2, mkdir /newroot mounted /dev/hda3 /newroot
deleted all __db* on /newroot

$ export LD_ASSUME_KERNEL=2.2.5
$ su
Password: [enter root password]
# chroot /newroot rpm -q glibc
# chroot /newroot rpm -e glibc-2.3.2-11.9

# chroot /newroot rpm -Uvh --replacepkgs --replacefiles glibc-*
Comment 64 Brian Zammit 2003-10-26 19:39:21 EST
This is silly. Please fix the RPM so no more hosed systems occur.

I just spend two entire days working on a server, trying to figure out why a
"Segmentation fault" occured after a standard "rpm -Fvh *.rpm" command. How is a
user to know that first they go to the i686 directory for updates, then to the
i386 directoy (but not for the glibc packages lest you nuke your brand new
system), but only if your processor has been detected as i686 (which isn't
exactly obvious when issuing the "rpm -Fvh" command. Well actually, rpm doesn't
say anything about nuking your system if you're using i686 but trying to install
i386 (but how to know this anyways? Digital telepathy?))

Yes, this is a rant, rare for me. But two days of time lost to an error in a
critical RPM that was identified months ago is extremely frustrating.
Comment 65 Ulrich Drepper 2003-10-27 03:48:15 EST
*** Bug 107819 has been marked as a duplicate of this bug. ***
Comment 66 Ulrich Drepper 2003-10-27 04:06:43 EST
*** Bug 102569 has been marked as a duplicate of this bug. ***
Comment 67 Frederic Yolanda 2003-10-27 05:02:56 EST
Does Anyone know what other RPM Update that still have the similiar error like 
this. so i do not crashing my system the second time. Tankyu!
Comment 68 Steven Shiau 2003-10-31 04:23:46 EST
Jakub are asking for the testing glibc-2.3.2-27.9.3 (RHL9 errata candidate),
check this:

The files are in
Comment 69 Steven Shiau 2003-10-31 23:22:14 EST
The new version for this glibc is at
I'd like to confirm I can "upgrade" i686 glibc to i386 version in RH9.
Check this:
[steven@rh9 steven]$ rpm -q --qf '%{arch}\n' glibc
[steven@rh9 glibc]$ sudo rpm -Fvh
########################################### [100%]
########################################### [ 25%]
########################################### [ 50%]
Stopping sshd:[  OK  ]
Starting sshd:[  OK  ]
########################################### [ 75%]
########################################### [100%]
[steven@rh9 glibc]$ rpm -q --qf '%{arch}\n' glibc                    
After this, I reboot my machine, it seems everything is fine.
Nice going! Thank you, Jakub. Finally this "bug" is fixed, although it
exists over 6 months. Thanks again.
Comment 70 Ulrich Drepper 2003-11-05 13:21:39 EST
*** Bug 108756 has been marked as a duplicate of this bug. ***
Comment 71 Ulrich Drepper 2003-11-10 17:02:51 EST
Anybody still having problem with this with the errata version?  If
not, I'll close the bug soon.
Comment 72 Ulrich Drepper 2003-11-20 12:24:22 EST
Haven't heard about any problems, so I'm closing the bug now.
Comment 73 Jaska 2004-01-17 19:33:21 EST
Same thing still happens with Fedora Core 1. Yesterday I made the 
mistake to update glibc from up2date and now my system is useless. 

Haven't yet tried #15, I hope it helps. Fedora Core is a clean 
install. I compiled custom 2.6.0 kernel though.
Comment 74 Jason 2004-03-10 21:10:52 EST
Also experienced the same problem with Fedora Core 1 after running 
Comment 75 Barry K. Nathan 2004-03-10 22:19:05 EST
Jaska and Jason, even though the symptoms may be the same, it could be
a completely different bug. (Without more information it's hard to
know, however.)

I haven't seen the glibc upgrade via up2date on Fedora Core cause
anything like this on the computers I maintain at work...

Note You need to log in before you can comment on or make changes to this bug.