It should have been fixed this morning. try updating to the latest version. i had this exact issue this morning.

@Sebastian-Roth And with that said, I will say although I am very new to FOG and Linux, I will try to help if I can. Wayne has been great and I had a good talk with George as well. The community here is great and full of knowledge.

So far FOG is great and I am trying to learn/understand as much as i can about it.

@JMacavali I believe you just disable secure boot, and make sure you choose to use Legacy ROMs. We do that on anything newer than a OptiPlex 790 (I believe) in our environment, I have 5040’s and We do not use UEFI anything yet.

http://<serverip>/fog/management have you tried typing that?

@george1421 I dont think that will work… each of our asset tags is a different number. asset tags are our primary way of knowing what machine is what. When it comes time to name the machine during imaging, our PS script pulls the asset and server tag info from the bios, and puts it together how we want.

So sadly i think i will need to the scanner-keyboard-scanner option… but still sounds better than keying in everything.

And helps on fat-fingering characters.

Quick update, I have tested at the building where the FOG and DHCP server reside. the 390s there work just fine. I’m assuming the DHCP server grabs the request before the AP’s get a chance to. On the other hand, we took a 390 to a remote site where AP’s need to relay to the DHCP server. Having the exact same issue as my building. It seems the AP is passing the DHCP correctly, but it cannot do theTFTP, which is where the timeout is occurring.

This is going to be a fun one. I will try to keep it updating as I find out new information regarding the Realtek nics and Aerohive APs.

I created a new image called Win7x32

Then went to hosts and set it there:

then to basic tasks, capture:

then i click create and get the 500 error. it all looks correct to me unless I am missing something.

@abibbas He needs the number in the cloud. Like here is 7911:

Located at the top of the web interface of the server. http://<SERVERIP>/fog/management

Just as an FYI, we had to remove the DHCP relays on the AP’s. As the switches were apparently handling the relays anyway, the ones on the AP’s were not needed.

i typed

/fog

mine is working with that set

I think there was a request made to fill it in by default, then the sysadmin could change it if needed, but /fog is what my storage node is using

@george1421 you doing that for every single uefi machine, or just the problem child’s?

@george1421 You say the 7010s will hang forever. I am on a 7010 that was hanging started looking around. When you say forever, do you mean it will never go thru, or forever as in it just takes a long time be will eventually go? I am currently running ipxe.efi

@jester805 We just got in a Precision 3530 that will only boot to the hard drive if it is plugged in with the network cable. As soon as we unplug it, it will say no drive found… My coworker did these steps:

1. (If you can get in windows like we can) run an elevated cmd prompt,
2. run this mbr2gpt.exe /convert /allowos
3. boot back into the BIOS and set boot back to UEFI
4. It should show the drive in there now.

If you cant get in windows I assume you would be able to do this with a restore disk or something similar to runt the command.

**Side note Once imaging is done here for the summer, we are going to look at moving to UEFI images and setting FOG to handle both using THIS ARTICLE.

Just as an FYI, we had to remove the DHCP relays on the AP’s. As the switches were apparently handling the relays anyway, the ones on the AP’s were not needed.

@dclark Checking in from Milford School District. I heard you guys switched over to FOG.

They are supposed to handle the wireless clients getting DHCP. We have one DHCP server, the APs relay DHCP requests to the server. This is in all buildings. Its really just odd that its Realtek acting this way. All the Intel nics do not act the same way, and none of them have this issue. Plus these AP’s were not in this building until December, which is why they imaged this summer just fine.

So they aren’t actually handing out addresses, they are just relaying it. Not sure why a wired client is trying to relay thru the AP. and why only Realtek. (thankfully we only have a handful of these)

Quick update, I have tested at the building where the FOG and DHCP server reside. the 390s there work just fine. I’m assuming the DHCP server grabs the request before the AP’s get a chance to. On the other hand, we took a 390 to a remote site where AP’s need to relay to the DHCP server. Having the exact same issue as my building. It seems the AP is passing the DHCP correctly, but it cannot do theTFTP, which is where the timeout is occurring.

This is going to be a fun one. I will try to keep it updating as I find out new information regarding the Realtek nics and Aerohive APs.

Welp, took the 390 over to the other building. only sees one gateway… something must have got jacked in this building during the switch configs. I will need to contact our state guy that handles these. I will see if I can get info out of them.

The building where this is failing is on the same campus as the FOG server, but they are separate subnets. I will take the machine over there and see if it does the same thing. If so I will attempt the pcap.

Something I noticed about this picture I did not notice prior. This is showing two gateways. There should only be one. I booted up a Latitude 3330 with an Intel nic and I get the correct gateway. I rebooted the same 390, now instead of 3.62, it shows 3.70, along with the 1.1. I have never seen that before in 10 years.
EDIT: Digging a little more, the 3.xxx IP address are the DHCP reservations of our access points. going to investigate farther. Still doesn’t make sense why only the realtek machines are seeing this.