when create database use dbassist, process stop there do nothing.
Oracle's dbassist is a Java application and Java seems to be broken for the glibc coming with RHL7...?!
It isn't entirely a JDK problem. Oracle's installer uses it's own JRE to install the thing, and it's capable of going through the install fine where the various JDK's that fail to run fail immediately. Oracle's utilities all use the same JRE as it's installer uses (it is possible that some aspects of the dbassist utility may be triggering things that are broken with the JRE). During the creation of the oracle database, you'll note that there are core dumps located in ORACLE_HOME/dbs directory. This is where the Oracle server dumps core. You'll find core_XXXXX directories located in there (or something to that effect). This is the oracle server process dumping core. It may be related to the Jserver aspect of oracle. I'll be re-installing oracle without it's Jserver support this weekend to see if I can get the thing working. The exact same thing happens when you attempt to start an Oracle database (and once again, my backup database includes Oracle's Jserver components so this may be the root of the cause). Still this really should probably be a glibc bug and not an AnotherLevel bug *8^).
this problem was discussed on oracle's technet, too. http://technet.oracle.com:89/ubb/Forum7/HTML/004821.html oracle thinks its a problem is an interaction with the new GNU Lib C shipped with RH 7. oracle sais they have communicated the problem to Red Hat. any statement from redhat regarding this would be nice...
Does it help if you install this week's glibc errata or not?
*** Bug 18880 has been marked as a duplicate of this bug. ***
yesterday i installed the new glibc package. (but not yet the new glibc-devel package) that did not change the situation
Ok, one more thing about Oracle. Just "debugged" another problem here. Starting from glibc > 2.1.91, _running_ oracle database (installed with 2.1.3) behavos incorrectly here. When I connects to it using any tool (e.g. sqlplus) and issue some queries, all looks just fine. But if I "sleep" some time (about ~10 mins) and issue just the same query again, it will lock up for about 1..3minutes and only after this will respond with results. Interestingly that if I issue another query (or just login/logout) at a time of lockup, both clients will continue (this was a "workaround" -- if your query stalled, just "ping" a db using sqlplus). _All_ glibc versions starting from 2.1.92 shows this nicely here. And both 7.0 and errata's 2.1.94 shows it. For now, I have a workaround here: I placed all the glibc-2.1.91-19 files from /lib to /usr/oracle/lib (oracle hardcodes /usr/oracle/lib to ld_run_path), so that oracle's processes uses this exact version (it works just fine), while other processes uses never version from /lib. It is ugly. But definitely something was broken between 2.1.91 and 2.1.92 "releases". I tried to debug this using strace, but for no avail now -- oracle issues so many _ugly_ syscalls (yes, it is _very_ ugly in this respect -- the way it works) that I was unable to determine what's happenes... BTW, Should this be a new bug? :)
Ok, some new info. My problem is not solved by using 2.1.91 -- it just takes longer time to start appearing again; and on another machine that uses exactly the same kernel (2.2.16-3) and glibc (2.1.91-18) things works well. I need further investigations here. But some issues related to the original problem. $ORACLE_HOME/bin/oracle executable won't start (it segfault on startup/init) when linked by current 7.0 gcc with any version of glibc >= 2.1.91 (and using 7.0 binutils -- compiler may be irrelevant here). Executable linked by previous gcc with previous glibc works (with some glitches but them can be unique for me). Remember -- when oracle installs it relinks all the executables! I'd suggest to extract original `oracle' executable (available in oracle installation media somewhere at stage/Components/...rdbms... inside .jre (.zip) archive) and see if _that_ executable works.
I recompiled glibc 2.1.3 from RedHat 6.2 using gcc 2.96 under 7.0. If I replace sprintf.os and vfprintf.os compiled with gcc 2.96 under 7.0, the resuling libc-2.1.3.so won't work right with oracle under RedHat 6.2. So there are differences in sprintf.os and vfprintf.os between compiled with egcs in 6.2 and gcc 2.96 in 7.0. I am not sure if the same files are affected in glibc 2.1.94.
The main problem Oracle has and has been informed about is the relinking on the target. That's a big no-no, glibc has never guaranteed binary compatibility with object files compiled with different glibc headers (as opposed to maintaining binary compatibility with shared libraries and binary programs). This can break between any minor glibc releases, not just 2.1.3->2.2, e.g. 2.1.2->2.1.3 could have beaten them as well. So for now, you should install Oracle on 6.2 (or hack their install scripts so that the scripts use i386-glibc21-gcc as compiler to link stuff together and -L/usr/i386-glibc21-linux/lib somewhere in LDFLAGS). To H.J.: can you find out what arguments given to *printf behave differently?
Just as an FYI. This has been reproduced in our test lab using 7.0 with the latest glibc update. All goes well until database creation where it hangs at Initializing Database 80%. Looking around shows the binary 'svrmgrl' taking up 99.9% CPU and 2.5 MB of memory using top.
From my experience, it is better to build database by hand, not using the installer/dbassist. Use bin/genclntsh to rebuild oracle client shared lib, make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk install to relink/install oracle executable, make -f $ORACLE_HOME/svrmgr/lib/ins_svrmgr.mk install to install/relink svrmgr, and then run script generated by dbassist (placed somewhere in $ORACLE_HOME, probably in install/ directory). This way you can see what's happened and what statement(s) executing. BTW, 80% is probably the place where database internal java machine should be initialized (not to confuse with external java machine, this one is all inside oracle and does not uses any external support files except of those provided by oracle itself (again, not counting jdk as "external" for oracle product) and by the c libraries). Look to the logs, them should be available somewhere (this is why I prefer to install things myself -- there is a trouble finding those logs and to figuring out where error occured, as the dbassist logs contains _tons_ of debugging info from dbassist itself).
BTW, dkl, this was a step further. "Normally" oracle executable won't start, so dbassist should stop near 0%. At your case, 80% was done.
Plsase get http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/README http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/README.Oracle8i http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/i386-glibc-2.1-linux.tar.gz for instructions. Let me know if it works for you or not. BTW, glibc 2.1.94-3 is required.
H.J.L, can you please tell what exactly modules/objects caused the problems (already mentioned *printf)? Is that in startup modules like crt*.o, or in libc? If it is the latter, then it is simpler/better to just add little library with expected by oracle interfaces (only including those objects) and place it to e.g. $ORACLE_HOME/lib (and add corresponding -l option) instead of making all that great changes. This will _not_ cure installation process (as one can't just easy edit makefiles while oracle installs), but it is ok for "after-install" stage -- just trivial script that patches makefiles and calls `make -f ... install'; after that one can use dbassist or something to actually create database. But yes, if is't in the crt*, than this will not work. (Huh, probably will, by playing with -B option for gcc).
gcc 2.96 is fine and glibc 2.1.94-3 is fine. The problem is shmctl (): # objdump --dynamic-sym /lib/libc.so.6 | grep shmctl 000e22d4 g DF .text 00000219 GLIBC_2.2 shmctl 000e24f0 g DF .text 00000051 (GLIBC_2.0) shmctl Oracle 8i is compiled against glibc 2.1.3. During the Oracle install, they link/compile binaries from .o and .a files. Glibc 2.1.3 has to be used for the Oracle install. shmctl is just one of those functios which have a newer version in glibc 2.2. That is why my glibc 2.1 SDK is needed. BTW, compat-glibc and kgcc are only available under RedHat. And they are not quite right as a glibc 2.1 SDK. My glibc 2.1 SDK should work on all glibc 2.2 based systems.
Can the others also affect this? I see also the same changes with (only "interesting" ones are listed): msgctl, semctl (oracle uses semaphores), getrlimit, fsetpos/fgetpos (!). btw, what about just adding some sort of ld script (instead of providing additional lib or the whole sdk) that defines versions of that routines explicitly (like "GLIBC_2.0 { shmctl; ... }") in $ORACLE_HOME/lib/libc.so (that should also point to /lib/libc-... and others like /usr/lib/libc.so does)? (I'm not a guru here, just looked to `info ld' here -- this just to show an "idea", details maybe different). Or, another case, add a lib (also can be done via $OH/lib/libc.so) with contents like __asm__(".symver shmctl,shmctl"); (compiled ofcouse!) I still didn't tried the sdk (it seemed to be that our provider have PMTU discovery problem, so it's hard to download large files for me now). Does anybody knows if this sdk cures the problem? I saw that oracle dies at shmctl call, so probably you're right here; but sprintf also was mentioned here -- what's with _this_ routine?
I got 2 confirmed success reports with my SDK.
The valinux fix did not work for me. I did a fresh RH7 install, made the valinux changes (steps 1, 2, 3: README.Oracle8i), installed Oracle and did the valinux post install (undo the valinux changes with steps 5, 6, 7: README.Oracle8i). I did not try to create the database by the shell scripts saved from dbassit since I wanted to adjust the listerner parameters first. lsnctrl stop|start just segs faults. Without the listerner, I do not consider this a workable fix. If I have installed and created databases under RH6.2, will upgrading to RH7 (by the RH7 installer upgrade option) still make Oracle unusable?
I can reproduce the problem. It is because somehow glibc 2.2 is used to relink lsnctrl. I will work with Oracle to fix it.
Oracle has been already told by Ulrich Drepper and myself that they there is no binary compatibility for .o/.a files assured even between glibc minor releases. H.J., what's the problem with compat-egcs and compat-glibc that it cannot be used for Oracle installation?
You cannot use /usr/lib nor /usr/include for any glibc 2.1 compile/link. My glibc 2.1 SDK won't go outside of /usr/i386-glibc-2.1-linux for anything. It even comes with its own ld, which won't even look at /lib nor /usr/lib.
I updated http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/README http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/README.Oracle8i http://ftp.valinux.com/pub/support/hjl/glibc/sdk/2.1/i386-glibc-2.1-linux.tar.gz Please read my new instructions and try again to see if it fixes lsnrctl.
The latest valinux fix seems to work (listener, dbassst). I do not have a comprehensive test suite for full varification but things look fine so far. Thanks. p.s. On the valinux ftp site there are multiple glibc (i386-glibc-2.1-linux-20001016.tar.gz and i386-glibc-2.1-linux-20001017.tar.gz). What is the difference between them? Does one have a debug symbols and the other does not?
i386-glibc-2.1-linux-20001016.tar.gz is removed now. You can forget about even it existed :-).
*** Bug 19101 has been marked as a duplicate of this bug. ***
Looks like nearly the identical problem has occurred before: ftp://external-ftp.us.oracle.com/server/patchsets/unix/LINUX/bug878586/README
Does anyone have the final fix for this?? I cannot get the above to work. If I move the lib's to a saved folder as someone above suggests, then nothing will work, ie ls, su, and the oracle installer cannot even start without these libraries. If I explcitly point my LD_LIBRARY_PATH to the glib2.1 directory everything seg faults. I followed the above fix exactly with the exception of moving the libraries which did not work. Can anyone point me in the right direction. I have the updated glibc, as well as the other one I downloaded from valinux. Thanks greatly, Chuck
Unfortunately the SDK doesn't really solve the real problem. Nor does the fault of this problem Oracle's, though they've certainly exercerbated the consequences. The fact is that the binaries Oracle ships with are only part of the system. It also includes the client libraries. From what you've described there is absolutely no way to ship a portable library that can be used even on multiple minor versions of glibc. To comply with your policies Oracle would have to ship a separate set of .o files for each minor release of glibc. And any subsequent release would risk making it impossible to compile clients. That's frankly ludicrous.
That's how symbol versioning works and has worked ever since it appeared. If you want to ship a library portable accross many glibc major/minor versions, simply ship it as a shared library and it will work. Symbol versioning is a matter of final link.
jakub , we have RH7 and Oracle 8i. We applied the fixes as specified by hjl@valinux . the database has crashed twice in the last 24 hrs. I was wondering if this was a long-term fix, or is there some patches from red- hat/valinux, that has been released already or in the pipeline. I did see some new 'respin' files in the ftp directory, will they have any useful updates that will help in this oracle problem. thank you. (hjl@valinux included)
I finally relinked oracle exes on 7.0 without big valinux "collection". Here is how I did this, in case this can be useful to someone. I got glibc-2.1.3-xxx.rpm from redhat mirror (from 6.something, does not matter). I extracted and put the following files to $ORACLE_HOME/lib: libc-2.1.3.so libpthread.so libdl.so ld-linux.so.2 (those was symlinks to some like libXX-2.1.3.so, I copied targets). After this, I created file $ORACLE_HOME/lib/libc.so with one line: --- cut --- GROUP ( /usr/oracle/lib/libc.so.6 /usr/oracle/lib/ld-linux.so.2 /usr/lib/libc_nonshared.a ) --- cut --- (ld-linux needed here to satisfy reference to _dl_init_next from libc.so.6). My $ORACLE_HOME was in /usr/oracle, as you can see. Ok, this is a "development environment". I relinked all oracle exes with this "setup". From this point, all goes ok (works for me (tm)). Even one thing that I not tried (and will not try) may be considered is to do that steps before installing oracle: create ORACLE_HOME/lib and place all those files there, and _after_ just install oracle as usual. This probably should work. BTW, I have no java components here (moreover, I removed all references to java (aka java "option") from oracle libs (hack, hack!)), so I not checked if this will work with java. But why not? :) BTW2, all other tools used from rh7.0 including gcc/binutils etc etc, even math library was from glibc2.2 (as you can notice). That's all... Please correct me if I'm wrong here.
Oops, one little correction: GROUP ( /usr/oracle/lib/libc.so.6 ... ^^^^^^^^^ should be /usr/oracle/lib/libc-2.1.3.so instead... Just my typo. BTW, the names I choosed for all those .so's will allow both build with glibc-2.1.3 and run with system's 2.2, since for libXXX.so used for build, but libXXX.so-N used for run.
Hello All, Just to let you know. I created a tar/gzip image of entire Oracle directory from a RedHat 6.2 Oracle 8.1.6 installation and copied it over to my RedHat 7.0 installation and unzaipped the contents into exactly the same directory path as on RedHat 6.2. After setting the ORACLE_HOME and ORACLE_SID exactly same as on the RedHat 6.2 system and copying the /etc/ora* files, I was able to startup my Oracle 8.1.6 database on the RedHat 7.0 without problems. Initial tests show that it works and I can connect to the database. More extensive tests may be needed to establish the stability of this installation. If you can, try getting a gzip image of the oracle installation from a RedHat 6.2 system. This might be one of the solutions for those who can manage to get such a installation image.
*** Bug 20866 has been marked as a duplicate of this bug. ***
I have a problem with the installation of JServer of Oracle 8.1.6 EE R2 on Red Hat 6.2. Every time I try to install it, I get "end-of-line on commuincation channel" and "VM: Killing oracle process" ... Also, I've another problem when I use dbassist the modify an existing database, dbassist crashes ... Do these problem relate the the problem of glibc? Any help will be apprecaited very much. I tried the discussion forums in otn.oracle.com. But, it did not get helpful answers ... I hope I get it here
Hi... I ran the following script to change all references to cc and gcc to /usr/bin/i386-glibc21-gcc, and changed the genclntsh script so that LD uses a different link script, searching for /usr/i386-glibc21-linux/lib first. After that, I could create and connect to the database, and had no problems with listener. This idea is based on what the patch supplied for Oracle 8.0.5 does. Robson. #!/bin/sh cd $ORACLE_HOME LIST=`rgrep -rl -x mk "gcc" .` for FILE in $LIST ; do # Make a backup if [ ! -f $NAME.orig ]; then cp $NAME $NAME.orig fi # Change cc and gcc for /usr/bin/i386-glibc21-gcc sed -e "s/gcc/\/usr\/bin\/i386-glibc21-linux-gcc/ s/CC=cc/CC=\/usr\/bin\/i386-glibc21-linux-gcc/" $NAME > $NAME.new mv $NAME.new $NAME done
Doc ID: Note:121176.1 Subject: 8.1.6.1 doesn't start on RedHat Linux 7.0 after relinking Type: ALERT Status: REVIEWED Content Type: TEXT/PLAIN Creation Date: 03-OCT-2000 Last Revision Date: 24-OCT-2000 Language: USAENG ****************************************************************************** This article is being delivered in Draft form before publishing standards have been applied, and may contain errors. Please use the MetaLink "Feedback" button to advise Oracle of any issues related to this article or this process. ****************************************************************************** Oracle 8.1.6.1 does not start on RedHat Linux 7.0 after relinking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Versions Affected ~~~~~~~~~~~~~~~~~ Product & Oracle versions affected 8.1.6.1 Enterprise Edition for Linux Platforms Affected ~~~~~~~~~~~~~~~~~~ RedHat Linux 7.0 and probably any glibc-2.1.9x based distribution. Description ~~~~~~~~~~~ After upgrading from earlier versions of RedHat Linux to RedHat 7.0 Oracle fails to start up after being relinked. The reason is a generic incompatibility across different major versions of GNU libc that does not guarantee that a binary linked against a version of glibc will keep working if relinked in an environment of a later major glibc release. Since Oracle 8.1.6.1 is linked against glibc-2.1.3 and RedHat 7.0 ships with glibc-2.1.9x, we experience the described problem. Likelihood of Occurrence ~~~~~~~~~~~~~~~~~~~~~~~~ This problem will occur after relinking Oracle to install patches or kernel options or to deinstall them. It will NOT occur if Oracle is not relinked after the OS upgrade. Possible Symptoms ~~~~~~~~~~~~~~~~~ Starting up the database fails with ORA-3113 after some time spent looping in semop() and a core file is generated. The stack trace taken with GDB is the following: (gdb) where #0 0x404c74e1 in __kill () from /lib/libc.so.6 #1 0x8469156 in slcra () #2 0x846cd01 in ssexhd () #3 0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221208616, esi = 3221208744, ebp = 3221208516, esp = 3221207644, ebx = 3221207676, edx = 0, ecx = 3221207676, eax = 0, trapno = 14, err = 4, eip = 138857746, cs = 35, __csh = 0, eflags = 2163270, esp_at_signal = 3221207644, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 8}) at signals.c:97 #4 <signal handler called> #5 0x846cd12 in ssexhd () #6 0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221209840, esi = 3221209968, ebp = 3221209740, esp = 3221208868, ebx = 3221208900, edx = 0, ecx = 3221208900, eax = 0, trapno = 14, err = 4, eip = 138857746, cs = 35,__csh = 0, eflags = 2163351, esp_at_signal = 3221208868, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 8}) at signals.c:97 #7 <signal handler called> #8 0x846cd12 in ssexhd () #9 0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 3221211064, esi = 3221211192, ebp = 3221210964, esp = 3221210092, ebx = 3221210124, edx = 0, ecx = 3221210124, eax = 0, trapno = 14, err = 4, eip = 138857746, cs = 35, __csh = 0, eflags = 2163347, esp_at_signal = 3221210092, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 8}) at signals.c:97 #10 <signal handler called> #11 0x846cd12 in ssexhd () #12 0x4048ed60 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 153736192, esi = 3221213276, ebp = 3221211380, esp = 3221211320, ebx = 3575600, edx = 3221211332, ecx = 1745, eax = 502, trapno = 14, err = 6, eip = 145158780, cs = 35, __csh = 0, eflags = 2163219, esp_at_signal = 3221211320, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 2147483648, cr2 = 1745}) at signals.c:97 #13 <signal handler called> #14 0x8a6f27c in sskgmstat () Workaround ~~~~~~~~~~ (for RedHat 7.0) Install the following packages: compat-egcs-6.2-1.1.2.9 compat-glibc-6.2-2.1.3.2 and modify all occurrences of CC and LINK definitions in all env_*.mk makefiles in the $ORACLE_HOME software tree from either $(LDCCOM) or gcc to i386-glibc21-linux-gcc. To better illustrate the needed changes, the lines such as CC=cc LINK=$(LDCCOM) LINK=$(PURECMDS) gcc $(LDFLAGS) $(COMPOBJS) will become CC=i386-glibc21-linux-gcc LINK=i386-glibc21-linux-gcc LINK=$(PURECMDS) i386-glibc21-linux-gcc $(LDFLAGS) $(COMPOBJS) You will also need to modify the genclntsh shell script and substitute LD="ld -shared -L${ORACLE_HOME}/lib" LD_RUNTIME="-R${ORACLE_HOME}/lib" LD_OPT="-h ${CLNT_LIB}" with LD="i386-glibc21-linux-gcc -shared -L${ORACLE_HOME}/lib" LD_RUNTIME="-Wl,-R${ORACLE_HOME}/lib" LD_OPT="-Wl,-h${CLNT_LIB}" Finally, rebuild libclntsh.so by running 'genclntsh' and relink oracle, svrmgrl etc. using the usual relink commands. You'll get warnings in the relink process but they can be ignored. This has been tested on env_rdbms.mk, env_sqlplus.mk, env_network.mk but should be working on the other makefiles as well. Other possible workarounds: --------------------------- - downgrade to RedHat 6.2 - get a copy of the oracle kernel and utilities such as svrmgrl, imp, exp etc. from a RedHat 6.2 box and place them in $ORACLE_HOME/bin - if you haven't relinked multiple times, it's enough to copy back the old binary versions in $ORACLE_HOME/bin (such as oracleO, impO etc.) to oracle, imp etc. Note that the two latter workarounds will not allow you to relink the Oracle kernel and/or utilities - the resulting binaries will not run under a glibc-2.1.9x system. Patches ~~~~~~~ n/a References ~~~~~~~~~~ n/a ______________________________________________________________________________ Oracle Support Services .
I would love to try the downgrade to RH6.2 workaround. However, I would need to get a *supported* version of RH6.2 (since I just purchased RH 7.0 and wasn't doing an upgrade). How can I get a copy to implement the workaround (downloading for 27 hours isn't my idea to a great way to get a copy and any download I have found is for *unsupported* RH 6.2). Do I have any options?
I have tried the above fix for Red hat 7.0 and get the following errors when running genclntsh. i386-glibc21-linux-gcc: /usr/oracle/product/8.1.7/lib/clntsh.map: No such file or directory i386-glibc21-linux-gcc: libclntsh.so.8.0: No such file or directory genclntst: error: could not locate /usr/oracle/product/8.1.7/lib/clntsh.map please generate the client shared library first I am using the following egcs version package compat-egcs-c++-6.2-1.1.2.9 is already installed package compat-glibc-6.2-2.1.3.2 is already installed
*** Bug 22740 has been marked as a duplicate of this bug. ***
To avoid that error make sure the map option is passed correctly. I used: LD_OPT="-Wl,-Map=${MAPFILE} -Wl,-h${CLNT_LIB}"
I performed the above-mentioned Valinux fix successfully. I cannot say with any certainty that ORacle is stable for production, however. I use it only for light duty development purposes right now. There were some gotchas though: 1) After the failed install, and performing the steps recommended in the Valinux posting at the bug entry, I was only able to get through the installation successfully by 'upgrading' RH7. Even though my workstation was a new install, the process of trying to get Oracle on, putting on GLIB patches, performing the Valinux fix, etc. lef the system confused. A phony upgrade restored its pristine state. Simply run install off the CD or source area, and select upgrade instead of install. It fixes all that was wrong. Reboot. 2)I then ruthlessly whacked all the Oracle install stuff except for the empty ORACLE_BASE and ORACLE_HOME directory trees. I left my oracle user and group configurations alone. I did double check directory permissions. 3) Then, I redid the Valinux fix on the 'pristine' system. 4) Install then concluded fine. 5) DBASSIST still misbehaved creating my 2nd instance after install. I opted for it to make a script instead of trying to auto-build the instance. The script ran fine. 6) I was perturbed to note that several Oracle scripts misbehaved, particularly /etc/init.d/dbora as well as $ORACLE_HOME/bin/dbstart and $ORACLE_HOME/bin/dbstop. I was unable to get dbora to spawn dbstart or dbstop in the background during init or shutdown. I gave up and let them run foreground. Probably my problem. Also, dbstart had to be hacked to look for the right product signature. It looks for this to figure out what version of Oracle it is trying to start up. As installed, it expected 'PL/SQL' to come back but that string never appears during ORacle startup for me. I changed it to look for 'Oracle8i Enterprise' and all was well then with dbstart. YMMV. Any guidance on this is welcome. 7) DBASSIST seems to puke silently if it can't find the target instance build directory it wants, for example, u03/oradata/... That was vaguely annoying. HTH Allen Marshall
This bug has been around since 2000-10-05. Red Hat's inability to provide a solution by now indicates a lack of commitment to the database community. Oracle is a core enterprise-level product that should have been thoroughly tested before RH7.0 was shipped.
Has this bug been fixed in Red Hat 7.1, or shall I invest in a competing product?
DippyChippy, Whilst I agree that the non-attempt to resolve this problem is a disgrace and dissapointing. Check out technet.oracle.com for the latest version of Oracle 8i. There are additional glib stubs. Although I haven't tried it myself it sounds like it should resolve the problem. Junky
We cannot fix this bug, since the bug is in Oracle. But we have provided a workaround for this, see 7.1 RELEASE-NOTES.