I recently came accross a new (to me) error when trying to upgrade Grid Infrastructure on my lab, a 2-node 18.6 RAC cluster. To upgrade Grid Infrastructure directly to 19c with the latest Release Update 19.4, I downloaded the 19.3 base release and tried to apply RU 19.4 before launching the upgrade :
# /u01/app/19_4_0_0/grid/gridSetup.sh -silent -applyRU /staging/path/29708769
(Please refer to Doc ID 1410202.1 for the full explanation.)
Unfortunately, I had my head in the clouds (pun intended), and the node on which the patch was running encountered a problem and the session got killed.
During the second attempt of patching, I got the following error :
# /u01/app/19_4_0_0/grid/gridSetup.sh -silent -applyRU /staging/path/29708769
ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.
It’s upsetting but it does not seem too difficult to handle. With Doc ID 2279633.1 validating my intuition, I removed the directory and unzipped the home once again without forgetting to unzip the latest opatch as well :
# cd /u01/app/19_4_0_0/grid
# rm -rf *
# unzip -d /u01/app/19_4_0_0/grid /staging/path/LINUX.X64_193000_grid_home.zip
# unzip -d /u01/app/19_4_0_0/grid /staging/path/p6880880_190000_Linux-x86-64.zip
But things didn’t go exactly as expected when I tried to apply the patch again :
# /u01/app/19_4_0_0/grid/gridSetup.sh -silent -applyRU /staging/path/29708769
[INS-32826] The software home (/u01/app/19_4_0_0/grid) is already registered in the central inventory. Refer to patch readme instructions on how to apply.
So far, neither Google nor My Oracle Support seem to know anything about INS-32826. And there is a line in file inventory.xml of central inventory which looks like a temporary home :
<HOME NAME="tempGIName" LOC="/u01/app/19_4_0_0/grid" TYPE="O" IDX="3"/>
After a few risky attempts, it was time to use a radical yet simple solution : recreate the central inventory. I backed up the content of /u01/app/oraInventory/ before emptying it on both nodes, then launched the following command to recreate it with the current Grid Infrastructure home of the 2 nodes …
# /u01/app/18_6_0_0/grid/oui/bin/runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/18_6_0_0/grid" ORACLE_HOME_NAME="OraGI18Home1" LOCAL_NODE="node1" CLUSTER_NODES="{node1,node2}" CRS=true
… and added the only RDBMS home I have on this lab :
# /u01/app/18_6_0_0/grid/oui/bin/runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/oracle/product/18_3_0_0" ORACLE_HOME_NAME="OraDB18Home1" LOCAL_NODE="node1" CLUSTER_NODES="{node1,node2}"
After that, the patch was applied successfully.
Floo Bar 
I just happened to be upgrading a GI home to 12.2 today, and checked the inventory while I ran gridSetup.sh. Sure enough, when it ran the patch, it had added a tempGIName home to the inventory. As soon as it finished applying the RU, the entry was removed. I guess your session crashed during the patch, and not after!
LikeLike
Hi Andy!
Thank you for checking the inventory during the patch process and confirming this behaviour, I did not have a chance to try again recently. Yes indeed, the node crashed while the patch was ongoing (and this usually takes ages on my lab environment 😉
LikeLike
Hi Florab, nice blog and excellent issues. Btw, I wondered Why you just didnt remove the bad entry from the inventory.xml file ?
LikeLike
Hello,
Very good point. Actually I thought about it, and then I found on My Oracle Support Doc ID 1470313.1 that Oracle strongly recommends against modifying inventory.xml manually, as it can lead to corruptions.
LikeLike
Hi, this has nothing to do with the previous issues, but I like to sharing. During the applied of GI Update OCT2019 (12.2.0.1.191015) 30116802 on my RDBMS home 12.2.0.1. I receive this error from opatchauto apply command:
Reason: Failed during Patching: oracle.opatch.opatchsdk.OPatchException: Re-link fails on target “proc”.
Re-link fails on target “procob”.
I could not find a clear MOS on the issues and following the logs I saw this message
/bin/chmod: cannot access ‘/u01/app/oracle/product/12.2.0/db/db_1/precomp/lib/procob’: No such file or directory
make[1]: *** [/u01/app/oracle/product/12.2.0/db/db_1/precomp/lib/procob] Error 1
make: *** [procob] Error 2
The problem was resolve it just with simple touching those files, that did not exists
touch $ORACLE_HOME/precomp/lib/procob
touch $ORACLE_HOME/precomp/lib/proc
and resuming the patching
# /u01/app/oracle/product/12.2.0/db/db_1/OPatch/opatchauto resume
it works like a charm!!
==Following patches were SUCCESSFULLY applied:
Patch: /u01/medios/30116802/30138470
Log: /u01/app/oracle/product/12.2.0/db/db_1/cfgtoollogs/opatchauto/core/opatch/opatch2019-11-06_11-50-19AM_1.log
OPatchauto session completed at Wed Nov 6 13:43:42 2019
Time taken to complete the session 39 minutes, 12 seconds
LikeLiked by 1 person
Hi,
Thanks for sharing. Someone seems to have experienced the same problem, in the comments under this post by Mike Dietrich : https://mikedietrichde.com/2019/10/17/patching-all-my-environments-with-the-oct-2019-patch-bundles/
In your case, what is the OS ? Did you file an SR regarding this ?
LikeLike
Why not just detach?
export ORACLE_HOME=/u01/app/19.3.0.0/grid
$ORACLE_HOME/oui/bin/runInstaller -detachHome -silent ORACLE_HOME=$ORACLE_HOME
LikeLike
Hello 🙂
Detach was not possible either … but I forgot to copy/paste the error I had at this time 😦
LikeLike
#rm /etc/oraInst.loc
#rm /etc/oratab
luego volver a intentar
LikeLike