Chainloading failed / boot looping

[gwhitfield]

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

[Sebastian Roth]

@gwhitfield Your DHCP server is actually offering different information depending on the request being sent by the client. The first DHCP DORA (discovery, offer, request, ack) sequence issues by the VMs PXE ROM comes with all the PXE info (next-server/option 66: 192.168.120.19 and filename/option 67: snponly.efi) included. Seams fine. Then the iPXE binary is loaded via TFTP and sends its DHCP discovery request. The request looks a bit different from the first one (that’s normal for iPXE!) as is provides option 175 and some other things.
Hmmmmmmmm here I noticed something that might cause the issue. In the first request the client sends vendor class identifier “PXEClient:Arch:00007:UNDI:003016” but the iPXE binary sends “PXEClient:Arch:00009:UNDI:003010”. See the difference in arch. I guess you setup vendor classes to match ID 7 only? Those classes are still a mystery to me. Some UEFI firmwares send 7 others 9 and iPXE might do 7 or 9 as well. I guess that it somehow changed when you updated to the latest iPXE binaries.
So back to what happens next: The answer from your DHCP server comes without any PXE information whatsoever - most probably caused by the class mismatch just mentioned I hope. This is why iPXE does not find the next-server/tftp server IP by itself.

[Sebastian Roth]

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.

[george1421]

@Sebastian-Roth said:

Hmmmmmmmm here I noticed something that might cause the issue. In the first request the client sends vendor class identifier “PXEClient:Arch:00007:UNDI:003016” but the iPXE binary sends “PXEClient:Arch:00009:UNDI:003010”. See the difference in arch. I guess you setup vendor classes to match ID 7 only? Those classes are still a mystery to me. Some UEFI firmwares send 7 others 9 and iPXE might do 7 or 9 as well. I guess that it somehow changed when you updated to the latest iPXE binaries.

We may need to update the wiki to be sure to include all arch settings. I see it lists this for the Linux dhcp, but not for the windows 2012 setup (step 3). @Wayne-Workman

[Wayne Workman]

@george1421 said:

We may need to update the wiki to be sure to include all arch settings. I see it lists this for the Linux dhcp, but not for the windows 2012 setup (step 3). @Wayne-Workman

The steps are the same for all architecture types - you’d just change the number in step 3 and then maybe give the names something that is specific to the arch you have setup.

That said - I also understand that someone who doesn’t understand it already will be totally lost for how to set it up for additional architectures. So we do need more steps. Maybe even a video.

wiki

Also - in case anyone is wondering what the heck we are talking about, we are talking about this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

[george1421]

@Wayne-Workman said:

That said - I also understand that someone who doesn’t understand it already will be totally lost for how to set it up for additional architectures. So we do need more steps.

Maybe just add some text under step three to rinse wash as repeat for “PXEClient:Arch:00002”, “PXEClient:Arch:00006”, “PXEClient:Arch:00008” and “PXEClient:Arch:00009”. If you don’t read through the linux section, the windows admins would not know these values are also required. (and for full disclosure, I did not create them either. Will do now…)

[gwhitfield]

@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.

[george1421]

@gwhitfield said:

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.

That should be your exit condition. (i.e. sanboot, grub, exit, etc). Some systems have different exit conditions I’m sorry to say.

[gwhitfield]

@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.

[Wayne Workman]

@gwhitfield That won’t work for 32 bit UEFI systems.

[george1421]

@gwhitfield Yeah I agree with wayne, plus I don’t think wild card matches are supported. you have to spell out each one to get a match. No windows cheating here.

[gwhitfield]

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…

[gwhitfield]

@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.

[gwhitfield]

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

[Sebastian Roth]

@gwhitfield Ok, the PCAP file looks good now from my point of view! DHCP setup correct now I reckon! Reading through the whole post again I think the exit type is the only issue you have on your VM really. Booting into a task works fine as you said. @george1421 Which exit type do you use on your ESXi 5.5??

So we can go back to see if you can get things working with you Dell E5550 as well. You know that you can set exit type for each host. So play with those settings! If you cannot make it work on the E5550 you can try other iPXE binaries (and setup you DHCP to hand out the binaries depending on the clients’ MAC address). Probably best to open a complete new discussion on PXE booting E5550 in UEFI mode if you can’t make it work right away.

[gwhitfield]

@Sebastian-Roth
Funny, no matter what I set as my exit type, I see this as HD boot instruction:
“:fog.local
chain -ar ${boot-url}/service/ipxe/grub.exe --config-file=“rootnoverify (hd0);chainloader +1” || goto MENU”

but when I look at Wayne’s upload I see this:
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU

I would expect to see a changed response each time I change exit type.

Edit: Actually, the parameters for boot only change when I change the BIOS exit type, they don’t change when I change the EFI exit type. Maybe I have a corrupt file of some sort?

[gwhitfield]

This works for my VM - not that I understand why nor do I know if it’s a sign something is still wrong with my setup. My OS comes up if no tasks are pending and I am able to upload and deploy an image. Haven’t tried multicasting but I’m going with the assumption for now that it will work fine too. Current boot file is ipxe.efi but have also tested fine on snponly.efi and snp.efi.

I will work on the Dell E5550 laptop tomorrow and let you know what happens. THANK YOU EVERYONE!!! (Edit 3/2/16: E5550 works just fine)

[george1421]

@gwhitfield said:

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.

wiki hint: Under efi booting, if we are getting the ipxe kernel being delivered to the target computer but the ipxe kernel either doesn’t get the next server, boot file, or possibly an IP address we should dig into what architecture is being requested and what the dhcp server’s policy is configured to deliver. @Wayne-Workman

[gwhitfield]

@gwhitfield said:

Maybe no need to re-invent the wheel, there’s a great video here:

Oh, I’m not reinventing anything. I’m documenting for FOG, not WDS.

You also need to keep in mind - all revenue generated for the FOG videos I make will be donated to the fog project. All wiki articles I write generates traffic to the fog site, which in turn generates revenue for FOG. It’s in the best interests of the FOG Project for me to produce documentation specific to FOG.

And no decent Open Source project would rely on documentation written for competing software. I won’t have people relying on a WDS oriented video to do something for FOG.

[george1421]

@gwhitfield ??? Maybe a little context here would help to clarify the last post? Possibly a response to a chat session?