In-Place Patching Oracle Grid Infrastructure 19.3.0 to 19.32.0 on RHEL 7.9 Before Installation

By Chakravarthy
October 3, 2026 8 Min Read

After testing the Oracle Grid Infrastructure 19.3.0 → 19.32.0 in-place patching approach on RHEL 8.10, I wanted to test the same approach on RHEL 7.9.

The objective was straightforward:

Start with the Oracle Grid Infrastructure 19.3.0 home, apply the 19.32.0 Release Update, and then complete the Grid Infrastructure installation and configuration.

The overall patching and installation process was essentially the same as my RHEL8.10 implementation. However, the interesting differences appeared during the Cluster Verification Utility (CVU) validation.

Some prerequisite issues were common to both operating systems, while others behaved differently on RHEL7.9. In particular, RHEL7.9 reported a /dev/shm validation issue that I did not encounter on RHEL8.10.

There are two possible approaches:

As described in my previous article, there are two possible approaches:

  1. Install Grid Infrastructure 19.3.0 first and then apply the 19.32.0 RU
  2. Apply the 19.32.0 RU to the 19.3.0 Grid home first and then install/configure Grid Infrastructure.

I tested the second approach.

Because this was a fresh installation with no running databases, I used gridSetup.sh to patch the Grid home first and then complete the Grid Infrastructure installation.

Environment
  • Cloud: Microsoft Azure
  • Operating System: RHEL7.9
  • Database: Oracle 19c
  • Grid software: Oracle Grid Infrastructure 19.3.0
  • Target RU: 19.32.0
  • Grid Home:/u01/app/19.3.0/grid
  • Database Home:/u01/app/19.3.0/db

The purpose of this test was not to create a completely different installation procedure.

The main question I wanted to answer was:

Does the same Oracle GI 19.3.0 → 19.32.0 in-place patching approach work on RHEL7.9, and if so, what changes during prerequisite validation?

Quick Navigation
  1. Set the Oracle Installer Compatibility Variable
  2. Update OPatch
  3. Download and Extract the 19.32 GI RU
  4. Patch the 19.3 Grid Home Before Installation
  5. Run CVU Prerequisite Validation
  6. Resolve RHEL 7.9 CVU Issues
  7. Complete the Grid Infrastructure Installation
  8. Run Configuration Tools
  9. Verify the Patched Grid Home
  10. Patch the Database Home to 19.32
  11. RHEL 7.9 vs RHEL 8.10
  12. Final Result and Lessons Learned
1. Set the Oracle Installer Compatibility Variable

Before starting the installation, I used:

export CV_ASSUME_DISTID=OEL7.8

This was also part of the RHEL 8.10 implementation.

2. Update OPatch

The original Oracle Grid Infrastructure 19.3.0 home contained an older OPatch version.

Check the existing version:

/u01/app/19.3.0/grid/OPatch/opatch version

OPatch Version: 12.2.0.1.17

The 19.32.0 patch requires OPatch 12.2.0.1.52 or later, so I backed up the existing OPatch directory and replaced it with the newer version.

cd $GRID_HOME 
mv OPatch OPatch_12.2.0.1.17 

cd /u01/app/oracle/software

unzip -q p6880880_190000_Linux-x86-64.zip -d /u01/app/19.3.0/grid/ 

/u01/app/19.3.0/grid/OPatch/opatch version

After the update:

OPatch Version: 12.2.0.1.52

Updating OPatch before applying the RU is an important prerequisite when working with newer Release Updates.

3. Download and Extract the 19.32 GI RU

For this test, I used the same 19.32.0 GI Release Update:

GI RU: 39467003
GI RELEASE UPDATE 19.32.0.0.0

The patch archive was: 

p39467003_190000_Linux-x86-64.zip

Extract the patch:

cd /u01/app/oracle/software 

unzip -q p39467003_190000_Linux-x86-64.zip

The extracted directory was:

/u01/app/oracle/software/39467003

The same GI RU bundle also contains the Database Release Update that can later be applied separately to the database home.

4. Patch the 19.3 Grid Home Before Installation

This is the key part of the approach.

Instead of completing the Grid Infrastructure 19.3 installation first, I applied the 19.32 RU directly to the existing Grid home.

/u01/app/19.3.0/grid/gridSetup.sh -silent -applyRU /u01/app/oracle/software/39467003

The important part of the output was:

Preparing the home to patch...
Applying the patch /u01/app/oracle/software/39467003...
Successfully applied the patch.
The log can be found at: /tmp/GridSetupActions2026-08-05_06-30-23AM/installerPatchActions_2026-08-05_06-30-23AM.log
Launching Oracle Grid Infrastructure Setup Wizard...

[FATAL] [INS-40426] Grid installation option has not been specified.
   ACTION: Specify the valid installation option.

The installer then continued into the Grid Infrastructure installation phase and reported:

[FATAL] [INS-40426] Grid installation option has not been specified. 

ACTION: Specify the valid installation option.

At first glance, that looks like the patch operation failed.

It did not.

The patch application completed successfully. The subsequent error occurred because gridSetup.sh continued into installation mode without being provided an installation option.

Therefore, do not interpret the final INS-40426 message as proof that the RU application failed.

The important line is:

Successfully applied the patch.

Verify the patch inventory separately before continuing.

5. Run CVU Prerequisite Validation

After applying the RU, I ran the Cluster Verification Utility before completing the Grid installation.

/u01/app/19.3.0/grid/runcluvfy.sh stage -pre crsinst -n caoradb01 -verbose -method sudo -user oracle

This was the point where the RHEL 7.9 test became more interesting.

The Oracle patching procedure itself remained essentially the same as RHEL 8.10, but the operating-system prerequisite validation did not.

6. Resolve RHEL 7.9 CVU Issues
6.1 Add the Oracle User to the Wheel Group
usermod -aG wheel oracle
6.2 Resolve the sudo Path Validation

CVU reported:

PRCZ-2004 : File "/usr/local/bin/sudo" was not found
PRKC-1002 : Not all the submitted commands completed successfully.

The same issue occurred during the RHEL 8.10 test.

I created a symbolic link:

ln -s /usr/bin/sudo /usr/local/bin/sudo

This satisfied the CVU path requirement.

6.3 NTP Validation

One interesting difference between the two operating systems involved NTP.

During my RHEL 8.10 test, CVU reported an NTP-related issue:

Network Time Protocol (NTP) ...FAILED

PRVG-1017 : NTP configuration file "/etc/chrony.conf"
is present on nodes on which NTP daemon or service was not running

I did not receive that error on RHEL 7.9.

The RHEL 7.9 test passed the NTP validation:

chrony daemon is synchronized with at least one external time source ...PASSED

Network Time Protocol (NTP) ...PASSED

This demonstrates why CVU validation should always be performed on the actual target operating system rather than assuming two RHEL releases will behave identically.

6.4 Configure NOZEROCONF

CVU also reported:

zeroconf check ...FAILED

PRVE-10077 :
NOZEROCONF parameter was not specified
or was not set to 'yes' in file
"/etc/sysconfig/network"

I added:

NOZEROCONF=yes

to:

/etc/sysconfig/network

After the change:

zeroconf check ...PASSED

This prerequisite was encountered on both RHEL 7.9 and RHEL 8.10.

6.5 /dev/shm Validation on RHEL 7.9

The RHEL 7.9-specific issue was:

/dev/shm mounted as temporary file system ...FAILED

PRVE-0421

Although /dev/shm was visible at the operating-system level, CVU expected the corresponding configuration in:

/etc/fstab

After the RHEL 7.9 prerequisite issues were addressed, CVU completed successfully.

The final validation included:

Maximum locked memory check ...PASSED

/dev/shm mounted as temporary file system ...PASSED

File system mount options for path /var ...PASSED

DefaultTasksMax parameter ...PASSED

zeroconf check ...PASSED

ASM Filter Driver configuration ...PASSED

ORAchk checks ...INFORMATION (PRVH-1507)

Pre-check for cluster services setup was successful.

The article’s original test identifies the /dev/shm requirement as a RHEL 7.9-specific difference from the RHEL 8.10 run.

Note: I have intentionally not introduced a new /etc/fstab command here because the original article identifies the requirement but does not contain a specific remediation command to copy verbatim.

RHEL7.9 vs RHEL8.10 CVU comparison

Here is the most useful summary from my testing:

Article content

This comparison is probably the most important takeaway from the RHEL 7.9 test.

The Oracle patching procedure remained essentially the same.

The CVU prerequisite validation did not.

7. Complete the Grid Infrastructure Installation

Once the RHEL7.9 prerequisite issues were addressed, I continued with the response-file-based Grid Infrastructure installation.

/u01/app/19.3.0/grid/gridSetup.sh \   
  -ignorePrereq \   
  -silent \   
  -responseFile /u01/app/oracle/software/gridSetup.rsp

The installation completed successfully and requested the standard root scripts:

As a root user, execute the following script(s):

1. /u01/app/oraInventory/orainstRoot.sh
2. /u01/app/19.3.0/grid/root.sh

Run:

/u01/app/oraInventory/orainstRoot.sh

and:

/u01/app/19.3.0/grid/root.sh

The installer then requested execution of the configuration tools.

Successfully Setup Software.

The response-file installation sequence is documented in the original execution output.

8. Run Configuration Tools

Complete the Grid Infrastructure configuration:

/u01/app/19.3.0/grid/gridSetup.sh \   
  -executeConfigTools \   
  -responseFile /u01/app/oracle/software/gridSetup.rsp \   
  -silent

The final output included:

Successfully Configured Software.

At this point the patched Grid Infrastructure home had been installed and configured successfully.

9. Verify the Patched Grid Home

After completing the configuration, verify the installed patches.

Check lspatches
/u01/app/19.3.0/grid/OPatch/opatch lspatches

The Grid home showed the 19.32.0 components, including:

39526364;OCW RELEASE UPDATE 19.32.0.0.0 (39526364)
39503034;ACFS RELEASE UPDATE 19.32.0.0.0 (39503034)
39472050;Database Release Update : 19.32.0.0.260721 (39472050)
39107855;TOMCAT RELEASE UPDATE 19.0.0.0.0 (39107855)
39107825;DBWLM RELEASE UPDATE 19.0.0.0.0 (39107825)

OPatch succeeded.
Check lsinventory
/u01/app/19.3.0/grid/OPatch/opatch lsinventory | grep -i applied

Output:

Patch  39526364     : applied on Sat Aug 15 05:39:27 UTC 2026
Patch  39503034     : applied on Sat Aug 15 05:39:01 UTC 2026
Patch  39472050     : applied on Sat Aug 15 05:37:07 UTC 2026
Patch  39107855     : applied on Sat Aug 15 05:35:19 UTC 2026
Patch  39107825     : applied on Sat Aug 15 05:35:04 UTC 2026

Both opatch lspatches and opatch lsinventory confirmed that the 19.32.0 patches were present in the Grid home. In‑Place Patch_ Upgrading Oracle… In‑Place Patch_ Upgrading Oracle…

10. Patch the Database Home to 19.32

I also applied the corresponding Database RU to the separately installed Oracle Database 19.3.0 home.

Verify the Existing Database Home

Before Patching:

/u01/app/19.3.0/db/OPatch/opatch lspatches
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
29517242;Database Release Update : 19.3.0.0.190416 (29517242)

/u01/app/19.3.0/db/OPatch/opatch lsinventory | grep -i applied
Patch  29585399     : applied on Thu Apr 18 07:21:33 UTC 2019
Patch  29517242     : applied on Thu Apr 18 07:21:17 UTC 2019
Apply the 19.32 Database RU

Navigate to the Database RU directory:

cd /u01/app/oracle/software/39467003/39472050

Apply the patch:

$ORACLE_HOME/OPatch/opatch apply

The patch completed successfully:

Patch 39472050 successfully applied.

Sub-set patch [29517242] has become inactive
due to the application of a super-set patch
[39472050].

OPatch succeeded.

The older 19.3 Database RU became inactive because it had been superseded by the 19.32 Release Update

Verify the Database Home After Patching
/u01/app/19.3.0/db/OPatch/opatch lspatches
39472050;Database Release Update : 19.32.0.0.260721 (39472050)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

/u01/app/19.3.0/db/OPatch/opatch lsinventory | grep -i applied
Patch  39472050     : applied on Sat Aug 15 06:11:33 UTC 2026
Patch  29585399     : applied on Thu Apr 18 07:21:33 UTC 2019

The database home now contained the 19.32 Database RU.

11. RHEL 7.9 vs RHEL 8.10

Here is the most useful summary from my testing:

Article content
What changed between RHEL7.9 and RHEL8.10?

After running the same overall procedure on both versions, the differences became quite clear.

Common to both
#PRCZ-2004
/usr/local/bin/sudo 

#PRVE-10077
NOZEROCONF=yes in /etc/sysconfig/network
RHEL7.9

The additional issue was:

/dev/shm mounted as temporary file system ...FAILED

PRVE-0421

Although /dev/shm was visible in df -h, CVU was looking for the corresponding configuration in /etc/fstab.

RHEL8.10

The additional issue was related to NTP and chrony.conf.

That validation issue was not encountered in my RHEL7.9 test.

12. Final Result and Lessons Learned

The biggest takeaway from this second test was not that the patching process worked again.

The same Oracle Grid Infrastructure 19.3.0 → 19.32.0 in-place patching approach was successfully tested on Azure RHEL7.9.

The overall sequence remained:

Article content

The most important lesson from the RHEL7.9 test was not simply that the patch worked.

It was that:

The same Oracle installation and patching procedure can produce different prerequisite-validation results depending on the operating-system version.

The Oracle software was the same.

The Release Update was the same.

The OPatch update and Grid Infrastructure installation process were essentially the same.

What changed was the environment validation. The /dev/shm check appeared during my RHEL7.9 test, while the NTP/chrony.conf issue encountered on RHEL8.10 did not.

This reinforced the importance of running CVU against the actual target operating system rather than assuming that a prerequisite checklist validated on one RHEL release will behave identically on another.

Same Oracle version. Same RU. Same overall installation approach. Different CVU behavior.

That was the most useful result of this RHEL 7.9 test.

Related Article

Article 1: RHEL8.10 👇

Patching Oracle Grid Infrastructure 19.3.0 to 19.32.0 Before Grid Installation: An In-Place Approach

#Oracle #OracleDatabase #Oracle19c #GridInfrastructure #DBA #OPatch #RHEL #RHEL7.9 #RHEL8.10 #DatabaseAdministration #Patching

Tags:

No Comment! Be the first one.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright 2026 — Forerunner DBA. All rights reserved.