My customer is being advised by TAC to upgrade their CUPS 6.0(5) to V7.0(7) and so we decided to try out upgrade in the lab, which is built on VMware ESX V3.5. My CUPS server was initially 6.0(2) and was upgraded to V6.0(5) in this environment (or so I understand). I did a remote upgrade to the V7.0(7) upgrade kit and the upgrade proceeded and stated it had completed successfully. I then did a UTILS Switch-version, which reported that V7.0(7) was on my inactiver partition, so I said proceed. The gutest CUPS machine restarted but did not return to service, when I checked the console, the server was displaying a "Kernel panic - Not syncing: attempted to kill init", which as I understand Linux is the equivalent to the Windows "Inaccessible boot device".
Unfortunately, now it is in this state I can't fathom out how to restart it in the previous 6.0(5) partition. I tried the recovery disk but that ends up at same point (Kernel panic) and does nothing as far as I can tell. I need to test this upgrade in the lab before trying production and whilst I can rebuild the guest server from clean V6.0(2) I would love to know why this has happened and how to either recover to my previous version of CUPS or how to get this upgrade working :-)
Is there some specific version of Linux environment configuration we should use when building on VMware ?
That's really useful information, if I have to rebuild I shall hopefully be in a better position to retry the upgrade. In the short term is there any way to recover the current system and at least get it back working as V6.0(5), so my lab can continue whilst I am sorting this out ?
Also not sure if I missed something but what is the recovery iso for, and should it help my case ?
I do not know what version we chose when setting up the ESX guest machine but we are currently running V3.5 ESX, would this likely cause the current problem of "kernel panic" following the upgrade or shoudl I be looking for another cause ?
The problem you were seeing was usually caused by power outage.
I don't know if there's any automatic tool to fix it. Usually, I would use a RedHat recovery CD to boot into the shell and edit the GRUB file, so it can boot from the old partition. It's just too long to post the whole process here. I guess you'll have to do some googling.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...