Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 102569 - glibc postinstall script dies with exit code 121, hosing system
Summary: glibc postinstall script dies with exit code 121, hosing system
Status: CLOSED DUPLICATE of bug 88456
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-18 05:11 UTC by Charles Miller
Modified: 2016-11-24 14:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:58:07 UTC

Attachments (Terms of Use)

Description Charles Miller 2003-08-18 05:11:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Description of problem:
From a virgin installation of Intel RedHat 9.0, using the
glibc-2.3.2-27.9.i386.rpm downloaded from
(but updated from the local filesystem).

RPM command line: rpm -Fvh glibc-2.3.2-27.9.i386.rpm

Post-install script fails, error message says it exited with code 121

System is hosed from then-on, all attempts to run anything seg-fault and die,
attempts to boot system die when init can't respawn the seg-faulting tty's fast

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

How reproducible:

Steps to Reproduce:
1. Install RedHat 9.0
2. Download glibc updates from RedHat
3. rpm -Fvh glibc-2.3.2-27.9.i386.rpm

Actual Results:  System is fucked

Expected Results:  System should not be fucked

Additional info:

Comment 1 John Beimler 2003-08-18 11:27:18 UTC
looks like you installed the i386 glibc on a system that was not running an i386
kernel. RHL 9 has NPTL (threading) in the i686 kernel, but not in the i386. The
mismatch can cause a fubared system. 

Update to the i686 glibc if you can.

Comment 2 jmccann 2003-08-20 06:07:00 UTC
I just spent the last few hours dealing with this.  Not cool.

Just as a heads up this is going to happen to a lot of people because the
rhythmbox and gstreamer installs recommend that glibc-i686 be downgraded to

That is because they don't work hardly at all with the i686 version.

BTW, they way I got my system back was by doing (in tcsh):
% setenv LD_ASSUME_KERNEL 2.2.5
% rpm -Uvh --force glibc-2.3.2-27.9.i386.rpm

Comment 3 Jussi Torhonen 2003-08-28 05:29:21 UTC
The best recovery solution I have seen is:

<-- begin of quote -->

1) insert CD RedHat 9.0 disk 1 into CDROM
2) boot computer from CD
3) type "linux rescue" in the installation prompt
4) answer few questions about language and network settings, then press
"Continue" when asked about old system mounting to /mnt/sysimage
5) when you get shell prompt, type "mount" to check if CD is mounted to
/mnt/source and old system is mounted to /mnt/sysimage
6) type "rpm -ivh --force --root /mnt/sysimage
/mnt/source/RedHat/RPMS/glibc-common-2.3.2-11.9.i386.rpm" to reinstall original
7) type "chroot /mnt/sysimage" to check if you can get old root instead of usual
"Segmentation fault", then simply type "exit" twice to exit from shells and
reboot computer. Enjoy. :)
<-- end of quote -->

That really does the trick.

But, the real problem still exists: why rpm allows me manually update old
glibc*.i686.rpm with new glibc*.i386.rpm from Errata and break the system? If
you cannot resolve this with your rpm scripts and dependencies, please give us
good instructions how to update Red Hat Linux installations manually, if your
arch was athlon/i586/i686. Using pure i386 stuff is not problematic I guess, but
for example using AMD Athlon platform, where can I read clearly, which packets I
shouls install from Errata? I mean sure I will install
athlon/kernel-2.*.athlon.rpm but should I use i686/glibc*.rpm instead of
i386/glibc-2*.rpm ?

Comment 4 Jussi Torhonen 2003-08-28 06:42:10 UTC
BTW, before starting to install Errata fixes manually, you really should chech
which arch version have been used before. To do this, the following command is
very useful:

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

Comment 5 Ulrich Drepper 2003-10-27 09:06:40 UTC
> why rpm allows me manually update old
> glibc*.i686.rpm with new glibc*.i386.rpm from Errata and break the system?

Because Unix always gives the sysadmin enough rope to shoot him/herself.  If you
administrate a system you are supposed to know what you do.

*** This bug has been marked as a duplicate of 88456 ***

Comment 6 Charles Miller 2003-10-27 10:19:45 UTC
RPM is a package manager. Is it too much to ask that it should, perhaps, manage packages 
competently? Aren't package managers supposed to handle things like dependencies to ensure that 
moving from A to B doesn't break C? (Or in this case, that moving from A to B doesn't break B). 

Thankyou for reminding me why I hate dealing with Redhat.

(Yes, my employer was a paying Redhat customer. Yes, I'll be doing everything possible in my 
power to ensure that particular mistake isn't repeated in the future)

Comment 7 Jakub Jelinek 2003-10-27 10:40:05 UTC
There is a tool in RHL which ensures you don't upgrade wrong architecture.
It is called up2date and it handles this just fine.  Yes, there is a bug
in glibc 2.3.1-35 through 2.3.2-27.9 in that i686 -> i386 "upgrades" don't work
(fixed in 2.3.2-28 and it will appear in RHL9 glibc errata).  But the main thing
is that you shouldn't be doing such "upgrades" in the first case, as you severely
cripple your system functionality with it (even when the bug is fixed).
You loose NPTL, lots of various optimizations, TLS support.
rpm allows you to do it because there are legitimate (although rare) cases
where you want to do a i686 -> i386 "upgrade" - e.g. if you're installing
a disk on i686 box which ought to be used later on on < i686 box.

Comment 8 Red Hat Bugzilla 2006-02-21 18:58:07 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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