Friday, July 31, 2026

Fixing Oracle EBS 12.2 Clone Failure on RHEL8 — The refhost.xml Workaround

Fixing Oracle EBS 12.2 Clone Failure on RHEL8 — The refhost.xml Workaround

Fixing Oracle EBS 12.2 Clone Failure on RHEL8 — The refhost.xml Workaround

By Punit Kumar | Oracle EBS DBA | July 2026

Background

While performing an Oracle E-Business Suite 12.2 appsTier clone from Production to UAT, I encountered a series of prerequisite check failures. The target server was running Red Hat Enterprise Linux 8.10 (RHEL8). The EBS environment had AD and TXK at Delta 17. What seemed like a straightforward clone turned into a deep dive into Oracle's FMW prerequisite certification framework.

This article documents exactly what happened, why it happened, and how I fixed it — so you don't have to spend hours figuring it out yourself.

The Environment

  • Oracle E-Business Suite 12.2
  • AD and TXK Delta 17
  • Source: Production (RHEL8)
  • Target: UAT (RHEL8)
  • Clone type: appsTier

First Error — Log File Handler Failure

The first thing I noticed in the install log was this:


OiiolLogger.addFileHandler: Error while adding file handler
java.io.FileNotFoundException: .../clone/FMW/logs/prereqcheck.log 
(Not a directory)

The Oracle Universal Installer was trying to create timestamped log files inside a path called prereqcheck.log, expecting it to be a directory. However, a previous failed clone attempt had left prereqcheck.log as a flat file. The fix was straightforward — rename the file and remove it so the next run could manage it correctly.


rm -rf /u01/applruat/fs2/EBSapps/comn/clone/FMW/logs/prereqcheck.log

Important note here — do not recreate it as a directory either. A different Java class called FMWOracleHomePreReqCheck expects to create prereqcheck.log as a file itself. If you create it as a directory, that process will fail with AC-00002. The safest approach is to simply remove it and let the clone process manage it.

Second Error — oraInventory Logs Directory Missing


ODL-52008: unable to create log directory: /u01/applruat/oraInventory/logs

The Oracle Diagnostic Logging framework could not initialize because the logs directory under oraInventory did not exist. This caused all prereq checks to show "Not executed" rather than actually running.


mkdir -p /u01/applruat/oraInventory/logs
chown -R applruat:oinstall /u01/applruat/oraInventory
chmod -R 755 /u01/applruat/oraInventory

Third Error — oraInst.loc Wrong Parameter

While checking the Oracle inventory configuration I found:


inventory_loc=/u01/applruat/oraInventory
inst_loc=dba

The parameter name inst_loc is invalid. The correct parameter is inst_group and the value should match the group that owns the oraInventory directory. I confirmed this using:


ls -ld /u01/applruat/oraInventory
id applruat

The directory was owned by oinstall group so the fix was:


cat > /etc/oraInst.loc << EOF
inventory_loc=/u01/applruat/oraInventory
inst_group=oinstall
EOF

This same wrong parameter was found on multiple environments including Production, which had been running with this misconfiguration silently for a long time.

The Main Problem — refhost.xml Missing RHEL8 Entry

After fixing the above issues the prereq checks started actually executing. The CertifiedVersions check now ran but failed with the OS not being recognized. The root cause was in this file:


$COMMON_TOP/clone/prereq/webtier/Scripts/prereq/linux64/refhost.xml

This XML file is Oracle's certification registry. It tells the OUI and FMW prereq framework which operating system versions are certified for installation. When I opened the file I found entries for RHEL4, RHEL5, RHEL6, RHEL7 — but nothing for RHEL8.

The file had a last modified date of November 2024, meaning it had not been updated despite the servers being on RHEL8.

Why Did This Happen

This is an important question. The servers had been upgraded from RHEL7 to RHEL8 at the OS level. However the EBS filesystem under /u01/applruat was completely untouched during the OS upgrade. The refhost.xml file is not part of the OS — it is part of the EBS software stack and was originally installed when the appsTier was first laid down on RHEL7.

AD and TXK Delta 17 was applied but this delta did not deliver an updated refhost.xml with RHEL8 certification for the FMW webtier prereq framework. RHEL8 certification for EBS 12.2 FMW components came via specific supplemental patches rather than the main AD-TXK delta rollup.

The result was that Production had been running on RHEL8 for an extended period in a technically uncertified state from the FMW prereq perspective. Nobody noticed because the running EBS system is not affected by this file at runtime — it only matters during clone, patch, and install operations.

The Fix — Adding RHEL8 to refhost.xml

The workaround is to manually add an RHEL8 certified OS block to refhost.xml by copying the existing RHEL7 redhat block and changing the version number.

First back up the original:


cp /u01/applruat/fs2/EBSapps/comn/clone/prereq/webtier/Scripts/prereq/linux64/refhost.xml \
   /u01/applruat/fs2/EBSapps/comn/clone/prereq/webtier/Scripts/prereq/linux64/refhost.xml.bak_$(date +%Y%m%d)

Then open the file and locate the CERTIFIED_SYSTEMS opening tag. Insert the following block immediately after it:


<!-- RHEL8 entry added as workaround - copied from RHEL7 block -->
<OPERATING_SYSTEM>
    <VERSION VALUE="8"/>
    <ARCHITECTURE VALUE="x86_64"/>
    <NAME VALUE="Linux"/>
    <VENDOR VALUE="redhat"/>
    <GLIBC ATLEAST="2.17">
    </GLIBC>
  <PACKAGES>
        <PACKAGE NAME="binutils" VERSION="2.23.52.0.1" />
        <PACKAGE NAME="libgcc" VERSION="4.8.2" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="libstdc++" VERSION="4.8.2" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="libstdc++-devel" VERSION="4.8.2" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="sysstat" VERSION="10.1.5" />
        <PACKAGE NAME="gcc" VERSION="4.8.2" />
        <PACKAGE NAME="gcc-c++" VERSION="4.8.2" />
        <PACKAGE NAME="ksh" VERSION="..." />
        <PACKAGE NAME="make" VERSION="3.82" />
        <PACKAGE NAME="glibc" VERSION="2.17" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="glibc-devel" VERSION="2.17" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="libaio" VERSION="0.3.109" ARCHITECTURE="x86_64"/>
        <PACKAGE NAME="libaio-devel" VERSION="0.3.109" ARCHITECTURE="x86_64"/>
  </PACKAGES>
  <KERNEL>
        <PROPERTY NAME="VERSION" VALUE="3.10.0"/>
        <PROPERTY NAME="hardnofiles" VALUE="4096"/>
        <PROPERTY NAME="softnofiles" VALUE="4096"/>
  </KERNEL>
</OPERATING_SYSTEM>
<!-- End of RHEL8 workaround entry -->

Why compat-libcap1 and compat-libstdc++-33 Were Excluded

When the prereq Packages check ran after adding the RHEL8 block (initially copied with all RHEL7 packages), two packages failed:


Checking for compat-libcap1-1.10; Not found.       Failed
Checking for compat-libstdc++-33-3.2.3; Not found. Failed

Both of these packages were dropped in RHEL8. They were legacy GCC 3.x compatibility libraries from the RHEL5 and RHEL6 era that Oracle never removed from the RHEL7 package list in refhost.xml. They are not required for EBS 12.2 FMW WebTier to function on RHEL8.

The fix was to simply not include them in the RHEL8 block. All 13 remaining packages passed cleanly as RHEL8 ships with newer versions of all of them, and the version check is a minimum baseline comparison not an exact match.

Do You Need to Change Package Version Numbers

No. The prereq check compares installed package versions against the minimum baseline defined in refhost.xml. Since RHEL8 ships with newer versions of all required packages, they will all satisfy the minimum version requirements defined in the RHEL7-era values. For example:

  • refhost.xml requires glibc 2.17 — RHEL8 has glibc 2.28, which passes
  • refhost.xml requires gcc 4.8.2 — RHEL8 has gcc 8.5.0, which passes
  • refhost.xml requires make 3.82 — RHEL8 has make 4.2.1, which passes

Apply the Same Fix to All refhost.xml Locations

There are multiple refhost.xml files in an EBS 12.2 appsTier filesystem. The pasteBinary.sh process used by the clone framework has its own independent prereq check that reads from a different location. Find all of them and apply the same fix:


find /u01/applruat/fs2 -name "refhost.xml" 2>/dev/null

Apply the RHEL8 block to each location found. If pasteBinary continues to fail on prereqs despite the refhost.xml fix, Oracle provides a built-in bypass flag:


pasteBinary.sh ... -executeSysPrereqs false

The Bigger Picture — Production Was Also Affected

After fixing UAT I checked Production and found the same issue. The Production refhost.xml also had no RHEL8 entry, and the oraInst.loc had the same wrong parameter on Production as well. Production had been running on RHEL8 with a technically uncertified FMW prereq configuration since the OS upgrade.

This is a systemic issue that affects any EBS 12.2 environment where:

  • The appsTier was originally installed on RHEL6 or RHEL7
  • The OS was subsequently upgraded to RHEL8
  • No specific Oracle patch was applied to update the FMW prereq certification files

Permanent Fix Recommendation

The manual workaround works but needs to be maintained. For a permanent fix:

  • Check MOS Note 2500278.1 for running EBS 12.2 on RHEL8
  • Check MOS Note 1369010.1 for EBS 12.2 certified platforms
  • Raise an Oracle SR requesting the specific patch that delivers RHEL8 certification in refhost.xml for your FMW version
  • Keep a backed-up copy of your patched refhost.xml outside the EBS filesystem since AD-TXK patches can overwrite it silently
  • Add a step in your clone runbook to verify RHEL8 block is present after each AD-TXK patch application

Clone Runbook Checklist for RHEL8 Environments

Before every appsTier clone on RHEL8, verify:


1. prereqcheck.log does not exist under clone/FMW/logs/
2. oraInventory/logs directory exists with correct ownership
3. oraInst.loc has inst_group=oinstall (not inst_loc)
4. refhost.xml has RHEL8 block without compat-libcap1 and compat-libstdc++-33
5. All refhost.xml locations are patched (use find command)
6. Filesystem has sufficient free space
7. Running as correct OS application user

Conclusion

What started as a clone failure turned out to be a combination of stale certification metadata, leftover files from previous failed attempts, and a misconfigured inventory pointer — all stemming from the same root cause: the EBS software stack was never formally updated to recognize RHEL8 after the OS upgrade.

The fix itself is simple once you understand what refhost.xml does and why it matters. The broader lesson is that OS upgrades on EBS servers need to be accompanied by a review of the FMW prereq certification files and Oracle inventory configuration — not just the OS packages and kernel parameters.

Oracle EBS DBA | Exadata Specialist | AWS & AI Learner

Feel free to connect or comment if you faced the same issue.

Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)