@JasonNaughton Looking at the code the error would indicate that the target computer can’t reach the fog server.

https://github.com/FOGProject/fos/blob/8893d32bfb702dcf7b8f5427ccd6748fac15df17/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network#L64

What I want you to do is to pxe boot the computer into debug mode. Schedule a deployment to this computer but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer, you will still get the errors but you will be dropped to the fos linux command prompt.

run this command ip a s that should show if your network interface has an IP address. If not then issue this command.
/sbin/udhcpc -i enp128s31f6 --now where enp128s31f6 is the name I gleaned from your screen shot that appears to have picked up an IP address. See if it gets an IP address now. See if you can ping the fog server’s IP address.

The ‘checker’ script makes this call to verify your fog server is reachable.
curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 replace the entire ${web} with the IP address of your fog server. See if that returns a value.

Finally search the system messages to see if there is something related to firmware.
grep -i -e firm /var/log/syslog I think syslog is the right file, if it returns nothing try /var/log/messages One error could be the network adapter needs a specific firmware for the network adapter to communicate. That firmware may need to be added to the linux kernel.

@chevengur The flag is onDemand -> 0 = No, 1 = yes.

@Tom-Elliott What’s the difference between the full and quick registration processes then? because AD join exists in full, but not in quick…

@jacaman Does this happen with every HP computer or just one in specific? Does this happen with any other brand/model of computer? Have you tried deploying that same image to another computer? Have you tried replacing any component of the HP computer: HDD/SSD/NVMe, RAM, network adapter (dongle instead of embedded port)?

@sloeckle You can use an older kernel for now, but I’ll work on a fix for this issue. I don’t have access to the hardware needed to reproduce this issue. Are you willing to help us test some kernels?

@Tom-Elliott Cheers, works as expected now!

To add to this, we’ve been imaging a variety of desktop and laptops to Windows 11 last week and we’ve had three occasions where FOG has imaged to a connected portable hard drive rather than the local hard drive. I don’t remember it doing this before.

My technicians are on the lookout and are trying to remember to disconnect portable drives ongoing before a deploy but has something in Windows changed recently? We’re on FOG Version 1.6.0-beta.2233

Thank you!

Ok, nevermind, did the git thing, got it working, cheers 🙂

@Tom-Elliott can confirm, this does now appear to work in 1.6 - huzzah! @george1421 looks like your hard work has paid off and it will eventually be in the stable branch!

@Tom-Elliott cheers - looks like someone changed working branch in 2019 to add hdbios, and it’s not something that’s in the dev branch either!

I think I have the same problem and I want to be sure of exactly what I need to do (I don’t know if there is a step-by-step tutorial…).

I boot with a USB-C network adapter on an HP Elitebook. It finds FOG, I have the menu, I choose to deploy an image, and then I get this error message:

IMG_20251106_162705.jpg

Is this the problem in question?
If so, what exactly should I do? I see (link @FlorianLenz ) that I need to replace two files with the new ones, then run the .sh. But isn’t that dangerous for other network boots?

Thank you in advance for your help.

@george1421 No, they were in proper failover config and the options replicated between the scopes. But it’s all good now and that’s the important thing ❤

@Tom-Elliott Just wondering if I could have your input here.