EBS 12.2 Rapid Clone dbTechStack Fails with RC-50013 — INS-08101 supportedOSCheck on Oracle Linux 8

Alhamdulillah, sharing another real troubleshooting session — this one from an EBS 12.2 database tier clone on Oracle Linux 8.10, where adcfgclone.pl dbTechStack failed and the on-screen error pointed in completely the wrong direction.

Environment

Oracle EBS 12.2, Oracle Database 19c (19.21) multitenant (CDB/PDB), Oracle Linux 8.10, target server testserver01.

The Symptom

perl adcfgclone.pl dbTechStack /u01/EBSDB/19.0.0/appsutil/EBSDB_testserver01.xml

RC-00110: Fatal: Error occurred while relinking of ApplyDBTechStack
ERROR while running Apply...
ERROR: Failed to execute /u01/EBSDB/19.0.0/appsutil/clone/bin/adclone.pl

The first instinct with RC-00110 is to suspect a relink problem — missing OS packages, a corrupt backup, bad extraction. We verified all of that and ruled it out. The real lesson of this post: the RC error on screen is generic. Follow the log chain.

The Log Chain

Step 1 — The ApplyDBTechStack log showed the relink script actually passed:

adlnkoh.sh completed sucessfully

but home registration failed:

Finished OUI CLI cloning for s_db_oh with return code: 1
ouicli.pl  INSTE8_APPLY  1
RC-50013: Fatal: Instantiate driver did not complete successfully.

Step 2 — ohclone.log pointed one level deeper:

OUI runinstaller log file - /u01/EBSDB/oraInventory/logs/InstallActions<timestamp>/installActions<timestamp>.log
Found the INFO: Exit Status is -1 in runInstaller log.
OUI CLI cloning returned non-zero.

Note the timing: runInstaller started and exited within the same second. An installer that dies instantly is not failing a task — it is failing a pre-check.

Step 3 — The installActions log had the true error:

[WARNING] [INS-08101] Unexpected error while executing the action at state: 'supportedOSCheck'
SUMMARY: - java.lang.NullPointerException

Root Cause

The 19c ORACLE_HOME delivered inside the EBS Rapid Clone stage carries the 19.3 base installer (year 2019). Its OS certification table ends at Oracle Linux 7. On OL8/RHEL8, the lookup for the distribution ID returns null and the installer crashes with a NullPointerException before doing any work — surfacing back up the chain as RC-50013 and RC-00110.

The Fix

Set CV_ASSUME_DISTID in the same shell session before rerunning the clone:

export CV_ASSUME_DISTID=OEL7.8
echo $CV_ASSUME_DISTID
cd /u01/EBSDB/19.0.0/appsutil/clone/bin
perl adcfgclone.pl dbTechStack /u01/EBSDB/19.0.0/appsutil/EBSDB_testserver01.xml

Result — the rerun completed cleanly, confirmed by these lines in the new ApplyDBTechStack log:

Finished OUI CLI cloning for s_db_oh with return code: 0
Completed home registration for s_db_oh
Completed Apply...
ApplyDBTechStack Completed Successfully.

Important: this variable does NOT change your OS or the installed software. It only tells the old installer which certification profile to use for its checks. The value must be one the 19.3-base installer recognizes — OEL7.8 is the value documented in Oracle’s Linux 8 release notes. Setting it to your actual OS version (8.10) defeats the purpose.

Permanent Fix

The workaround can also live inside the ORACLE_HOME, in $ORACLE_HOME/cv/admin/cvu_config:

# Fallback to this distribution id
CV_ASSUME_DISTID=OEL7.8      <-- uncomment and set

This also explains a common confusion: “my previous clone worked without this!” If the earlier backup was taken from a home where cvu_config already had this set, the fix travelled inside the backup. A backup from an untouched home reintroduces the failure. Check with:

grep -i CV_ASSUME_DISTID $ORACLE_HOME/cv/admin/cvu_config

Post-Clone Notes

After the fix, you will still see FATAL errors like “DB Connection failed” and “Invalid APPS database user credentials” from the AutoConfig phase, plus DB-ETCC connectivity warnings — these are expected at this stage because the database is not restored and opened yet. They resolve once you restore the database and rerun AutoConfig and ETCC.

Also refresh ETCC from patch 17537119 — the bundled bugfix XML goes stale after 30 days, and older versions do not recognize newer Release Updates such as 19.21.

Key Takeaways

RC-00110/RC-50013 are wrappers, not root causes — always walk ApplyDBTechStack log → ohclone.log → installActions log. A runInstaller that exits in under a second failed a pre-check, not the work itself. And on OL8/RHEL8 with any 19.3-base home, CV_ASSUME_DISTID=OEL7.8 belongs in your clone runbook.

---

Disclaimer: The views expressed on this blog are my own and do not reflect the views of my employer or any client. All environment names, hostnames, and identifiers used in this post are anonymized. Always test in a non-production environment before applying any change to production.