@gwhitfield - another output after reinstall OS and changing DHCP policy:
0_1456859580183_output2.pcap

@gwhitfield - Nope, not it. Correcting image on the disk didn’t change anything. However, at some point recently I stopped being prompted for the IP address and I hope that’s a good thing, I’m pretty sure that happened when I changed the DHCP policies. I remember with some of our older FOG machines we had to correct the chainloading by adding/editing some files. Is this possibly as simple as that ?? I did try all the different exit conditions and they all respond exactly the same way.

Hold horses. I just changed boot order to look at some image details and the VM won’t boot to the HD. I think my test VM got reverted to a BIOS image on a UEFI disk. I’m guessing that’s the explanation for chainloading failure. Reinstalling OS now, should know shortly…

@george1421 - For the time being I decided to simplify and set the Policies to:
1: Arch=00000 (BIOS) - undionly.kpxe (works great)
2. Arch<>00000 (all other) - snponly.efi
I was hoping that this would tell anything not reporting as a BIOS machine to get the same boot file regardless of architecture. Doesn’t seem to have worked.

@Sebastian-Roth said:

Again: Have you ever tried registering this MAC address in the FOG web interface by hand and scheduling an upload task for it? What happens when you PXE boot the client then? Picture or video of an error would be great. Otherwise I can only guess what’s going on.

Yes, the MAC is registered and an image task runs if/when set. It appears that if there’s no task it doesn’t go to the HD as the next option.

@Sebastian-Roth here’s the output. IP 120.135 confirmed
0_1456847693267_output.pcap

@george1421 - The 2008dhcp and 2012 dhcp are all different locations with different subnets and broadcast domain. exported tcpdump (filtered as suggested) from FOG server : 0_1456840985605_GBfogboot.csv
Never used tcpdump or wireshark, will need to bring in a buddy to assist with a wireshark capture if you still want one.
Did I say THANK YOU" for your help?!

@Sebastian-Roth - Current boot menu settings:

I did (and do) have the boot menu hidden but when I un-hide it I do get the menu after entering the FOG IP. Then it fails. I did make sure of the e1000 NIC and snponly.efi settings. This environment has a 2012 Standard server doing DHCP to approx 75 BIOS machines (no proxy). This UEFI VM is only used for testing in preparation for adding UEFI to the mix this Fall. Therefore I have the policies and options set to allow BIOS and UEFI machines to grab their own boot files which works very well for the BIOS machines. Seems like I’m almost there. I have other FOG servers doing the same thing but they’re 2008 boxes and I can’t set policies so I have to leave them alone or face the wrath of a lot of people not being able to boot their BIOS machines.
@george1421 - Having relied HEAVILY on FOG for many years I can say that my perception of FOG is rose colored! Its all just a little bump in the road, probably of my own doing rather than FOG’s.

@Wayne-Workman - I’ll give up on the 7010, they’re just an experiment anyway. I’m currently testing on the ESXi 5.5 VM set to UEFI and E1000 nic, also testing with a Dell E5550 set to UEFI boot first from IPV4 nic and then Boot Manager. They both appear to be doing the same thing when being served the same boot file.

Scope options in DHCP are:
66 - IP of FOG server
67 - whatever file name I’m testing out.

Boot file ipxe.efi - they ask “Please enter tftp server:”
Boot file snponly.efi - they ask “Please enter tftp server:”
Boot file snp.efi - they ask “Please enter tftp server:”
Boot file intel.efi - they ask “Please enter tftp server:”
Boot file realtek.efi - They say “DHCP failed, hit ‘s’ for shell, reboot in 10 seconds”
Boot file undionly.kpxe - E5550 flashes quickly and boots to OS, VM looks like below (I don’t have an UEFI disk in the system, just wanted to see the network boot okay.)

@Wayne-Workman said:

@gwhitfield It’s missing kernel parameters.

I upgraded to trunk and no change. I was hoping the kernel parameters issue would be resolved automagically since I never intentionally made any changes to anything except putting different efi boot file names in DHCP. I looked and can tell there’s tons of info on kernel parameters and editing the boot menu but isn’t there a default setup that should be in place with a re-install? Do I need to edit something now?

@Wayne-Workman said:

https://www.youtube.com/embed/iWo14lBhXWc

Oh sht that’s funny!!!
#1- I gotta see that movie again. It feels like 20 years since…
#2 - I apologize. I know just enough to be dangerous and under the circumstances sometimes it’s hard to know what’s relevant to the discussion much less what’s important.

@Wayne-Workman - Ahhh…they appeared similar enough in the netboot phase that I got the impression it was the same technology. I been duped.

When you MDT boot you can use either cdrom or usb flash drive. This process doesn’t use iPXE so I would expect this to work.

I’m fairly certain I PXE booted the 7010 UEFI using WDS to deploy the MDT image. Only reason I’m uncertain at all is simply how many different imaging related projects I have going on… I will be able to test/confirm later today or tomorrow.

@Wayne-Workman -only saw the first one, enjoyed it immensely for no good reason.

What version of FOG are you using now? Did you upgrade to trunk as suggested?

Ubuntu 14.04.4, FOG 1.2.0, rev 6365. I didn’t update yet but plan to as soon as I can today. I neglected to mention that I did have a positive UEFI boot and was able to upload from and re-deploy a test image to a Dell E5550 a few days ago using snponly.efi so I thought maybe I’ve just changed something accidentally since then that would be simple to identify.

@Wayne-Workman said:

@gwhitfield It’s missing kernel parameters.

Sorry to appear dense, but I don’t know what the output SHOULD look like, nor what to do to get it that way. I’m handicapped by a lack of in-depth knowledge on how it works. I apologize if I have missed a how-to I suppose?

Another thought I had was that we also use MDT for creating images that can be put on a boot flash. I have no problem with booting the 7010 UEFI using the MDT boot files. I was able to deploy a .wim file yesterday with no issues. I’m inexperienced with the process and the files but I’m wondering if there isn’t a boot file that we can pull from the MDT process and add it to the FOG repository?

I checked the VM was set to E1000 and EFI booting. When I enter the URL I get the following:

#!ipxe
set fog-ip 192.168.1.53
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x1b
iseq ${platform} efi && set keyName ESC || set keyName Escape
prompt --key ${key} --timeout 3000 Booting… (Press ${keyName} to access the menu) && goto menuAccess || chain -ar ${boot-url}/service/ipxe/grub.exe --config-file=“rootnoverify (hd0);chainloader +1”
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://192.168.1.53/fog/service/ipxe/boot.php##params

Thank you all for helping out. Sorry I couldn’t get back to reply earlier than this!

Seems this should be easy but not finding the answer yet. FOG 1.2, Ubuntu 14.04.4, revision 6365. Attempting my first UEFI booting and getting “Chainloading failed…” message and a boot loop. Test clients are a VM (ESXi 5.5) and a Dell 7010 with most current BIOS. The Dell actually just hangs ans “iPXE initializing devices”. I have tried intel.efi, ipxe.efi, snp.efi, snponly.efi in my Win2008 DHCP server. Legacy booting works fine. Am I missing an edit to a file or something? Thanks for the assist!

I struggled with this for a few hours today only to find out that the bootfile options on my DHCP server (WIN2008) had been set in both the Server Options [U][I][B]AND[/B][/I][/U] in the Scope Options fields. I have never needed to specify Scope Options so I didn’t even look in there, but once I did I saw they were the old settings. Once I removed the Scope Options settings (simply to reduce the duplication), everything worked as expected.