bug report regarding Oracle 18.104.22.168.0 Enterprise Edition on RedHat 7.0.
Operating System : RedHat 7.0
Oracle Version : Oracle 22.214.171.124.0 Enterprise Edition
Hardware : x86 (P-III 633, 128 Mb Ram, 8Gb IDE)
Updates Applied : glibc-2.1.94-3.i386.rpm
Unable to start the Oracle database server after installation
The Oracle 8.1.6 installation goes through smoothly including copying of
files and the linking process.
However when the new database creation program starts up, the server
manager (svrmgrl) starts dumping core.
This is not a JDK problem, as I have made the Oracle installer write to a
shell script and then tried to execute the shell script from the command
prompt. We have the same problem.
Oracle support claims that there is a bug with the RedHat glibc in 7.0.
If it would help, we can send core files.
using strace and ltrace can reveal a lot about where the program is dumping.
See Bug 18391 which has similar problems. Generally, the glibc version shipped with RH7 cannot be used by the Oracle 8.1.(5,6,7 ?) Universal Installer.
The "Fix" from the other bug report lets oracle works, but try getting anything else to run is a joke. You can spend all day downloading Oracle 9i AS and
it may compile alright, and you may be able to do the fix, but the actually forms and java processes seem to barf.
Is the *only* supported fix to go back to RedHat 6.2? That doesn't make sense from the business perspective since it isn't kernel 2.4 compatible and you
know anyone running a database wants to make use of the journaling file systems, logical volume managers and the stable 2.4.1 raid kernel. RedHat 6.2
just doesn't offer that.
I'm personally trying to get Applications 11i (11.5.2) to install. I was able to get the database to load by hacking it to use the glibc compat to compile
against, but the rapidwiz quickly failed afterwards when trying to run the tools cd install.
Is there anything i can do to help solve this issue? Redhat is redhat, and things should be forward compatible, especially when you buy RedHat 7.0 as a
server, i can understand the workstation version having its quirks.
Is there anyway to update the libc's or work through this without hacking it up?
Oracle code violates ABI rules left and right. It can break at any time and
likely every time a major glibc change is added. There is nothing left to do
but to pester Oracle to fix their code or use exactly the binary releasess they
were using in their QA. For longer lifetimes you can use Red Hat Advanced
Server which has a certified Oracle version. Otherwise you can only hope that
the next release won't hit yet another of Oracle's bugs.
For some of the problems (like object file portability) Oracle has some
workarounds but nothing will fully cure the problems unless they follow the ABI.
I will close the bug. There is nothing we can do for the old code and there are
RHL versions after 7.0 which support Oracle.