Hi David

Thanks for the response.

Just to clarify - Do you mean only have 1 file in the directory where your SFTP server points to, so when you run the upgrade via Call Manager OS  Administration web page, it only finds one file. Or do you mean ensure that only one file exists in the CUCM repository on the call manager where the uploaded file is copied to?

If it is the later, where are these files located?

Many thanks

The first...make sure only one file exists in the SFTP server directory that you point CUCM to for upgrade files via the OS administration page.  Again, can't give you a great explanation as to why but when I've issues like this in the past I found that only having 1 file available to download via SFTP clears up the issue.

No guarantees but it's worth a shot.

Hailey

Hi

I tried a new upgrade with only one file in the SFTP directory. Again the upgrade failed around 30mins into the upgrade.

I have captured the install log and it seems to error each time at the same point...

06/04/2010 10:11:33 CCMInstall|Internal Error, File:instMain.c:1416, Function: handlePhase(), Failed to exec command: "/partB/usr/local/bin/base_scripts/env.sh nice -n 19 /usr/sbin/chroot /partB /usr/local/cm/script/7.1.3.32900-4/cm-dbl-install L2 PostInstall 7.1.3.32900-4 7.1.2.10000-16 /usr/local/cm/ /partB/usr/local/cm/ /common/log/install/capture.txt"|<:CRITICAL>

Any ideas.

Thanks

Hi Andrew

This indicates a problem loading your data from your existing version to the new version.

The DB logs are helpfully spread accross several locations. Best way to pull them is to run RTMT, and do a collect files twice:

1) Files from the publisher, for the 'Install and Upgrade Logs' and 'DB Logs' - do this for the time period covering the upgrade attempt, and specify the 'active' partition.

2) Repeat that for the same set of logs from the 'Inactive' partition.

One of the files from this second set of logs will be called 'something-or-other.err' - it contains any errors encountered when running the data transfer. This   should clue you in to where the problem is, or at least what times to be looking at in the other logs. Normally the useful stuff is in this inactive partition log set...

Regards

Aaron

Please rate helpful posts..

Hi Aaron

I have found the installdb_12.log.err and it contains the following error....

06/04/2010 10:05:54.946 installdb|*ERROR* Error executing "Insert into TypeLicenseUnit ( Enum, Name, Moniker, Units, tkLicenseFeature, adjunctUnits )  values (496, 'iD808_64_Lines', 'LIC_UNIT_PRODUCT_SPEAKERBUS_ID808', 9, 2, -1 )": [Informix][Informix ODBC Driver][Informix]Could not insert new row - duplicate value in a UNIQUE INDEX column. sqlerrm(Unique Index:x_typelicenseunit_moniker)|
06/04/2010 10:05:56.519 installdb|   installFull *ERROR* Prior Cancel or Error Processing installCsv (/usr/local/cm/db/csv/products)|

Now iD808_64_Lines is a .cop file that we have had generated for our own product integration. If i understand this correctly we have a duplicate value in a unique column index in the database.

Question is - how can this be resolved?

Thanks

Hi

Well - I've previously seen issues like this where a recording solution vendor had been on a 5.x system, and added a group called 'Standard Call Recording' or something. When we did an upgrade to 6.x, which introduces a group called 'Standard Call Recording'... well, it was very unhappy. Renamed the group we had on 5.x, and the upgrade went OK.

In your case, I'm guessing that the unique key being violoated is the 496 value - if Cisco have added a new row to this table, it may be using that ID. The other unique field in this table is the 'moniker' field, but as I've never heard of your custom device I'm guessing that is unique.

You may see earlier in the other DB install logs from the inactive partition that a row is inserted to that table with this ID; not sure if that level of detail will be shown, but I think it is. Try searching the files for the 496 value.

I would suggest that you look at changing that; however it's likely that as this is a 'type' table you will have other devices in the DB that refer to this value directly - e.g. other tables will have a column named tklicenseunit, which will refer to this table. You'll need to search the db definition for your version of CCM to find what those tables are, and update those as well.

A quick scan of the docs suggests these will include:

typelicenseunit

licenseinfo

licensedistributionused

I guess you have developers on board, so you may want to back this off to them.

Regards

Aaron

Please rate helpful posts and mark answered questions that you've got a satisfactory response from to help identify useful content in the forums...
https://supportforums.cisco.com/docs/DOC-6212