Grid Infrastructure patching on Exadata failing at precheck? Three causes to check first

1. ASM compatible.rdbms is set too low (PRVE-03180)

What you see:

PRVE-03180: RDBMS compatibility for ASM disk group "DATA" is set to "11.2.0.4.0", which is less than the minimum supported value "19.0.0.0.0".

Cause (verbatim from Oracle's official error message reference): the ASM disk group attribute compatible.rdbms for the indicated disk group was set to a value less than the minimum supported value.

Why it happens in practice: a GI upgrade requires compatible.rdbms on the ASM disk group to be equal to or higher than the version you're patching to. If the disk group was created long ago and never updated, it stays stuck at the old value.

Diagnosis:

SELECT name, compatibility, database_compatibility
FROM v$asm_diskgroup;

Fix — two equivalent options:

Option A — asmcmd (this is the exact command in Oracle's official Action text for PRVE-03180):

asmcmd setattr -G DATA compatible.rdbms 19.0.0.0.0

Option B — SQL*Plus (connected to the ASM instance as sysasm):

ALTER DISKGROUP DATA SET ATTRIBUTE 'compatible.rdbms' = '19.0.0.0.0';

Both do exactly the same thing — one just goes through asmcmd, the other through SQL. Oracle's own documentation happens to phrase the fix using asmcmd, so that's the one you'll see quoted in the error reference itself, but there's no functional difference.

Important warning: this change is irreversible. Before making it, verify that the COMPATIBLE init parameter of every database on that disk group already meets or exceeds the value you're raising ASM to — otherwise you risk a database becoming incompatible with its own storage disk group. Also note the required order: compatible.asm must always be raised to at least the target value before compatible.rdbms — ASM compatibility can never be lower than RDBMS compatibility on the same disk group.

2. Multiple ASM password files (CLSRSC-00667)

What you see, straight from Oracle's error message reference:

CLSRSC-00667: found multiple ASM password files under '<GRID_HOME>/dbs'

Cause (Oracle's own text): an attempt to execute the root script failed because multiple ASM password files were found in the indicated directory.
Action (Oracle's own text): ensure that there is only one ASM password file in the indicated directory, then rerun the root script.

Note this fires from the root script itself (rootupgrade.sh / rootcrs.pl -upgrade) during a GI upgrade, not from a separate standalone precheck tool — but it's exactly the kind of thing you want to catch before you're mid-upgrade with a failed root script on your hands.

Why it happens: $GRID_HOME/dbs only tolerates a single orapw* file. Oracle doesn't care why there's a second one — it could be a genuine leftover from before the password file was moved into the ASM disk group, or it could be as mundane as a manual backup copy a DBA left behind with a date suffix before doing something else entirely. Either way, the root script sees two files and refuses to guess which one is real.

We've hit this ourselves during a real patching cycle: the registered, active password file was correctly in the ASM disk group (confirmed via srvctl config asm -a), but a stale filesystem copy on just one node (the others were clean) was enough to fail the check.

Diagnosis — check every possible location:

srvctl config asm -a                          # registered location (the one CRS actually uses)
find $GRID_HOME/dbs -name "orapw*"             # filesystem, Grid home — do this on EVERY node
find $ORACLE_HOME/dbs -name "orapw*"           # filesystem, DB home
asmcmd find +DATA / --type f -name "orapw*"    # inside ASM disk groups
asmcmd pwget --asm

Fix (most common case — a leftover or backup file on the filesystem):

cp $GRID_HOME/dbs/orapw+ASM /tmp/orapw+ASM.bak   # backup before deleting
rm $GRID_HOME/dbs/orapw+ASM

Golden rule: always delete/move the file that is NOT registered in srvctl config asm -a, never the other way around — and check every node individually, since the duplicate doesn't have to be present on all of them.

3. A stale home still registered in the central inventory

What you see — either as a blunt install-time error:

[INS-32826] The software home (/u01/app/oracle/product/19.0.0/dbhome_xyz) is already registered
in the central inventory. Refer to patch readme instructions on how to apply.

or buried in a precheck log flagging an old, unrelated home as unreadable.

Why it happens: an old Oracle home — often a pre-upgrade clusterware home, or a DB home nobody cleaned up — stays registered in inventory.xml long after it stopped being used, and gets in the way of a fresh install or patch apply on that path.

Fix — Oracle's documented two-step detachHome procedure (MOS Doc 1346305.1 / KB149122):

export ORACLE_HOME=$OLD_HOME
$OLD_HOME/oui/bin/runInstaller -detachHome -silent ORACLE_HOME=$OLD_HOME

# confirm it's gone from the central inventory
opatch lsinventory -all

If that fails, fall back to the -local per-node variant — this is the exact command we've used in practice, run successfully:

runInstaller -silent -waitforcompletion -detachHome ORACLE_HOME='/path/to/old/home' -local

A quick reference only — there's enough nuance around central-inventory cleanup (stale homes vs. unreadable comps.xml vs. an incorrectly-set CRS=true flag on the wrong home) to warrant its own dedicated post; that's coming separately.

Diagnostic order when precheck fails

Before going deeper, this sequence covers all three scenarios in a couple of minutes:

1. Read the precheck log for the specific error code (PRVE-XXXX, CLSRSC-XXXXX, INS-XXXXX, or text message)
2. Check ASM compatibility: SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup;
3. Check password files on every node: find $GRID_HOME/dbs -name "orapw*"
4. Check whether the flagged home is a stale one: opatch lsinventory -all | grep <home_name>

The takeaway