Upgrade fail from 6.1.5 to 9.1.2 (Drive to nine)

[armin.wagenfuehr]

Hello Community, Customer bought this upgrade. I follow the the drive to nine guide for this upgrade.

Drive_to_Nine_Jump_upgrade_versions_4.1.3-7.1.5_to_9.1.2[2]

Basic Steps I had done as refer in the guide.

1. Backup on MCS in 6.1.5

2. Install OVA V8 in EXSi 5.0 and fresh Install 6.1.5 lates Version same like at the customer.

3. Install Refresh COP 1.2 and Restore Customer Data. Reboot CUCM. NTP and DNS are accessible.

4. Start upgrade 9.1.2 via sftp. Download and Installation runs well, server restarts byself, start setup routine Install OS and DB (CLI I saw)

Take near 2 hours.

During some Post Installtion scripts ( I saw on CLI) the Setup stops with see attached errormessage and is in loop. When Restart the VM, runs all the time in this state on attachment upgrade_fail2.jpg.

Meantime I follow this bug cscui85967 Workarround and I am back in 6.1.5.

https://tools.cisco.com/bugsearch/bug/CSCty45858

Please any help are appreciate.

Best Regards

Armin

[Aman Soi]

Hi Armin,

As u have already mentioned the BUG and there is a workaround .May be to do this , u would require TAC help.

Alternatively, instead of upgrading from 6 to 9 , u can first upgrade 6 to 7 and then, do JUMP upgrade.

regds,

aman

[armin.wagenfuehr]

Hi, as I mentioned, I am back in "6.1.5" causing by the workarround, but thats not the goal. The workarround describe the Rollback in 6.1.5 by using the shell. When I Rollback the Workarround I am back in the 9.1.2 fault.

Please any help are appreciate.

Cheers Armin

[Rob Huffman]

Hi Armin,

Like Aman nicely noted (+5) there is a "special" Drive to 9 TAC that can help

you resolve this issue

• • Product Design and Implementation Helpdesk•
• TAC with special keyword to navigate you to CUCM upgrade experts
• Co-ordinated Support backed by BU Engineering Escalation
• License SWAT team to handle 100% Migration Cases

    Open case using Service Request Tool, Special Sub-Tech --- > Comunication Manager Upgrade to v9 (Drive-to-9 Initiative)

Failing the TAC case you could download the .iso for 7.1.3 or 7.1.5 and use one of them

as an interim jumping off point for the move to 9.x

Cheers!

Rob

"A smile relieves a heart that grieves" 

- Stones

[armin.wagenfuehr]

Hi Rob, Really Thanks to help me on that. Could you point me on the right way, because I could open only a

Tac Case Type:

Replace my product

Diagnose and Fix my Problem

not more!!!!!

May be Screenshoot or Hyperlink?

Regards

Armin

[Rob Huffman]

Hi Armin,

OK we'll get there

When you are on the first page of opening the the TAC choose

Diagnose & fix my problem> choose the severity level> enter contact info>

press next @ bottom of page> moves to next page>

choose support contract from dropdown via search by other> choose supported product  CUCM>

press next @ bottom of page> moves to next page then you will see this

once you enter the "select product" dropdown box

Then submit the support case to TAC with the details.

You can also open the SR right from this page

https://supportforums.cisco.com/docs/DOC-13613

Cheers!

Rob

"A smile relieves a heart that grieves" 

- Stones

[armin.wagenfuehr]

Hi Rob, Problem is:

Teh Customer have bought Drive to nine License and the  upgrade, but they have no servicecontract. So I could not choose a  Contract and w/o contract I could not go ahead.

How I could open a case?

[Joseph Martini]

Armin,

I've been working in the background on your issue with the previous owners of your TAC case.  I filed the bug you referenced in your original post as I have run into the same problem in the lab while upgrading a customer's system from 6.1(5) to 9.1(2).  To keep this thread up to date, there is a flag that TAC can set prior to the next upgrae attempt which will prevent the system from automatically rebooting upon failure.  This flag also prevents the generic error message screen you saw, and instead reveals a more meaningful error, such as "Missing required NTP referece" or something else.  Hopefully we will find cause now that this parameter has been set.

[armin.wagenfuehr]

Hi Joe, Thanks for answer and help on that. The case is move to EMEA Timezone TAC, because we lost to much time.

When I perform a utils diag all ckecks are "passed". NTP and DNS are reachable!

I understand you could reproduce exactly this fault in your lab? right?

I understand current you test this"flag" in your lab? right?

On my system, the TAC engineer has set a OS based trace and I perform now the upgrade again. After upgrade TAC will grab the trace and will see what was going on during the upgrade!

Should I set this flag also at my System? Could you provide me the steps? Or you will post the result on this thread?

Best Regards

Armin

[Joseph Martini · Accepted solution]

The error messages I saw were exactly the same as you did in your original post, however the causes of our errors seem to be different.  My 6.1(5) server did not have an NTP reference because it was not required in 6.x but it is required in 7.x+.  In my lab I was able to determine the cause using a parameter set before attempting the upgrade again which prevents the system from rebooting when an error occurs so that the logs can be viewed and an error message will be shown on the screen, hopefully with more details than the generic message that an error occurred.

The parameter can only be set by TAC using a remote_support account.  I spoke with Aditya who you are working with earlier today and I believe you two have already set the parameter via the remote_account.  The next steps for you are now to attempt the upgrade once more so we can see the cause this time.

[armin.wagenfuehr]

Hi, yes, Aditya has set a remote accont. We will see!!!!

Really Thanks to work on that and your effort!

Best Regards

Armin

[armin.wagenfuehr]

Hi, my issue is solved, the not supported hardware was the issue The  message you get regarding the filesystem, is a "really common message"  TAC had set a flag for more detail output during upgrade and after  during Upgrade I got a timeout Message during Database Installation.  Takes to long. The Server was to slow. I had Upgrade on a Customer own  Vmware with 2.39GHZ Prozesser. Supported is 2.53GHZ. The upgrade take  Performance!!!!

I know unbelievable, but true!

So I use a UCS  C200M2 and stops all other Vm´s and the upgrade was successful. You get  also this message regarding the filesystem during upgrade, when the NTP  is not reachable. When TAC set this flag during upgrade you see that NTP  ist not reachable. NTP is needed!!!

So, when this Falg ist not set during upgrade you get all the time this commen message regarding upgrade! Very Confusing.

I recommend, use only supported hardware( cisco wiki) make sure DNS and NTP during upgrade are reachabel for the CUCM.

I had never believe that a timeout is the fault, because the CUCM Upgrade take to much Resources. For the next approval Releases, I recommend to introduce in in early Dev, LAB or latest time in Alpha, more detail output during Installation and Upgradeprocess (concerning the error messages) and stops immediality at the fault. It helps the Technican on site and save a lot of time. The message concerning the Filesystem after reboot is to common!