FOG 1.5.2 TFTP OpenTimeout
-
@george1421 Whatever information I can give, just let me know.
-
@jvenus Well I don’t know the answer. The ONLY thing I can see different between one that works and yours is that you are sending dhcp option 28 (broadcast address) to the target computer where normally its not sent.
-
@george1421 I’m going to try to get it working on Ubuntu 20.04 LTS this weekend. I’ll keep an eye on this post as well as let you know if there is any difference in this attempt.
-
@jvenus A different host OS isn’t the issue, its the dhcp server that seems to be the root of the issue. I just can’t find the different.
The discrepancy is between ipxe and your dhcp server. BUT what I might do is try a physical machine instead of VB. We have seem some strangeness in the way VB does things especially in regards to pxe booting. BUT I’m still conflicted, at this point iPXE should be in control of the network and VB not blocking things.
-
@george1421 I have an old machine I can throw linux on. I’ll do that this weekend instead of the Ubuntu VM.
-
@george1421 Interesting find…
I decided to attempt a pxe boot from that spare physical machine to the fogserver VM before installing / configuring FOG server on the physical machine and continuing testing to it instead of the current VM. Attached is the Wireshark output from the Win10 host while booting from a physical machine to the Debian ‘fogserver’ VM. Again, all three are in the same subnet. It seems like it passes all of the information just fine. The physical machine will boot into the FOG menu.
-
@jvenus See this is what I thought sometimes VB can be flaky when PXE booting. This is why I asked to test with a physical machine. From the pcap it appears the pxe booting process is normal. You see one set of dhcp requests for the PXE rom and then a second set for iPXE. If you were to boot into FOS Linux (by picking one of the registration functions) you would have seen a third dhcp sequence.
I remembered there was something we had to do to get around VB’s strangeness. A quick google-fu search of the forums suggest that you use ipxe.kpxe instead of unionly.kpxe with virtual box VMs. undionly.kpxe is a shim driver that uses the network card’s built in undi driver. So its very small and fast. If the built in undi driver in the network card is not behaving well FOG has the ipxe boot loaders that have all of the common network drivers built in. In this case ipxe.kpxe and the (recommended for general use) ipxe.efi for uefi systems. For bios mode you can typically use undionly.kpxe but if that driver doesn’t work then the larger ipxe.kpxe boot loader will work.
https://forums.fogproject.org/topic/10160/virtualbox-pxe-boot-no-configuration-methods-succeeded
-
@george1421 I can’t thank you enough for all of your help. I’ll switch over to the ipxe.kpxe bootfile instead for general use from now on. Should I have any problems, I’ll definitely let you know. But for now, many many thanks.
-
Well, I spoke too soon. To more thoroughly test it, I’m trying it on a newer laptop (Latitude 5510) on the same subnet. After switching the bootfile-name and option 67 to ‘ipxe.kpxe’, it’s not working on the 5510 but it does work on the original old machine (Optiplex 990 MicroTower) that I used last night for testing. There is no displayed error on the 5510 screen. It starts to pxe boot, says it’s “downloading NBP file…” and then goes straight into the Dell Support Assist (where it goes if it doesn’t find a boot device).
In the 5510 BIOS, I’ve got Network UEFI stack w/ PXE boot enabled. I’ve tried it with Secure Boot on/off; UEFI Boot Path Security on/off; POST behaviour set to ‘thorough’ (suggestions from https://www.dell.com/support/article/en-us/sln317555/bios-settings-to-allow-pxe-boot-on-newer-model-dell-latitude-laptops?lang=en). It’s not using a docking station but rather using the on-board NIC so no need for the USB options in that post. Although, they are enabled by default in this BIOS. But looking at the 5510.pcap, I can see it finds the ipxe.kpxe bootfile. The 5510 just doesn’t do anything after that. That makes me think it’s specific to that machine NIC or BIOS, especially since it works on the Opti990. That being the case, I don’t know what my options are given that the majority of my inventory items are newer Dell laptops.
Here are the pcaps.
5510.pcap
original_old.pcap -
Another thread with the same issue but different laptop model - https://forums.fogproject.org/topic/14685/dell-7000-series-laptops-pxe-booting. I reference it because he’s tried the same settings from that Dell KB website and has a video that shows the error.
And, of course, you already know this b/c you replied to the poster. Forgive my lack of sleep.
-
@jvenus Lets be clear ipxe.kpxe is only for fixing the booting issues with virtual box. In general use (physical machines) use undionly.kpxe for bios and ipxe.efi for uefi systems. Understand these two files are only used to get into the FOG iPXE menu (period). Also understand that these boot loaders are firmware specific. You CAN NOT boot a uefi based system with undionly.kpxe, conversely you can not boot a bios system with ipxe.efi. If you have both types of hardware in your environment you can not use static dhcp settings. If you have a windows 2012 or later dhcp server, or linux dhcp server then you can setup dynamic pxe booting based on the target computer.
Once imaging starts then FOS Linux takes over and iPXE is history. For this make sure you have the version 5.6.x series of kernels installed. Understand this is not the fog server host OS kernels but the kernels sent to the target computer for imaging.
-
@george1421 Ok. I was unaware of the differences before. But that makes sense. Changing the bootfile-name to ipxe.efi gets the 5510 to boot into the FOG menu. But, as it appears nothing wants to be easy for me, there is another issue with the 5510 registering. I will be going through the forums trying to find an answer. I had to split the image because the forum wouldn’t take the original full size.
-
file /var/www/fog/service/ipxe/bzImagesays 4.19.101. Updating kernel to your recommendation now. -
@jvenus said in FOG 1.5.2 TFTP OpenTimeout:
Updating kernel to your recommendation now.
Good start. As I said you need the 5.5 (or later) linux kernel to get the required network drivers. You can update the kernel using the FOG weib ui in Fog Configuration -> Kernel menus.
-
@george1421 Yep. That’s where I did the update. Updated to 5.6.18. The 5510 boots into FOG menu, performed full registration & inventory, and is now capturing the image from that machine. Amazing help. Thank you!
-
@jvenus So looking back on this thread what can we state was wrong?
- Strangeness in capturing a good packet capture.
- Needing to get the right pxe boot options configured in your firewall.
- Virtual box and undionly.kpxe
- Sending a bios based boot loader to a uefi system.
- Needing to update to the latest linux kernel to get the needed drivers for the hardware.
Wow you have been on a journey with this issue.
-
aaaaaand another error… At one point, I edited the /opt/fog/.fogsettings file and changed the ‘fogproject’’ username’s password from what it had to ‘password’. But, that’s a different file. Looking into /var/www/fog/lib/fog/fogftp.class.php file now.
-
@george1421 Quite the journey so far indeed. I’m grateful that you’ve been helping me. Otherwise, I’d have probably just issued USB drives by now.
-
@jvenus Ah yes, I can feel another voyage is in your future: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
How did that get messed up?
-
@george1421 There’s a forum visit somewhere in the spider web of browser history that said to change that variable. Regardless, I’m working through that link you gave me. RE: “4)Now reset the linux user
fogproject’s password withsudo passwd fogproject”, that’s referring to setting the Linux user account with the password from the/opt/fog/.settingsfile, correct? It’s not explicitly stated and I don’t want to cause myself (or you) any more headaches than already incurred.
