Unable to PXE Boot to Fog Menu.
-
@Technolust Here is our wiki article on how to test TFTP https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP
Could please upload that PCAP file that you looked at in wireshark or at least take a screenshot of the Bad Request you saw there? If you fear there is too much information in the whole file you can filter in wireshark using display filter
bootp || tftpand then only save/export those to a new PCAP you can share with us to check. -
Hey Sebastian,
Thank you for the response, I have attached the filtered Wireshark capture. Let me know if you need more information.
Also note, that I was able to tftp the file down from a different pc.
tftp -v 10.141.0.20 -m binary -c get undionly.kpxe
mode set to octet
Connected to 10.141.0.20 (10.141.0.20), port 69
getting from 10.141.0.20:undionly.kpxe to undionly.kpxe [octet]
Received 97003 bytes in 1.1 seconds [693957 bit/s]-Technolust
-
@Technolust In that PCAP I see a proper DHCP handshake with PXE information looking fine as well. But there is not TFTP packets in the PCAP so I can’t say what’s going wrong with TFTP. Make sure you upload a PCAP that has the TFTP packets in it.
-
Oh man, I completely forgot to add the tftp my bad on that, guess that would help.
Take a look at the attached tftp.pcapSorry about that,
Joe
-
@Technolust I don’t see “Bad Request” in that PCAP as you posted but it states the normal “Read Request”…
Don’t you have more packets in the original PCAP file? I am missing the answer from the server in there. But the two subsequent TFTP packets from the client make me think that there is a server responding in between. Maybe I am wrong but to me it looks like it.
I still don’t see any issue here. Can you please be more specific to what makes you think is an issue?? Take a picture of the screen on your client or whatever you think looks like an error. I can’t see it yet!
-
This post is deleted! -
Sorry for the delay man Sebastian, take a look at this unfiltered pcap and let me know what you find.
Thanks,
Technolust
-
@Technolust Ok, this time I actually see DHCP PXE packets and TFTP packets. Looking all good from my point of view. I still don’t see the issue, soryy!
Can you please explain why or where exactly you see the issue? In the topic heading it reads as if the client does not show the FOG menu. But what exactly happens on screen. Please take a picture or video or explain more in detail? Does it hang? Black screen or text on screen? Which text? Does it simply reboot? etc…
-
@Technolust Ah, I see something…
The target computer is saying that its an EFI system (BC [type 7]), but your dhcp server is telling it to load undionly.kpxe. You should see some type of error on the target computer with NBF in the title. Basically you are sending a bios boot kernel to a uefi based system. Also make sure you have secure boot disabled on the target computer.
Fix the boot file name, the rest looks perfect.
-
@george1421 You are great! I did not pay as much attention to see this…
-
Thank you George,
Can you tell me which file to use? Secure boot is disabled. I setup based off of the Fog Wiki page which says to use the undionly.kpxe for all versions 0.33 to current. Under the DHCP Settings section on the wiki page.
https://wiki.fogproject.org/wiki/index.php/FOGUserGuide#Installing_FOG
Here is what my tftpboot file contains
10secdelay intel.kkpxe ipxe.kkpxe ipxe.usb menu.c32 realtek.kpxe undionly.kpxe
boot.txt intel.kpxe ipxe.kpxe ldlinux.c32 pxelinux.0.old realtek.pxe undionly.pxe
default.ipxe intel.pxe ipxe.krn libcom32.c32 pxelinux.cfg snp.efi vesamenu.c32
i386-efi ipxe.efi ipxe.lkrn libutil.c32 realtek.efi snponly.efi
intel.efi ipxe.iso ipxe.pxe memdisk realtek.kkpxe undionly.kkpxeThanks,
Joe
-
@Technolust Before I answer you, please answer this: What dhcp server are you using (manufacturer and version)?
-
-
@Technolust Without sounding snarky, it will help you more than it will help me.
Follow this guide for configuring your dhcp server to dynamically support both bios and uefi systems that are pxe booting. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy
By following those instructions your dhcp server will hand out the right boot file name based the type of computer it is.But to answer your original question the boot file for uefi 64 bit is ipxe.efi. The correct boot file for bios based systems is undionly.kpxe typically.
-
Thank you George,
I created the policy and removed the options. However, is it possible to have two policies in place for x64 UEFI and x64 BIOS? This did allow me to access the Fog Server Menu from PXE boot.
Joe
-
@Technolust Umm, there is only one iPXE boot kernel for bios (undionly.kpxe) the kernel is 32 bits so it will run on both 32 and 64 bit systems. UEFI is the unique one where there is a kernel for 32 bits (/i386/ipxe.efi) and 64 bits (/ipxe.efi). Understand there are 2 64 bit type systems arch code 0007 and arch code 0009 that you need to create a rule for. Arch type 0006 is for 32 uefi and Arch 0 is for bios.
Just for reference:
Type Architecture Name ---- ----------------- 0 Intel x86PC 1 NEC/PC98 2 EFI Itanium 3 DEC Alpha 4 Arc x86 5 Intel Lean Client 6 EFI IA32 7 EFI BC (EFI Byte Code) 8 EFI Xscale 9 EFI x86-64 -
Thanks George,
I think my question was vague. I created vendor classes for 00000, 00006, 00007, & 00009. I meant to ask should I apply the 00000, 00007? The only policy I created was the 00007 policy. I do not foresee us using any 32bit OS’s but I do see us using Legacy Bios. My guess would be to just apply all four of them but wasn’t sure if it made a difference.
-
@Technolust I would set the default dhcp options to undionly.kpxe to cover all bios machines, then create a filter for arch 0007 and 0009 that will cover all of the common uefi systems. We have seen some tablets that are 64 bit processors but pinned to 32 bits and report as 32 bits during pxe booting. If you don’t plan on any 32 bit processors then don’t add the filter. Just be aware of some of the tablets if you ever get one.
-
Perfect!! Thank you George and Sebastian for your help and hopefully this helps others in the future.
-Joe
