Created attachment 1044008 [details] Installer logs. Description of problem: RHEV+RHCF deployment on physical servers took a very long time (46%), left it running for the weekend, it now shows completed 100%. But both hosts are stuck at with this pce error-> PXE-M0F: exiting intel boot agent. The boot order is local disk first, it also says "Booting from local disk..." before the PXE error. Restarting both nodes doesn't help. Version-Release number of selected component (if applicable): ISO with the Media ID 1434638612.868458 How reproducible: Unsure first attempt to install Steps to Reproduce: 1. Create new deployment RHEV+RHCF 2. NFS storage on RCHI server 3. Deployment got stuck for a long time on 46%. 4. Today I checked it's at 100% completed (green bar). 5. Both hosts don't bootup. Actual results: Both hosts are stuck on same PXE error during boot. Restarting hosts doesn't help they return to same error. Expected results: Hosts should boot up. Additional info: Just started helping out with RHCI, not sure which logs to add other than ones under: var/log/katello-installer I'll try this again see if I get stuck on same problem.
I've deleted my hosts rediscovered them and ran into the same error exactly. This time during second boot (after host OS installed) I'd manually changed boot order to start from disks rather than PXE, deployment resumed and is now almost done. The above bug can be attributed to the fact that on second PXE boot both servers didn't move to second boot device (disk drives). Hosts servers both Dell PowerEdge C6220 RHCI server Dell PowerEdge C6105 Now waiting for this step: Synchronize repository 'Red Hat CloudForms Management Engine 5.3 Files x86_64'; product 'Red Hat CloudForms'; organization 'Default Organization' One more thing on initial bug I've mentioned deployment indicator was green 100%, this is another bug reporting wrong status. As I know for a fact that both host servers were stuck on PXE boot after installing base OS, couldn't have installed anything more than base OS. Meaning there is a problem with the progress indicator, giving false reports.
I've run into this same problem on same servers as below Media ID 1439475247.560921 from Aug 13th if i recall. If any one needs access to servers in real time let me know.
Seems to be in poll loop in Actions::Fusor::Deployment::Rhev::WaitForDataCenter
Jason Montleon learned this is a hardware dependent issue between syslinux and the bios on the Dell PowerEdge c6220 http://www.syslinux.org/wiki/index.php/Hardware_Compatibility#LOCALBOOT A syslinux bz has been filed here to track the request for a fix: Bug 1254615 - Dell PowerEdge c6220 hangs on localboot after being provisioned by Satellite 6.1 > To work around it you can edit the 'PXELinux default local boot' template > change .localboot 0 to: > COM32 chain.c32 > APPEND hd0 If testing this on a Satellite with discovery. Make the edits then put the hosts into a build state and take them out to overwrite their copies of the template.
One note: If you edit 'PXELinux default local boot' after the hosts are provisioned and you hit the problem you're going to need to briefly put them in build and take them out to overwrite the individual host pxe configs or manually copy them in /var/lib/tftpboot/pxelinux.cfg, from default to each of the affected hosts.
FYI Flashing latest BIOS 1.1.19-> 2.5.3 didn't resolve. Still happens (media 1440170112.364470 21 Aug 2015).
Verified as restriction to be documented.
Tzach Shefi, per https://bugzilla.redhat.com/show_bug.cgi?id=1254615 could you retry with the syslinux package from 7.3 beta?
Jason, don't wait for me on this. I'd love to help out, but my hardware has since been replaced from Dell servers to HPs. My current focus as RHOS storage QE means I handle mostly RHOS storage and VMware interrogation testing. RHCI was a side job I was fortunate enough to help with a while back, not actively on going. Ask Roni Rasouli I think he does some RHOS+RHCI/FC testing, might have access to such Dell servers.
Closing with insufficient data. If we can test we can reopen and properly verify. Truth is it is probably fixed, we just can't know.