Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Upgrade from CUCM 7.1(2) to 7.1(3) fails

I am trying to upgrade a cluster which consists of a publisher and a subscriber. I am running 7.1.2-10000-16 and want to upgrade to 7.1.3-32900-4.

I have carried out the upgrade on VMware and it worked corectly.

When i use the upgrade file which has been checked for the correct MD5Hash, the file loads and the upgrade starts. After around 30mins the upgrade fails with the following error...



Start Time

Wed Jun 02 14:58:34 BST 2010


Error encountered: An unknown error occurred while accessing the upgrade file

I have tried this several times with different upgrade files and get the same error

The hardware Spec is as follows

HP DL380-G4

3.4Ghz Xeon Processor

4GB Ram

2*72GB Ultra 320 10K hard disks

Has anybody encountered this issue before

Many thanks


Everyone's tags (3)

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails

I have seen similar failures when accessing the 7.1(x) upgrade files via SFTP.  One thing I have tried and had success with is to ensure that the the file you are accessing is in a dedicated folder path with no other upgrade files in it...ask me why this works and I can't tell you but it's certainly worth a try.  So, put the file in a folder such as:


With only the specific 7.1(3) upgrade file in this path, attempt to download the upgrade file again by starting the installation process.


Please rate helpful posts!

Community Member

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails

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

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails

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.


Community Member

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails


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/ nice -n 19 /usr/sbin/chroot /partB /usr/local/cm/script/ L2 PostInstall /usr/local/cm/ /partB/usr/local/cm/ /common/log/install/capture.txt"|<:CRITICAL>

Any ideas.


Super Bronze

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails

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...



Please rate helpful posts..

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Community Member

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails

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?


Super Bronze

Re: Upgrade from CUCM 7.1(2) to 7.1(3) fails


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:




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



Please rate helpful posts and mark answered questions that you've got a satisfactory response from to help identify useful content in the forums...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
CreatePlease to create content