windoze-like nightmares with rpm upgrade of glibc on RH9
Linux - DistributionsThis forum is for Distribution specific questions.
Red Hat, Slackware, Debian, Novell, LFS, Mandriva, Ubuntu, Fedora - the list goes on and on...
Note: An (*) indicates there is no official participation from that distribution here at LQ.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
After this, any further attempts to rpm got "Segmentation fault",
I couldn't open a new xterm, and finally the system crashed and
would not reboot [I'll spare you the gory details of what it did do,
though they probably would give a clue as to what had got ****ed-up].
I couldn't figure out how to get out of the mess and finally installed RH9
Linux anew on the second hard disk so that at least I could recover
my data from the first.
Was I just being stupid or is there a bug in the rpm's?
Is there a way I could have cleverly backtracked and got out
of the mess, with the the emergency rescue disk?
Yeah, I really need to bug Jeff about putting in some form of warning into RPM for users trying to upgrade glibc. A bit Windowsish but way too many people have trashed their machien doing this. What with all the press about this upgrade due to Wine/Java breaking, people have been turning their attention towards it a lot.
Anyway, you can probably boot up a rescue system and force the reinstall of the default RH9 glibc package. rpm --force -Ivh glibc-2.3.whatever....
I rather suspect that you used an RPM of glibc not designed for Redhat 9 - glibc isn't like other packages, you don't upgrade it unless there's a security fault with it.
Thanks very much for the instant and useful reponse. Actually, I got the very latest rpm's for glibc, glibc-common, and glibc-devel from redhat network itself, and they were specifically built for redhat 9. So I think I was rightly surprised that everything went so spectacularly wrong. Haven't seen anything like it since windoze days (when of course it was a daily - now let's be honest, monthly - occurrence).
I'm a bit wary of getting myself into the same trouble again just to test this rescue business, but in case I do, just for the zen of it: do I need to have the old rpms somewhere in order to do this downgrade from the emergency disk? Don't I need to tell rpm that it is the rpm packages on the hard disk which I want to downgrade, not the rpm packages on the rescue floppy?
I had a very similar problem on a fresh install of RH9. I installed apt-get, and then did 'apt-get update' and 'apt-get dist-upgrade'. I got several failures during the dist-upgrade, including apparently glibc. After it was finished, I got segmentation faults whenever I tried to use apt-get or rpm. Fortunately, it was a fresh install, so I just started over. Guess I will stick with up2date for now...
Originally posted by pf1359 Guess I will stick with up2date for now...
According to the bugzilla page mentioned earlier in this thread, some people have had this problem while doing everything according to the book, including using up2date! So first study the instructions there on how to recover gracefully. It seems that the problem occurs when up2date tries to install an i386 rpm over an older i686 rpm. At the very end it should remove files left from the old package. But then it notices that those files belonged to a more advanced computer architecture and refuses to do the job. I was in the lucky position that I had a second
and empty hard disk, so could do a fresh install on a second disk and then salvage my files from the first. I still have to see if I can repair the damage done on the original installation.
I would guess, if it's a problem with glibc, you could ignore that package before performing up2date. That's not an option with apt-get dist-update - it downloads and installs everything without an option to ignore.
I'd like to put on record what was the cause of this bug. It came about through inadvertently trying to upgrade an i686 rpm with an older version of glibc to an i386 rpm with a newer version. It turns out that this is "not done". At some stage the rpm program needs to clean up remnants of the older package, and at that stage the higher architecture takes precedence. The result is a mess.
The solution is spelled out by a contribution from Rob Cermak in the Bugzilla thread referred to above. It worked wonderfully for me.
My initial situation had 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.
It seems that rhn has now added an i686 version of the newer glibc so in future this problem is less likely to arise. Anyway, the episode shows what it means to live "on the bleeding edge"! The newest distro, kept completely up to date - living dangerously!
Originally posted by gill1109 I'd like to put on record what was the cause of this bug. It came about through inadvertently trying to upgrade an i686 rpm with an older version of glibc to an i386 rpm with a newer version. It turns out that this is "not done".
Thank you for detailed explanations, they helped a lot ! Here is the solution, that I have applied yesterday and restored my system:
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.