Close Menu
Oracle RAC

OPATCHAUTO-72083 — Bootstrap Operations Failed When Patching Grid Infrastructure

HenriqueBy 5 Mins Read

This post is also available in: Português (Portuguese (Brazil))

When running opatchauto to apply a Release Update to Grid Infrastructure, the process may fail immediately with:

OPATCHAUTO-72083: Performing bootstrap operations failed.
OPATCHAUTO-72083: The bootstrap execution failed because null.
OPATCHAUTO-72083: Fix the reported problem and re-run opatchauto.
  In case of standalone SIDB installation and Grid is not installed
  re-run with -sidb option.

opatchauto bootstrapping failed with error code 255.

The error occurs before any patch is applied — opatchauto fails during the initialization (bootstrap) phase, where it identifies the environment, homes, and installation type. The “failed because null” message is frustrating because it doesn’t state the cause — but the clue is in the accompanying messages.

In this article, I’ll explain the most common causes of OPATCHAUTO-72083, how to diagnose which one applies to your scenario, and how to fix it.

💡 In practice: I encountered this error while applying RU 19.26 to Grid 19.25. The root cause was the CRS="true" attribute in inventory.xml pointing to an old Grid Home (19.0.0.0) instead of the active home (19.25). The opatchauto couldn’t identify the Grid installation and failed at bootstrap.

What the opatchauto Bootstrap Does

Before applying any patch, opatchauto runs a bootstrap phase that:

  1. Reads the inventory.xml to identify installed Oracle Homes
  2. Looks for which home has the CRS="true" attribute — that’s the active Grid Home
  3. Verifies the installation type (RAC, Standalone HA, SIDB)
  4. Validates permissions, space, and prerequisites
  5. Only then starts applying the patch

If any of these steps fail, the bootstrap aborts with OPATCHAUTO-72083.

Common Causes and How to Diagnose

OPATCHAUTO-72083 is an umbrella error — the actual cause varies. Pay attention to the messages accompanying the error to identify which scenario applies.

Cause 1: CRS=”true” Attribute on the Wrong Home (Most Common)

This was the cause in my environment. The inventory.xml had CRS="true" on an old Grid Home that was no longer the active one.

Clue in the error:

In case of standalone SIDB installation and Grid is not installed
re-run with -sidb option.

This indicates that opatchauto did not find an active Grid Home.

Diagnosis:

grep -i 'CRS=' /u01/app/oraInventory/ContentsXML/inventory.xml

Problematic result:

<HOME NAME="OraGI19Home1" LOC="/u01/app/19.0.0.0/grid" TYPE="O" IDX="1" CRS="true"/>
<HOME NAME="Orasiha19c_home1_6835" LOC="/u01/app/19.25.0.0/grid" TYPE="O" IDX="13"/>

CRS="true" is on the 19.0.0.0 home (old), but the active Grid is 19.25.0.0.

Fix:

$GRID_HOME/oui/bin/runInstaller -updateNodeList \
  ORACLE_HOME=/u01/app/19.25.0.0/grid CRS=true

$GRID_HOME/oui/bin/runInstaller -updateNodeList \
  ORACLE_HOME=/u01/app/19.0.0.0/grid CRS=false

Validate:

grep -i 'CRS=' /u01/app/oraInventory/ContentsXML/inventory.xml

CRS="true" should be only on the active home.

Cause 2: Outdated OPatch

opatchauto depends on OPatch to function. If the OPatch version is too old for the RU you’re applying, bootstrap fails.

Diagnosis:

$GRID_HOME/OPatch/opatch version

Fix:

mv $GRID_HOME/OPatch $GRID_HOME/OPatch.bkp

unzip p6880880_190000_Linux-x86-64.zip -d $GRID_HOME/

$GRID_HOME/OPatch/opatch version

Cause 3: /etc/oracle/olr.loc Pointing to Wrong Home

The /etc/oracle/olr.loc file indicates where the OLR (Oracle Local Registry) is located. If it points to an old Grid Home, opatchauto can’t find the active Grid.

Diagnosis:

cat /etc/oracle/olr.loc

Expected result:

olrconfig_loc=/u01/app/19.25.0.0/grid/cdata/hostname.olr
crs_home=/u01/app/19.25.0.0/grid

If crs_home points to an old home, update it manually.

Cause 4: Incorrect Permissions

opatchauto must be run as root. Additionally, the Grid Home owner and inventory permissions must be correct.

Diagnosis:

ls -la /u01/app/19.25.0.0/ | grep grid

ls -la /u01/app/oraInventory/ContentsXML/inventory.xml

whoami

Cause 5: Insufficient Space in /tmp

opatchauto uses /tmp for bootstrap operations. If the filesystem is full, it fails silently.

Diagnosis:

df -h /tmp

If usage is above 90%, free up space before retrying.

Cause 6: Multiple Grid Installations in the Inventory

Environments that went through multiple upgrades may have several Grid Homes in the inventory — including removed homes (REMOVED="T"). In rare cases, this confuses the bootstrap.

Diagnosis:

grep -i "grid" /u01/app/oraInventory/ContentsXML/inventory.xml

If there are many Grid homes (active and removed), consider cleaning the inventory by removing old entries that are no longer needed.

Understanding the inventory.xml

For those unfamiliar, the inventory.xml is the file that registers all Oracle Homes installed on the server. It’s located at:

cat /etc/oraInst.loc

Important attributes in inventory.xml:

AttributeMeaning
LOCOracle Home path
CRS="true"Identifies the active Grid Home — opatchauto uses this attribute
REMOVED="T"Home that was deinstalled (ignored by opatchauto)
IDXSequential installation index

Fundamental rule: Only one home should have CRS="true" — the current active Grid Home.

Quick Diagnostic Checklist

grep -i 'CRS=' /u01/app/oraInventory/ContentsXML/inventory.xml

$GRID_HOME/OPatch/opatch version

cat /etc/oracle/olr.loc

whoami

df -h /tmp

ls -la $(dirname $GRID_HOME) | grep grid

Conclusion

The OPATCHAUTO-72083 error is an umbrella error covering multiple possible causes during the opatchauto bootstrap phase. The “failed because null” message doesn’t help, but the accompanying messages point in the right direction.

Diagnosis follows this order of likelihood:

  1. CRS="true" on the wrong home — check inventory.xml (most common cause)
  2. Outdated OPatch — update to the latest version
  3. olr.loc pointing to old home — check /etc/oracle/olr.loc
  4. Permissions — run as root, verify home ownership
  5. Space in /tmp — free up if needed
  6. Cluttered inventory — clean up old Grid homes

The most important takeaway: read the messages accompanying the error. OPATCHAUTO-72083 alone says nothing — the cause is in the details.

References:

Share.

Related Posts

Add A Comment
Leave A Reply