@george1421 Gotcha. Thanks for the reply. I’ll post a picture of the error when I’m able to get back to testing next week.

@Tom-Elliott

Yeah, this was my suspicion. I see both sides of it too. Sounds like I’ll have to either super simplify some of my install scripts and make some sacrifices or figure out another solution.

I appriciate the response and confirmation!

@george1421 Hi,

Thanks for your reply. Its strange. I am working with (almost exclusively) early 2012 hardware. My older Imacs 2009-2011 afaict pxe boot fine image with FOG w/o issue. The problem comes along when, I try to image our macbooks. They display different levels of progress before they flat out hang. I had one mbpx,y I’m almost sure it was a 3rd gen intel just can’t find it right now. I may be being processed to go out the door to our clients.

Yes the 2019 verison of ipxe was executed from a boot of clonezill 3.1.x the version I would attempt to boot from ventory stick or from an imaged usb stick would display an error regarding not having efi capability and/or hang or return to the ventoy menu. If I just let them be long enough the MBP would just restart.

So I did attempted to roll my own and ran into the same problem with the oobox downloadable iso/zip file. Hang… I am researching w/o much success with how clonezilla compiled their ipxe menu entry or how to just plain add efi capability to ipxe.iso/zip and burn it to a usb stick. I just am not knowledable enough to formulate a good question or find what I am looking for (cause I don’t know:))

So thanks again for your reply. I have a large donations of older MBP’s coming just before the holidays and I would lik to be able to make it rain.

Regards,

@azm9s
In general, it didn’t work.
it doesn’t add it to the domain, that’s all.
Either I did something wrong.
or I have configured something wrong in the settings.

Hello, it looks something is wrong with you backend.
Are you able to open from the browser:

http://192.168.1.22/fog/service/ipxe/boot.php http://192.168.1.22/fog/service/ipxe/bzImage

?

@george1421 No luck, could you please have a remote session at your convenient time?

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.

@kentasmith Try changing your DHCP option 67 to another one of the boot files available (link below). We had this error and this resolved it. Think changing it to ipxe.kpxe instead of undionly.kpxe helped.

https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/#option-67

Hey @george1421 , Thanks for the quick reply, sorry for the missing details.

What device is your dhcp server? (manufacturer and version)

DHCP (and DNS) is running on an Active Directory 10.0.20348.1668, Windows Server 2022 Standard

Is it on the same subnet as the FOG server? You mentioned the VM and FOG server was on the same subnet.

This applies to any machine I’ve tried to deploy to from fog, for example fog is on subnet 100, unless the target of the deploy is specifically on subnet 101 it will fail to boot into the PXE server. Even with a Workstation/VM on subnet 100 (exactly the same subnet as the fog server) it will without fail time out this will happen on any subnet other than 101. In our case VLANs will correspond to Subnets.

Any machine on the 101 subnet can pxe boot to fog to capture and deploy with no issue with both UEFI and BIOS.

What hypervisor are you using?

We have found that we will see this issue whether on a VM or a Workstation so this isn’t limited to the hypervisor in question.

I assume when you say “run PXE” you are saying you are trying to pxe boot the VM?

Yes, correct.

Is the VM in bios or uefi mode?

We have tried both with the same result for either.

What specifically do you have defined for dhcp option 66 and 67?

For the two DHCP Policies we have in place for fog we have the following options set for 66d and 67:

FOG snponly.efi policy
66: 10.2.100.103 (IP address of our fog server)
67: snponly.efi

FOG ipxe.efi
66: 10.2.100.103 (IP address of our fog server)
67: ipxe.efi

@luilly23 thanks for the reply. It was a working script before and I had updated it to comment areas and operations recently and added regions within the powershell script. There were no reboot options that I can remember (fairly sure) inline in the script but will double check.

There was a reboot option on the snapin itself.

Is there any log of the fog client to server comms that could say “this caused the reboot” or just more detail. I was thinking of turning the reboot off of the snapin properties to see if it would progress.

@george1421 result!!!

i bought a HP NIC as i have a HP laptop and it works

this one if anyone is inteerested

https://www.amazon.co.uk/HP-N7P47AA-Network-DesignJet-Adapters-Black/dp/B01618WGMY?th=1

as literally star tech, ugreen, tp link, realtek or asix chipsets didnt work

@george1421 I have run all test and first, there were a firewall rule that were blocking TFTP from the FOG server then after running more test, I realised that it’s not link to hardware or sofware on the server.
During test, I just changed the port on the switch next the computer to keep most of the hardware between server and client.
On same vlan I run at 450 Mbits/s (around 50 mo/s) and when I change vlan, I run at 150 Mb/s only.
And under 20 mo/s max with Windows TFTP client so I give up using it to run more tests.
Colleagues says there is not QOS but there is definitly something reducing the speed.

a06abb6b-6197-402f-ba10-c8be4fddc41a-image.png

This can sometimes happen after you have sysprepped an machine and missed the boot menu prompt, entering the Out-of-box-experience. Trying to shutdown the device will leave the dirty bit resulting in the unclean error.

To avoid having to sysprep again, allow the device to enter OOBE again and hit shift+F10 and enter “oobe\bypassnro” at the resulting command prompt. Once you hit enter, the system will perform a clean reboot, clearing the dirty bit and allowing Fog to capture the filesystem correctly.

Hopes this helps someone else as some Dell machines are notorious for failing to get an IP from IPV4 PXE boot.