Forum OpenACS Q&A: Problem with C libraries after downgrading to glibc2.3.2 for installing Oracle 8 on Redhat E3

Request notifications

Subject says it all :)

Seriously folks,

I've run into a serious problem with the C runtime libraries on my linux Redhat Enterprise Server 3 box, while attempting to get Oracle 8 installed on it.

I referenced some postings here to get some guidance about installing Oracle, and one of the steps recommended was to downgrade to version 2.2.3-5 of glibc. Unfortunately, while doing this, I got a 'script error' message from rpm, and immediately after the OS was pretty hosed; doing an 'ls' command resulted in Floating Point Exception. I don't remember the exact format of the rpm error message, but is that scenario familiar to anyone here ? Also, I cannot recall if I used the --oldpackage flag when installing glibc-2.2.3-5; does anyone know if not doing so would have serious repurcussions ?

The kernel cannot load at boot time either; when I reboot I get a load of messages that look like this:

/bin/sh: relocation error: /lib/i686/libc.so.6: symbol _dl_catch_error,
version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

INIT; LD "x" respawning too fast: disabled for 5 minutes

I've used the repair disk to look at /lib, but I don't feel I know enough about the C runtime on RedHat to know what libraries to create links to. (Anyone know what a 'relocation error' is? My guess is it's something to do with loading libraries into the kernel. Also, what is "link time reference" ? My guess is that symbol is undefined in the ld-linux.so.2 lirary. Unfortunately, I don't have access to nm in repair mode.)

I'm thinking my best course of action now is to reinstall Linux and leave the parititions unchanged, but, does anyone know if and how I could fix this problem with a repair disk, and poking around /lib ?

Also, does rpm leave a log file anywhere ?

Thanks for any pointers on this.

Colm.

Just for reference, here is the How-to I used for installing glibc-2.3.2-5:

Work Around Procedure:

Since I was not able to find the glibc-2.3.2-5 RPMs available for download, I'm making the RPMs available on my website. These RPMs are copies of the glibc RPMs that came with the RH 9 CDs I bought in the store. I do not recommend to use any of the "compat" RPMs from older Red Hat distributions since RH 9 contains major changes.

Here is the procedure for installing glibc-2.3.2-5 temporarely on your RH 9 server:

Download the 2.3.2-5 glibc RPMs from here on my web site.

First make sure if these downloaded RPM's are not corrupt and if they were really built and signed by Red Hat. You never know if someone fiddled with these RPMs or replaced them. To ensure the integrity and origin of these Red Hat's RPMs, run the following commands:
$ su - root
# rpm --import /usr/share/rhn/RPM-GPG-KEY  # add Red Hat's PGP public key to the RPM database
# rpm --checksig glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm

glibc-2.3.2-5.i686.rpm: (sha1) dsa sha1 md5 gpg OK
glibc-common-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK
glibc-devel-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK
#
Downgrade glibc, glibc-common, and glibc-devel:
# rpm -Uvh --oldpackage glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm
If you get the following error:
error: Failed dependencies:
        glibc = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
        glibc = 2.3.2-11.9 is needed by (installed) glibc-utils-2.3.2-11.9
        glibc-devel = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
        glibc-devel = 2.3.2-11.9 is needed by (installed) nptl-devel-2.3.2-11.9

then you can temporarily remove these RPMs (glibc-debug, glibc-utils, nptl-devel) from your system until you upgrade the glibc RPMs after your Oracle installation:
# rpm -e glibc-debug glibc-utils nptl-devel

Now try to run runInstaller again.

After Oracle has been installed, you can upgrade glibc, glibc-common, and glibc-devel again. For example:
# rpm -Uvh glibc-2.3.2-11.9.i686.rpm glibc-common-2.3.2-11.9.i386.rpm glibc-devel-2.3.2-11.9.i386.rpm

According to Red Hat, binary compatibility in Red Hat Linux is always guaranteed for binaries and shared libraries accross releases, but not for .o files nor .a files. However, compatibility is guaranteed for .o files and .a files. _within_ a realease. Since glibc-2.3.2-5 and glibc-2.3.2-11.9 are from the same release, compatibility should be guaranteed for .o files (Oracle's .o files which have been created during the Oracle installation) and .a files.
This means that Oracle should be fine when you upgrade glibc after the Oracle installation.

Why are you even trying to install Oracle 8.1.x? Do you have some reason for wanting to use it rather than 9i? I'm told that recent versions of OpenACS work fine with 9i - not sure about 10g though.
Good question... Short answer is it's needed on our Linux box for compatibility with a database integration product.

Do you need to downgrade glibc to 2.3.2 for installing Oracle 9i ?

Thanks,

Colm.

It's been 1.5 years since I last wrote my notes on Installing Oracle 8.1.7 on Linux, but maybe there's something in there useful to you.

I hadn't heard of anyone needing to downgrade anything in order to install Oracle 9i, as far as I knew such problems were restricted to 8i. As 9i starts getting old (relative to current Linux systems), maybe you will have to do something like that, but I don't know.

Thanks; we decided to go with Oracle 9.

Any advice for what's the least painful version of Oracle 9 to install on Redhat Enterprise Server 3 ?

Thanks,
Colm.

Colm,

Ths is a bit late, but for future reference...  I am betting that your first problem resulted in a mismatched architechture on the rpm files.  Say your current glibc is built for i686 then you downgraded using an i386 glibc.  This messes practically almost everything on your system including rpm itself so it's hard to recover.  There is a solution to this by doing doing LD_ASSUME_KERNEL and rpm --replacepkgs voodoo which I can't recall anymore.