[Apr-23-2014 07:47:35] >>>>Installing preliminary components .. [Apr-23-2014 07:47:51] >>>>Installing component Core Infrastructure Components Verifying dependencies Verifying crypto DB: SUCCESS Verify "/var/opt/oracle/tnsnames.ora" exists: SUCCESS Verify hostname "spin" is resolvable: SUCCESS Verify user "spin" can connect to database "truth.truth": SUCCESS Successfully performed "verify_pre" operation on Opsware SAS components. WARNING: an error was detected while running an external command or script. The output follows:
[INFO] Log started.
[ERROR] 'Data Access Engine' not available at '10.132.104.251:1004'.
It almost looks like you're lacking verbose information..
I can't tell you for sure if the following is applicable, but I had this scenario...
We were patching from 10.01 to 10.10. We thought we had removed all hotfixes and CORD patches to return us to 10.0, however, the installer runs a pre-check; and if it finds you have existing patches, it will attempt to roll them back for you.
In our environment, when it did this, it would stop the Opsware-Sas services, perform some rollback steps and restart the services.
We would see and error in regards to "permission denied' when it attempted to create the Twist PID file.
The results was that Twist was actually running, but without the PID file, the Opsware-Sas stop command wouldn't actually terminate it. So, you'd have to identify the PID yourself and kill it.
I did this by running "/etc/init.d/opsware-sas stop" Then, I'd run "ps -ef | grep /opt/opsware" and parse the output for the pid. (you can change the parameters to not use the extended process information. This will reduce the needless info on your screen).
kill the identified PIDs
What was happening, was that after the rollback script stopped the Opsware processes, during its steps, the /var/opt/opsware/twist directory would get its permissions changed from twist:users to root:root. As a result, the Opswares-sas startup could not write the .pid file to that directory, and thus the startup would fail, and so too our upgrade.
What I had to do was, stop and kill twist processes as listed above
fix the permissions with the command "chown twist:users /var/opt/opsware/twist" Start all opsware-sas services "/etc/init.d/opsware-sas start"
Start my HPSA 10.10 upgrade.
When it got to the part where it stopped the services, on another terminal window to the box, I repeatidly executed "ls -al /var/opt/opsware/twist" until I noticed the change of permissions for the parent directory file "." to root:root. I then immediately ran the chwon command mentioned above to fix the permissions before the rollback script got to starting the twist service up.
With all that done, the services restarted properly, and the HPSA installer knew that the rollback had completed successfully and continued on with the upgrade.