Step 2 of Mammoth Upgrade Fails at "Patch_fimage/Exec[copy_oswbb]"
(Doc ID 2479768.1)
Last updated on APRIL 17, 2023
Applies to:
Big Data Appliance Integrated Software - Version 4.11.0 and laterLinux x86-64
Symptoms
NOTE: In the examples that follow, user details, table name, company name, email, hostnames, etc. represent a fictitious sample (and are used to provide an illustrative example only). Any similarity to actual persons, or entities, living or dead, is purely coincidental and not intended in any manner.
Step 2 of Mammoth upgrade fails with:
************************************
Error [5629]: (//bdanode01.example.com//Stage[main]/Miscsetup::Patch_fimage/Exec[copy_oswbb]/returns) change from notrun to 0 failed: /bin/echo ; mnode=bdanode01.example.com; /usr/bin/scp -o StrictHostKeyChecking=no ${mnode%%.*}:/opt/oracle/BDAMammoth/zipfiles//oswbb* /opt/oracle/bda/zipfiles/ returned 1 instead of one of [0]
************************************
Error [5629]: (//bdanode01.example.com//Stage[main]/Miscsetup::Patch_fimage/Exec[copy_oswbb]/returns) change from notrun to 0 failed: /bin/echo ; mnode=bdanode01.example.com; /usr/bin/scp -o StrictHostKeyChecking=no ${mnode%%.*}:/opt/oracle/BDAMammoth/zipfiles//oswbb* /opt/oracle/bda/zipfiles/ returned 1 instead of one of [0]
************************************
Additional Symptoms look like:
1. The associated log file shows:
<timestamp> bdanode01 puppet-master[5629]: (//bdanode01.example.com//Stage[post]/Miscsetup::Endstep/Notify[end_step]) Dependency Exec[copy_oswbb] has failures: true
<timestamp> bdanode01 puppet-master[5629]: (//bdanode01.example.com//Stage[post]/Miscsetup::Endstep/Notify[end_step]) Skipping because of failed dependencies
<timestamp> bdanode01 puppet-master[5629]: (//bdanode01.example.com//Stage[post]/Miscsetup::Endstep/Notify[end_step]) Skipping because of failed dependencies
2. The file Mammoth fails to copy can be manually copied from Node 1 to the rest of the cluster using the same command Mammoth is using. In other words manually running the following from Node 1 is successful:
3. But if a manual copy of ooswbb* is made from Node 1 to the rest of the cluster, rerunning Mammoth deletes that file and the Mammoth copy fails again.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |