Hi, Thanks for the quick response (glad I moved this to the correct forum!).
The workaround was carried out by TAC, using root access as you say. Following that process when we tried the upgrade again it failed with exactly the same error, which is why I (and the TAC engineer) say that the workaround did not fix the problem. Possibly we're hitting a different defect.
The actual error in the install log comes after all the table copy lines during the switch version, and incidentally none of those lines show any indication of an error. The first indication is this ..
10/09/2018 14:33:06 installdb|--- --- Begin Performing Final Target DB Updates (Step 6 of 6)|<LVL::Info>
10/09/2018 14:33:06 installdb|--- --- End -- Performing DB Load and Transforming Copy
10/09/2018 14:34:20 IPM|Internal Error, File:ipm.c:2011, Function: ipmReadNormalizedInputLine(), "/usr/local/cm/script/cm-dbl-install RU PostInstall 11.5.1.15900-18 9.1.2.12901-3 /usr/local/cm/ /common/component/database /common/log/install/capture.txt " failed (1)|<LVL::Critical>
10/09/2018 14:34:22 IPM| end-of-session "Installing database component": 962.403 secs.|<LVL::Info>
The case is currently still with TAC, there is a suggestion of a work around by deleting all route patterns and route filters that reference the UKNP, then uninstalling the NP before trying the upgrade again, then recreating all the deleted configuration. That's not practical for this particular customer as it would disable all outbound calling for the full duration of the upgrade, for all phones.
Currently I'm building a replica of their cluster in the lab and will try some scenarios, but this all takes time.
Thanks again for chipping in.
