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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: