In-Place Patching Oracle Grid Infrastructure 19.3.0 to 19.32.0 on RHEL8.10 Before Installation

By Chakravarthy
October 3, 2026 8 Min Read

Can an Oracle Grid Infrastructure 19.3.0 home be patched to 19.32.0 before completing the Grid Infrastructure installation?

I tested this approach on Microsoft Azure using RHEL8.10.

The idea 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.

This differs from the more familiar sequence of installing and configuring Grid Infrastructure 19.3.0 first and applying the Release Update afterward.

For this test, I reversed that sequence.

I first patched the 19.3.0 Grid home to 19.32.0, validated the operating-system prerequisites with the Cluster Verification Utility (CVU), and then completed the Grid Infrastructure installation.

The test also exposed several environment-specific prerequisites involving sudo, NTP/chrony.conf, and NOZEROCONF, making the validation phase an important part of the exercise.

Environment

I have tested this approach across multiple environments:

Article content

The core approach remains the same:

19.3.0 Grid Home
    ↓
Update OPatch
    ↓Apply 19.32.0 RU
    ↓Validate prerequisites
    ↓Complete Grid Installation
    ↓Verify Patch Inventory

However, the OS-level prerequisites and configuration requirements can vary between environments, so each platform should be validated independently.

I will be publishing separate implementation details for the additional environments rather than combining every OS-specific difference into this article.

Note: We will set the environmental variable before running the setup

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 8.10 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. What I Learned from This Test
  12. Final Result
1. Set the Oracle Installer Compatibility Variable

Before starting the installation, I used:

export CV_ASSUME_DISTID=OEL8

This allows the installer compatibility checks to proceed appropriately for this environment.

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 RU 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

The result:

OPatch Version: 12.2.0.1.52

This is an easy step to overlook, but it is important when working with newer RUs.

3. Download and Extract the 19.32 GI RU

For this test I used:

GI RU: 39467003
GI RELEASE UPDATE 19.32.0.0.0

Patch archive:

p39467003_190000_Linux-x86-64.zip

Extract the patch:

cd /u01/app/oracle/software

unzip -q p39467003_190000_Linux-x86-64.zip

The extracted patch 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 step in this approach.

Instead of completing the Grid installation first, I used gridSetup.sh directly against the existing 19.3.0 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.

However, immediately afterward, the installer 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 important distinction is that the patch application completed successfully, while the Grid setup process subsequently continued into installation mode and complained because an installation option had not been provided.

This is one of the useful lessons from the test: don’t automatically interpret the final installer error as proof that the RU was not applied. Verify the patch operation and inventory separately.

5. Run CVU Prerequisite Validation

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

This exposed several environment-specific prerequisites that needed attention.

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

CVU exposed several operating-system prerequisites that needed attention before the installation could continue.

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

The verification command initially reported:

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

I created a symbolic link:

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

This resolved the sudo path requirement.

6.3 NTP Validation

The NTP verification reported:

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

Network Time Protocol (NTP) ...FAILED
caoradb02: PRVG-1017 : NTP configuration file "/etc/chrony.conf" is                                                         present on nodes "caoradb02" on which NTP daemon or service was not running

For this test environment, I moved the configuration file:

mv /etc/chrony.conf /etc/chrony.conf.old

After the environment changes, CVU later reported:

Network Time Protocol (NTP) ...PASSED

This was one of the notable RHEL 8.10-specific observations from this test.

Important note

Because moving chrony.conf was specific to this lab/test environment, I would keep the wording as:

For this test environment, I moved the file.

I would not present this as a universal production recommendation.

That keeps the article faithful to what you actually tested.

6.4 Configure NOZEROCONF

The zero-configuration network check reported:

zeroconf check ...FAILED
caoradb02: PRVE-10077 : NOZEROCONF parameter was not  specified or was not set to 'yes' in file "/etc/sysconfig/network" on node "caoradb02"

I added:

NOZEROCONF=yes

to:

/etc/sysconfig/network
CVU Validation After the Fixes

The validation included:

 ASMLib installation and configuration verification. ...PASSED
  Network Time Protocol (NTP) ...PASSED
  Same core file name pattern ...PASSED
  ..........................................
  Daemon "proxyt" not configured and running ...PASSED
  User Equivalence ...PASSED
  RPM Package Manager database ...PASSED
  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 final verification showed the major checks passing, including memory, swap, filesystem checks, user and group configuration, network connectivity, NTP, ASM, and zero-configuration checks.

7. Complete the Grid Infrastructure Installation

Once the environment passed the prerequisite checks, I continued with the Grid installation using the response file:

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

The installer completed successfully and requested execution of the standard root scripts:

Launching Oracle Grid Infrastructure Setup Wizard...

The response file for this session can be found at:
 /u01/app/19.3.0/grid/install/response/grid_2026-08-14_06-06-45AM.rsp

You can find the log of this install session at:
 /tmp/GridSetupActions2026-08-14_06-06-45AM/gridSetupActions2026-08-14_06-06-45AM.log

As a root user, execute the following script(s):
        1. /u01/app/oraInventory/orainstRoot.sh
        2. /u01/app/19.3.0/grid/root.sh

Execute /u01/app/19.3.0/grid/root.sh on the following nodes:

Execute /u01/app/19.3.0/grid/root.sh on the following nodes:
[caoradb02]

Successfully Setup Software.
As install user, execute the following command to complete the configuration.

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

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.

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 message was:

Launching Oracle Grid Infrastructure Setup Wizard...

You can find the logs of this session at:
/u01/app/oraInventory/logs/GridSetupActions2026-08-14_06-15-48AM

You can find the log of this install session at:
 /u01/app/oraInventory/logs/UpdateNodeList2026-08-14_06-15-48AM.log

Successfully Configured Software.
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)
Check lsinventory
/u01/app/19.3.0/grid/OPatch/opatch lsinventory | grep -i applied

Output:

Patch  39526364     : applied on Fri Aug 14 05:58:26 UTC 2026
Patch  39503034     : applied on Fri Aug 14 05:58:11 UTC 2026
Patch  39472050     : applied on Fri Aug 14 05:54:29 UTC 2026
Patch  39107855     : applied on Fri Aug 14 05:53:43 UTC 2026
Patch  39107825     : applied on Fri Aug 14 05:53:35 UTC 2026

Both opatch lspatches and opatch lsinventory confirmed that the 19.32.0 patches were present in the Grid home.

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 Fri Aug 14 06:31:27 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. What I Learned from This Test

The biggest takeaway is not simply that “the patch worked.”

It is that there is a useful distinction between:

Patching the Oracle Home and Completing the Grid Infrastructure Installation/Configuration.

In this test the RU could be successfully applied to the 19.3.0 Grid home before the installation was completed.

The subsequent 

INS-40426

message did not mean that the RU itself had failed.

That distinction is important when troubleshooting this approach.

Another important lesson was to treat CVU prerequisite validation as part of the installation process, rather than as an afterthought. In this environment, CVU exposed several OS-level configuration issues that had to be addressed before installation could continue.

Traditional Sequence vs Tested Sequence

Traditional:

Article content


Tested approach:

Article content
12. Final Result

The Oracle Grid Infrastructure 19.3.0 → 19.32.0 in-place patching approach was successfully tested on Azure RHEL8.10.

The important result was that the 19.32.0 Release Update could be applied to the Grid home before completing Grid Infrastructure installation.

The test also demonstrated why patching and installation should be viewed as separate operations.

The sequence:

gridSetup.sh -applyRU

successfully patched the Oracle home, even though the installer subsequently reported:

INS-40426

when it continued into installation mode without an installation option.

The patch inventory later confirmed that the expected 19.32 components were present.

For me, the most useful part of the exercise was not just getting from 19.3.0 to 19.32.0. It was understanding what happens when the RU is applied before Grid installation is completed, and how to distinguish an installer message from an actual patching failure.

Production Considerations

I would not describe this approach as a universal recommendation for production environments.

An in-place approach modifies the existing Oracle home and, depending on the deployment, may require additional downtime, rollback, and recovery planning.

My objective in this test was to document a fresh-installation scenario where there were no running databases when the Grid home was patched.

For production environments, the patching strategy should still be evaluated against the organization’s maintenance, rollback, downtime, and recovery requirements.

Related Article

RHEL 7.9 Implementation

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

That makes the two articles useful companions rather than duplicates.

The overall patching sequence is essentially the same, but the CVU prerequisite behavior differs between RHEL8.10 and RHEL7.9.

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.