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:
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.
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
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 ?
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"
> 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 ***
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)
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.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.