UEFI PXE boot
-
@tesparza Could you use your FOG server to grab a pcap of these target system pxe booting? https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
You have to remember that there are 4 different flavors of uefi, the target computer tells what it is in its dhcp discovery packet.
The 3 common uefi types are: Arch:0000x
6 EFI IA32
7 EFI BC (EFI Byte Code)
9 EFI x86-64
Your dhcp server needs to be configured for all three to cover all of the bases. -
@george1421 [root@localhost admin]# tcpdump -i enp5s0 port 67 or port 68 or port 69 or port 4011
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:21:59.974458 IP 10.154.18.65.ibm-abtact > localhost.localdomain.tftp: 43 RRQ “undionly.kpxe” octet tsize 0 blksize 1468
17:21:59.977786 IP 10.154.18.65.pra_elmd > localhost.localdomain.tftp: 35 RRQ “undionly.kpxe” octet blksize 1468
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
[root@localhost admin]# -
@george1421
I added added the 3 Arch -
@tesparza It would really help if you use the output file option and then upload the pcap here so we can take a look at it. That tcpdump command should have created more than just 2 packets. A normal dhcp process consists of at least 4 packets and then pxe boot many, many more. For centos you will probably need the -i interface command but the rest from my tutorial should produce an acceptable pcap.
The one thing I didn’t ask was to have the pxe booting client, fog server and dhcp server on the same subnet. Or at the very minimum the fog server and pxe booting client on the same subnet to capture what we really need to see. That will show us what the client is saying about itself and what the dhcp server is telling it.
-
@tesparza for arch 6, you need to have
i386/ipxe.efifor the boot file. -
@tesparza Do you have a single DHCP server in your network? We have seen occasions where a pair of DHCP server not synced properly are causing a PXE boot issue.
-
@Sebastian-Roth I’m a school campus, part of a school district. Each school has its own DHCP server. But the computer in my campus can only get IP’s from my DHCP because the IDF in my campus has the IP helper to route to my DHCP server.
-
@tesparza said in UEFI PXE boot:
because the IDF in my campus has the IP helper to route to my DHCP server
So this tells me your pxe booting client is on a different subnet than your dhcp server? Is your fog server on the same subnet as your dhcp server? That pcap will tell us what is going on, especially if there is another actor we don’t know about. If the pxe client is on a different subnet, then take a laptop with wireshark to capture that side of the pxe booting. It won’t give us the same level of detail as from the FOG server, but at least we can see what the pxe client is saying as well as the dhcp server.
-
@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
-
@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.
-
@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
-
@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.
-
@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.
-
@tesparza do you have the centos firewall on? I would think you would have imaging issues if it was enabled.
-
@george1421 it’s enabled, but has the exception specified in the wiki guided
-
@tesparza for the purpose of these testing please stop the centos firewall with
systemctl stop firewalldthen use tcpdump command. We need to see packets that would normally be dropped by the firewall. -
@george1421 said in UEFI PXE boot:
systemctl stop firewalld
https://drive.google.com/open?id=14zDpA9fW6P6qE4Xs6J5Cpgvw4ZClQUd6link to the capture
-
@tesparza Hint: look at the forum chat bubble for additional info
-
@george1421 [mod note: linked removed because it contained sensitive data - geo]
-
