How to apply a patch if rootupgrade.sh / root.sh been executed partially to a GI home
Last updated on OCTOBER 22, 2017
Applies to:Oracle Database - Enterprise Edition - Version 220.127.116.11 and later
During an installation or upgrade of a Grid Infrastructure (GI) home, while executing the root.sh or rootupgrade.sh from the first node, an error could be reported due to a bug and a patch is required.
If the issue is known before executing the root.sh / rootupgrade.sh, can simply apply the patch with 'opatch apply' command to lay down the patch. However, if root.sh or rootupgrade.sh has been partially run and failed, the following steps is required to overcome the issue, especially if the failure already pass the phase that init entries update is done.
Following is an example of upgrading from 18.104.22.168 to 22.214.171.124 GI home, three nodes cluster, namely lc1n1, lc1ntwo and lc1nthree.
This will encounter <Bug 19453778> due to hostname length difference, and need to apply 126.96.36.199.2 GI PSU (Jan 2015), patch number 20132450
BUG 20132450 - COMBO OF OJVM COMPONENT 188.8.131.52.2 DB PSU + GI PSU 184.108.40.206.2 (JAN2015)
This is the error reported during rootupgrade.sh on node1 (lc1n1)
Performing root user operation.
. . . . .
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u02/app/220.127.116.11/grid/crs/install/crsconfig_params
2015/02/12 15:51:22 CLSRSC-4015: Performing install or upgrade action for Oracle Trace File Analyzer (TFA) Collector.
2015/02/12 15:52:32 CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector.
2015/02/12 15:52:43 CLSRSC-464: Starting retrieval of the cluster configuration data
2015/02/12 15:53:08 CLSRSC-465: Retrieval of the cluster configuration data has successfully completed.
2015/02/12 15:53:09 CLSRSC-363: User ignored prerequisites during installation
2015/02/12 15:53:35 CLSRSC-515: Starting OCR manual backup.
2015/02/12 15:53:40 CLSRSC-516: OCR manual backup successful.
2015/02/12 15:53:50 CLSRSC-468: Setting Oracle Clusterware and ASM to rolling migration mode
2015/02/12 15:53:50 CLSRSC-482: Running command: '/u02/app/18.104.22.168/grid/bin/asmca -silent -upgradeNodeASM -nonRolling false -oldCRSHome /u01/app/22.214.171.124/grid -oldCRSVersion 126.96.36.199.0 -nodeNumber 1 -firstNode true -startRolling true'
ASM configuration upgraded in local node successfully.
2015/02/12 15:54:03 CLSRSC-469: Successfully set Oracle Clusterware and ASM to rolling migration mode
2015/02/12 15:54:03 CLSRSC-466: Starting shutdown of the current Oracle Grid Infrastructure stack
2015/02/12 15:54:54 CLSRSC-467: Shutdown of the current Oracle Grid Infrastructure stack has successfully completed.
OLR initialization - successful
2015/02/12 16:00:30 CLSRSC-329: Replacing Clusterware entries in file '/etc/inittab'
CRS-4133: Oracle High Availability Services has been stopped.
CRS-4123: Oracle High Availability Services has been started.
2015/02/12 16:05:59 CLSRSC-115: Start of resource 'ora.ctssd' failed
2015/02/12 16:05:59 CLSRSC-117: Failed to start Oracle Clusterware stack
2015/02/12 16:05:59 CLSRSC-245: Failed to start Cluster Time Synchronization Service (CTSS)
Died at /u02/app/188.8.131.52/grid/crs/install/crsupgrade.pm line 804.
The command '/u02/app/184.108.40.206/grid/perl/bin/perl -I/u02/app/220.127.116.11/grid/perl/lib -I/u02/app/18.104.22.168/grid/crs/install /u02/app/22.214.171.124/grid/crs/install/rootcrs.pl -upgrade' execution failed
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms