Solved: Re: Problem in upgrading from 7.1.5 to 8.6.2

plillelund · ‎12-14-2012

Hi Guys

I am experiencing a problem en upgrading from 7.1.5 to 8.6.2. Platform is 7825H3 and the system is already running 7.1.5.

Im getting this in the log:

verfied|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb INFO: CSV Files verfied|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb ERROR: Number of headers and datatype and data are not same in tbl_mail_parameters table. So migration will fail.|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb ERROR: exceptions.SystemExit|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb ERROR: Error occured while verifing CSV files|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb ERROR: exceptions.SystemExit|<LVL::Debug>

12/14/2012 17:19:43 component_install|(CAPTURE) Fri Dec 14 17:19:43 2012 exportcardb ERROR: Error occured while getting table names|<LVL::Debug>

12/14/2012 17:19:43 component_install|/common/refresh_upgrade/Cisco/callmanager/scripts/exportcardb.py RU Export 8.6.2.10000-30 7.1.5.33900-10 /common/component/callmanager /usr/local/cm/ /common/log/install/capture.txt failed (1)|<LVL::Error>

12/14/2012 17:19:43 refresh_upgrade|Final exit processing with result 1|<LVL::Info>

12/14/2012 17:19:44 refresh_upgrade|(CAPTURE) Mail notification cancelled - smtp server address for email not found! [/common/cisco/platformConfig.xml]|<LVL::Debug>

12/14/2012 17:19:44 ServerApiManager|In legacy initHardwareLibrary args []|<LVL::Debug>

12/14/2012 17:19:44 refresh_upgrade|Exit processing with result 1|<LVL::Info>

ilesystem /dev/hda|<LVL::Debug>

What is going on here?

Regards

Peter

plillelund · ‎03-19-2013

Hi JK

Yes we got help from TAC, but the answer was pretty simple. As can be seen from the log, we had problems with the CDR database. The process called exportcar database fails, and in a way that prevents upgrade.

The solution is to empty the CAR database, and stop the car process while upgrading.

Resolution Summary:

Followed below steps and the upgrade was successful.

1. As precautionary measure, restart CAR DB service and the loader scheduler service.

2. Please check of any mail ID is configured in mail parameters, if yes, please reset the password. (I actually deleted the parson that had been receiving mails)

3. Make sure that the server name defined is a reachable mail server. If not sure about dns, please use ip address instead of the any hostname.

4. Before making another upgrade attempt, please purge all the CDR tables if possible. In case you need to save this data, we can export the CDR dump which would have all the CDR info in a file.

5. Disable the loader under System -> Scheduler.

6. Go to call manager admin page -> system -> service parameters -> and disable flag for CDR before upgrade. We can re-enable that flag once upgrade is done.

And that actually did the trick - upgrading to 8.6.2 went smooth.

Peter

View solution in original post

Chris Deren · ‎12-14-2012

Did you install ciscocm.refresh_upgrade_v1.1 on the server?

Did you upgrade the server memory to 4 GB?

Chris

plillelund · ‎12-15-2012

Hi Chris

Yes - this server has in fact 6 GB and I did install ciscocm.refresh_upgrade_v1.1 before trying to upgrade to 8.6.2.

In fact I believe that the problem is the CAR database - somehow it is not possible to upgrade this database to 8.6.2 format?

Do you know if it is possible to run a test validation on an existing CAR database before the upgrade to 8.6 is tried once more?

Peter

System Administrators · ‎03-19-2013

We're experiencing the same issue trying to upgrade from 8.0.3 to 8.6.2. We've even tried upgrading 8.0.3 to 8.5.1 (which was successful) and then to 8.6.2 which gives the same error.

Were you ever able to figure out what was causing the issue?

Thanks,

JK

plillelund · ‎03-19-2013

Hi JK

Yes we got help from TAC, but the answer was pretty simple. As can be seen from the log, we had problems with the CDR database. The process called exportcar database fails, and in a way that prevents upgrade.

The solution is to empty the CAR database, and stop the car process while upgrading.

Resolution Summary:

Followed below steps and the upgrade was successful.

1. As precautionary measure, restart CAR DB service and the loader scheduler service.

2. Please check of any mail ID is configured in mail parameters, if yes, please reset the password. (I actually deleted the parson that had been receiving mails)

3. Make sure that the server name defined is a reachable mail server. If not sure about dns, please use ip address instead of the any hostname.

4. Before making another upgrade attempt, please purge all the CDR tables if possible. In case you need to save this data, we can export the CDR dump which would have all the CDR info in a file.

5. Disable the loader under System -> Scheduler.

6. Go to call manager admin page -> system -> service parameters -> and disable flag for CDR before upgrade. We can re-enable that flag once upgrade is done.

And that actually did the trick - upgrading to 8.6.2 went smooth.

Peter

System Administrators · ‎03-19-2013

Thanks for the quick reply, Peter.

Odd, TAC had us do the same thing and the upgrade still failed.

We will keep working with TAC on this. I appreciate your help.

Thanks,

JK