01-08-2018 03:21 PM - last edited on 03-25-2019 08:44 PM by ciscomoderator
After installing new cluster, i get the message below after a reboot.
Probing EDD (edd=off to disable)... ok
Any ideas?
Solved! Go to Solution.
01-16-2018 05:32 AM
Guys, I just received a Notification Alert showing there is a bug report for this issue: CSCvh55176 with title "After reboot Server is not booting back console stuck with "Probing EDD (edd=off to disable)... ok"". Apparently, the issue occurs because of an automatic vmtools installation.
The procedure to restore this issue is as follows:
- Boot the server with the applicable recovery CD. Once the options appear, press ALT+F2. This will take you to bash prompt. - ls -la /mnt/part1 - ls -la /mnt/part2 - Which ever folder has newer files identify that as the active partition - chroot /mnt/part1 or part2 (which ever one is the active partition) - /usr/bin/vmware-config-tools.pl -d - You may ignore the errors at the end - Exit - Disconnect the RecoveryCD - Reboot the VM
I have tested this procedure on my broken VM (I kept it just in case) and it worked indeed! :-)
Regards,
Ruud van Strijp
01-08-2018 08:16 PM
01-09-2018 03:08 AM
I have rebuilt this cluster 4 times now. This is beyond just accepting that as a solution.
I am looking to see if someone might know what is causing this.
01-09-2018 03:42 AM - edited 01-09-2018 03:43 AM
I ran into the same issue after upgrading 11.5 to 12.0 and doing the first reboot after installing a device pack on 12.0. Unfortunately I was only able to 'solve' it by restoring a DRS backup of the 11.5 cluster. When I installed CUCM 12.0 again, it worked well even after another restart. So it feels like a hit or miss thing.
Besides running into this issue on CUCM, I also had the same thing on PCD 12.0 after I changed its disk from 80GB to 200GB (which is possible according to the documentation).
Perhaps it has something to do with the change of RHEL to CentOS?
01-09-2018 07:11 AM
I believe it is related to the change from RHEL to CentOS.
I am probably going to stay away from 12.0 until it is a bit more baked.
01-09-2018 07:07 AM
Do you meet the HW/SW specs for the server you're using?
Are you deploying with the Cisco provided OVA template?
01-09-2018 07:11 AM
yes to both.
01-09-2018 08:06 AM
One thing to try is to remove the vm from esxi, and then re-add it.
Don't delete, just remove.
And when you rebuild, are you deploying a brand new OVA?
01-10-2018 11:58 PM - edited 01-14-2018 11:39 PM
I tried deploying a new CUCM 12 OVA and using the old 'broken' VMDK file in that new VM, but it still wouldn't boot.
When I rebuilt, I used the CUCM 12 OVA to install CUCM 11.5 indeed. However, I only got the error on my Publisher; the subscriber wasn't rebuilt and still used the old CUCM 11.0 OVA.
01-11-2018 04:34 AM
@ruudvanstrijp wrote:
I tried deploying a new CUCM 12 OVA and using the old 'broken' VMDK file in that new VM, but it still wouldn't boot.
When I rebuilded, I used the CUCM 12 OVA to install CUCM 11.5 indeed. However, I only got the error on my Publisher; the subscriber wasn't rebuilt and still used the old CUCM 11.0 OVA.
I believe the issue is related to the change from RHEL to CentOS. I think it might be related to the OVA specifically.
01-11-2018 04:32 AM - edited 01-11-2018 04:33 AM
@seanvaid wrote:
One thing to try is to remove the vm from esxi, and then re-add it.
Don't delete, just remove.
And when you rebuild, are you deploying a brand new OVA?
I had tried this with the same results.
I downloaded a new OVA from CCO each time
01-16-2018 05:32 AM
Guys, I just received a Notification Alert showing there is a bug report for this issue: CSCvh55176 with title "After reboot Server is not booting back console stuck with "Probing EDD (edd=off to disable)... ok"". Apparently, the issue occurs because of an automatic vmtools installation.
The procedure to restore this issue is as follows:
- Boot the server with the applicable recovery CD. Once the options appear, press ALT+F2. This will take you to bash prompt. - ls -la /mnt/part1 - ls -la /mnt/part2 - Which ever folder has newer files identify that as the active partition - chroot /mnt/part1 or part2 (which ever one is the active partition) - /usr/bin/vmware-config-tools.pl -d - You may ignore the errors at the end - Exit - Disconnect the RecoveryCD - Reboot the VM
I have tested this procedure on my broken VM (I kept it just in case) and it worked indeed! :-)
Regards,
Ruud van Strijp
01-16-2018 04:37 PM
thank you Ruud. this is exactly what I was looking for.
06-23-2018 01:02 AM
I had the same exact problem with CUCM version 12.0.1.21900-7 and resolved it with Ciscos suggested way.
Cisco should add the above release to the affected ones in the bug CSCvh55176.
07-13-2018 01:23 AM - edited 07-13-2018 01:26 AM
An update over my previous post: I ran into a situation where somehow the vmware-config-tools.pl file did not exist on the active partition, but only on the inactive one. Here's how I copied it over and still managed to install VMware tools and boot the appropriate active partition. Of course this isn't any Cisco-supported way, but at least it worked for me so I didn't have to boot back to my old inactive partition!
Find all folders containing vmware-tools:
find / -type d -name 'vmware-tools'
Remove every relevant directory on the active partition, if they exist:
rm -r /mnt/part1/etc/vmware-tools
(do this for all other folders as well)
Copy folders from the Inactive partition to the Active:
cp -d -r /mnt/part2/etc/vmware-tools /mnt/part1/etc/
(do this for all other folders as well)
After this I was able to run the vmware-tools-config.pl script on my active partition by following the guide, starting with 'chroot'.
Regards,
Ruud
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide