Bug 102569 - glibc postinstall script dies with exit code 121, hosing system
glibc postinstall script dies with exit code 121, hosing system
Status: CLOSED DUPLICATE of bug 88456
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-18 01:11 EDT by Charles Miller
Modified: 2016-11-24 09:56 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:58:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Miller 2003-08-18 01:11:05 EDT
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 ftp://updates.redhat.com/9/en/os/i386/
(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
enough.


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

How reproducible:
Always

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 07:27:18 EDT
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 02:07:00 EDT
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
glibc-i386.

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
% unsetenv LD_ASSUME_KERNEL
Comment 3 Jussi Torhonen 2003-08-28 01:29:21 EDT
The best recovery solution I have seen is:
http://www.linuxquestions.org/questions/archive/5/2003/05/4/57607

<-- 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-2.3.2-11.9.i686.rpm
/mnt/source/RedHat/RPMS/glibc-common-2.3.2-11.9.i386.rpm" to reinstall original
glibc
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 02:42:10 EDT
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 04:06:40 EST
> 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 05:19:45 EST
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). 
Isn't that the WHOLE POINT OF HAVING A PACKAGE MANAGER IN THE FIRST PLACE?

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 05:40:05 EST
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 13:58:07 EST
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.