FOG 1.5.2 TFTP OpenTimeout
-
@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. -
@jvenus I’m not sure I understand your question, but the linux user
fogprojectneeds to have a password set. That password is set by the fog installer and “no one shall touch it”, is the commandment by the developers. If you change it, then you need to then update the .fogsettings file and then change it in all of the places it hides in the web ui.You are not the first person to mess with the password, that is why I already have a tutorial on how to fix it.
-
@george1421 The 5510 connected. The FOG server captured the image and was able to deploy it to another 5510. There’s a hiccup with the image containing the Dell service tag, but that’s something I’ll work on with our image creator. The image that I’m capturing from shouldn’t have that information in it. FOG is capturing that information, but from where I don’t yet know. Maybe the recovery partition? More reading to be done. Probably just need to restrict the partition that is being collected/deployed. However, as far as this post is concerned, FOG is working in our environment because of your help. Thank you for all your help.
-
@jvenus I will give you some suggestions now that you have it working.
- Develop your golden image on a VM. You can use VB but its not my preference. The logic is the vm is hardware agnostic and generic. You will get a cleaner end product if you build it in a VM.
- Create your VM golden image on the smallest disk possible. With that said, most reference images will fit onto a 70GB virtual disk just fine.
- Since you have an imaging solution right now, decide if the recovery partition adds any value in your environment. We are seeing with Windows 2004 that the recovery partition is causing issues with resizing the partitions. So I would pose the question, do you really need the recovery partition? In my golden image I’ve been deleting the recovery partition. If you feel you need the recovery partition make sure the main partition (the one you want resized) is the last partition on the disk.
- Create a single image for all hardware. I have a tutorial on how you can load the hardware specific drivers post image push. You will then load them during the oobe/winsetup phase in the setupcomplete.cmd batch file.
- Sysprep your image.
- Either use sysprep to power off your image, or use
shutdown -s -t 0, or disable fast startup then shutdown your virtual machine for capture with FOG. If you don’t you will get a windows dirty bit warning because windows was not powered off correctly for image capture.
-
- Our team used Hyper-V to create their image.
- That’s about the size they used.
3-6) The current “solution” is USB drives. The team developed a sysprep’d Win10 .wim and uses Dell’s Image Assist to restore the image and infuse drivers. (We provide Dell with an annual .wim to include on all of our purchases.) Since all of our machines are Dell, including the CAB files on the USB for Image Assist to pull from is easily updateable. But your question about the recovery partition is very valid. Most of our clients are remote. So I think the logic there is that in worst case scenarios, the user could at least have “something”.
I know that FOG won’t use .wim. I think I’ll explore the route of creating a .vhdx out of the .wim, then capture the image with FOG, and then load the drivers (with your helpful link if I could get it please) post image push.
-
