UEFI PXE boot

[tesparza]

@george1421 No DHCP server is on the same subnet, it is local in that campus. The problem is it always just looks for undionly.kpxe it never attemps to boot from ipxe.efi even though i put the correct vendor and add the policy option 66 and 67

[george1421]

@tesparza I can appreciate that. The way the policies work is that if there isn’t an exact match with the policy the dhcp server will send out the default you have configured for dhcp option 67, which is of course undionly.kpxe. I can tell you for certain that the FOG wiki page about bios/uefi coexistence does work because I have my dhcp server setup exactly the same way as the wiki.

[tesparza]

@george1421 what do you think I’m doing wrong. I’m putting the PXEClient:Arch:00007 exactly because the binary matches the wiki pics. I know it has something to do with my DHCP server. Just don’t know what else to check

[george1421]

@tesparza Well I’m still waiting to see the pcap of the pxe booting process. If nothing else it will tell us where the problem is not. Right now all we know it its not working. The tcpdump results you posted is suspect, since it only captured the tftp part of the pxe boot steps. I’m expecting to see a dhcp discover, offer, request, and ack packets. The details of those packets will give us a clue to what is not working.

[tesparza]

@george1421 okay I will post tomorrow, I not at work right now. Was trying to post but tcpdump wasn’t allowing me, something about being root preventing me from capturing.

[george1421]

@tesparza do you have the centos firewall on? I would think you would have imaging issues if it was enabled.

[tesparza]

@george1421 it’s enabled, but has the exception specified in the wiki guided

[george1421]

@tesparza for the purpose of these testing please stop the centos firewall with systemctl stop firewalld then use tcpdump command. We need to see packets that would normally be dropped by the firewall.

[tesparza]

@george1421 said in UEFI PXE boot:

systemctl stop firewalld
https://drive.google.com/open?id=14zDpA9fW6P6qE4Xs6J5Cpgvw4ZClQUd6

link to the capture

[george1421]

@tesparza Hint: look at the forum chat bubble for additional info

[tesparza]

@george1421 [mod note: linked removed because it contained sensitive data - geo]

[tesparza]

@george1421 https://drive.google.com/file/d/1CqqzV3NZey74vw-CaOhQjEjTcwYN4glK/view?usp=sharing

[tesparza]

@george1421

[george1421]

@tesparza Update: after the OP supplied a clean pcap and reviewing it, we’ve determined that the issue is with the dhcp server. The target computer is behaving exactly as it has been told.

So lets focus back onto your dhcp server can you post a screen shot of your dhcp vendor classes? (Hint: the free application GreenShot or the Windows clipping tool will give us a better resolution picture. I like greenshot because it gives you the tools to annotate the picture.)

Your vendor classes should look like mine.

The xscale entry is not necessary for almost 100% of the installations. Your vendor class fields must match exactly what I have under the description.

[george1421]

@george1421 Then in the policy for the scope in question (could also be a global scope, but make sure you don’t have any local overrides) your polices should be set up similar. Just be aware you will need one policy for each vendor class you setup. Here is an example of one.

On the conditions tab you setup what to match in the packet

Then on the options tab, you need to set dhcp option 67 to the boot file you need. In this case its ipxe.efi.

[tesparza]

@george1421

[george1421]

@tesparza Well OK that one looks perfect. What about the policy now? Will you post images from the tabs I referenced below?

[tesparza]

[george1421]

@tesparza While this is a bit off point, the dhcp 66 options for each policy is a bit redundant since you are not changing the boot server based on each policy, you only need to change the boot file name.

[tesparza]

@george1421