@Tom-Elliott and @george1421

That did it. All drivers have installed successfully. Have a good day, all!

Finally figured it out. The packet capture was key. Apparently the file were looking for is when pxe booting with this particular version of dnsmasq is undionly,kpxe.0. This is the file that could not be found. I created a symlink like this - sudo ln -s undionly.kpxe undionly.kpxe.0 and it resolved the problem. Hopefully this will help future, non-Linux inclined users of FOG.

@FGeyer

I know this is an old topic, but it looks like you don’t have a solution. I have this exact problem. It looks like @Tom-Elliott may consider this unnecessary (which may very well be true for other use cases), but for the sake of using @george1421 's awesome driver injection solution, it would be really nice to have. My workaround was to utilize OS type 4 for Windows 11 as I am not using it for anything. I updated the following line in “fog.custominstall”

case $osid in
5|6|7|9)

to

case $osid in
4|5|6|7|9)

Then I updated the following line in “fog.copydrivers”

case $osid in
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;

to

case $osid in
4) osn=“win11” ;;
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;

Mark you image as OS type 4 and it works as it should. Hope this helps.

Finally figured it out. The packet capture was key. Apparently the file were looking for is when pxe booting with this particular version of dnsmasq is undionly,kpxe.0. This is the file that could not be found. I created a symlink like this - sudo ln -s undionly.kpxe undionly.kpxe.0 and it resolved the problem. Hopefully this will help future, non-Linux inclined users of FOG.

I have been running a FOG server for several years now. Configuration took a while, but once I had it up and running, it’s been bullet proof. Recently, we had a former employee “try to update” the server without permission. He was not able to tell us what he actually did to it, but it broke our ability to PXE boot. I’m certainly not a Linux guru by any stretch of the imagination, but I’ve been using my Google-fu to attempt to fix this to no avail. Here is everything I can think of that’s relevant:

1. I have updated FOG to the latest version with no issues
2. dnsmasq seems to be functioning fine
3. I am able to tftp -i 172.31.0.2 get undionly.kpxe
4. I can successfully logon to the fog web interface
5. I have attached a packet capture and screenshot of the PXE boot error

I’m sure there is a lot more I should include, so please let me know what you need and I’ll provide. Any help is greatly appreciated.

traffic-of-interest.pcap

@george1421 Thank you so much for the quick reply. I figured this part out. I ran sudo apt-get install dnsmasq and didn’t really pay attention to what was going on. It told me the latest version for LTS 16.04 was already installed, so I was still on 2.75. After a bunch of googlefoo, I check the version with dnsmasq -v and saw my error. I followed this - https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq and installed 2.76. Now, it’s working! This unfortunately broke DNS lookups on my FOG server and I’m not sure how to fix it. I can ping 8.8.8.8 and get a response, but can’t nslookup.

@george1421 I setup dnsmasq as you have suggested as I was not able to get my VMware VMs to EFI PXE; however, I am getting the as shown in the screenshot below when I legacy boot. EFI no longer functions on my working Dells. I am using Ubuntu 16.04. My FOG server is 172.31.0.2 (I updated all 5 entries in the script in the link you provided). I’m not sure where to go from here.

@george1421 Thanks, George. I think I’ve got it from here. You can mark this as solved. If I have further unforeseen questions or problems regarding this same issue, should I reply to this post, or open a new one?

@george1421 Looks like I got a horrible driver pack from Dell. I got several prompts titled “Windows can’t verify the publisher of this driver software.” Manual install of the drivers from this folder using device manager throws the error, “Windows encountered a problem installing the drivers for your device. Windows found drivers for your device but encountered an error while attempting to install them. The has for the file is not present in the specified catalog file. The file is likely corrupt or the victim of tampering.” I’ve been getting my drivers from here - https://www.dell.com/support/article/us/en/19/sln312414/dell-command-deploy-driver-packs-for-enterprise-client-os-deployment?lang=en and, so far, have never had an issue. This has been an awesome resource up until now. The pack I downloaded was the Latitude 5500 Windows 10 Driver Pack A05 (11/26/2019).

@george1421 I am going to attempt #2 now as i have to run out to a customer’s site now to do a VMware install. #1 will take more time than I have now. To provide some additional insight into what happens before and after I hard reset (because I just did it after letting the 5500 sit all night), when I came in this morning, the notebook display was black. Gesturing on the touchpad wakes up the display “Just a moment…”, so it’s not a freeze; it is responsive. Holding the power button for 15 seconds does a hard shutdown. After powering back on, I get “Just a moment…” for a few seconds then the annoying “Hi” and all the M$ crap that follows. I am then presented with a desktop (no request to logon, just the desktop with the expected icons). Trying #2 now.

I forgot to mention, a hard reboot allows the machine to boot into the OS, but SetupComplete.cmd does not run, so no drivers are actually installed (SetupComplete.cmd installs the drivers injected to C:\Drivers) and the workstation rename does not happen (a PowerShell script that gets called by SetupComplete.cmd).

We just received a new batch of Dell Latitude 5500 notebooks. We currently have an array of other Dell notebooks and desktops (17 in all) that we image with various golden images all cloned from the same base image built in VMware. This image is in audit mode with no preinstalled software or drivers. We clone the image, boot the clone (the clone boots in audit mode), install software (no drivers or VMware tools are installed), sysprep with an unattend.xml file, and image the workstations. Drivers are injected at the end of the Partclone process using @george1421 's post install script - https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed. We have found that keeping all drivers out of our images allows us to never have problems with deploying a workstation, until now.

The new Latitude 5500 notebooks hang at “Just a moment…” upon first boot (just after Partclone and the driver injection). We have never seen Windows 10 do this before. They seem to image just fine (after some UEFI PXE tweaking that @george1421 and @Sebastian-Roth helped me through on a previous topic), so we are not sure where to go from here. Any suggestions would be greatly appreciated.