From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT)
I am attempting a first-time install of Oracle8iEE release 2, version
8.1.6. We are running Red Hat 7, kernel 2.2.17-4smp on a duall processor
Compaq Proliant 1600, i686. While in GNOME I was initally able to launch
runInstaller from the CD, however, the install would fail when attempting
to intialize the database with ORA-03113 end-of-file on communications
channel, which I am aware is consistent with the well documented
incompatibility between 8i and glibc 2.2. After applying glibc and gcc
updates the runInstaller utillity will no longer launch.
Steps to Reproduce:
In an attempt to resolve the problem I applied the following upgrade
glibc (RHBA-2000:079 [glibc-2.2-9.i686.rpm,
gcc 2.96 (RHBA-2000:132 [cpp-2.96-69.i386.rpm, gcc-2.96-69.i386.rpm,
gcc-c++-2.96-69.i386.rpm, gcc-chill-2.96-69.i386.rpm, gcc-g77-2.96-
69.i386.rpm, gcc-java-2.96-69.i386.rpm (which also required the
installation of libgcj-2.96-22.i386.rpm, libgcj-devel-2.96-22.i386.rpm,
and zip-2.3-8.i386), gcc-objc-2.96-69.i386.rpm,
Presumably unrelated, the following patches were also applied in response
to Red Hat alerts:
mutt-1.2.5i-8.5.i386.rpm, nscd-2.2-9.i386.rpm, sgml-tools-1.0.7-
1.1.i386.rpm, slrn-0.9.6.4-0.6.i386.rpm, and slrn-pull-0.9.6.4-
I also followed the instructions from the posting on the valinux site. I
downloaded and installed the i386-glibc2.1-linux.tar.gz and relinked gcc
cc and ld in the /usr/bin to the members in the new /usr/i386-glic-2.1-
linux directory and removed the libc.so, libdl.so libm.so, libc.a, libdl.a
and libm.a members from /usr/lib.
After the glibc updates were applied runInstaller could no longer be
launched from the CD (i.e. Installer Window would not come-up).
Expected Results: runInstaller should launch the Oracle Universal
I have also tried installing the oracle8161_tar.gz and launching
runInstaller from the ORA8IR2 directory created under $ORA_HOME. I have
tried restoring the original /usr/bin and /usr/lib members, but the
runInstaller behavior is the same.
A posting from Allen Marshall (csi_rockhopper) - 01:01pm Jan 12, 2001 EDT
(220.127.116.11) on the Red Hat Forums at http://www.redhat.com/WebX?
firstname.lastname@example.orgS89aHmIpBG^0@.ee6c7c3 appears to be reporting the same problem.
Reportedly he resolved the problem by performing a "phony" upgrade, which I am
relunctant to do on a production box, unless it appears to be the only
A posting at technet.ora alerted me to the fact that there are known issues
involving the glibc i686 upgrades documented on the Red Hat beta site at
http://www.redhat.com/apps/download/beta/rhl.html. Specifically, among the
known issues "Some Java JDKs (both from Sun and IBM) don't work with the i686
version of glibc ..." "Additionally, the i686 version of glibc only supports
2.4-based kernels." and "If you... need to run a 2.2-based kernel, install the
i386 version of glibc...". Too bad this was so hard to find.
After upgrading from glibc 2.2-9.i686 to 2.2-12.i386, runInstaller would launch
normally. This, in combination with the solutions posted on technet.ora
Discussions/Linux as "Oracle 8.1.7 on Red Hat works (here's how)" and "Oracle
8.1.7 Running on RH7.0" worked for me to get a first time installation of
Oracle8i on Red Hat using a 2.2 kernel.
This link also has an installation post-mortem of some interest...
SOmething else that is bothering me - is it possible that ORacle installation is choking when running Linux-SMP ? We have a Dell PowerEdge with 2
CPU and I have been operating with SMP mode. While I thought I was slavishly following my previous approach to installing Oracle on RH7, I got a new
error not encountered in the previous trials. I will try to post the text of the error later as a a followup, but it appeared to be something to do with cpu and
machine references, in a c routine that references sys/types.h. My naive suspicion is that the c subroutine, which is generated by an Ora shell script, is
referencing SMP constants somehow, rather than singe-cpu values. I will follow up by booting in single CPU mode and trying the installation again.
Well, single CPU made no difference. A Red Hat Red Herring, I guess.
The key thing to do is to install the glibc upgrade to 2.2-12.i386, which made everything work again. Given short term memory loss on my part, I must
have done this last time around too when this succeeded. Until I explicitly bashed this on, weird stuff happened. Also, of course, do the valinux fix
described elsewhere (downgrade gcc, cc, ld to glibc-2.1 and so forth)