Posts made by adukes40

@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.

I will be back at the shop tomorrow, I will get a pic then.

It grabs DHCP, but not TFTP. error 32 I believe, but I will get that pic for you.

@wayne-workman before testing anything else I will just fire these back real quick…

Optiplex worked summer 2017 - Correct
Optiplex 780s plugged into the ports that the 390 was using still works - so network problems are ruled out. - My thoughts
DHCP server is ruled out since you’ve not changed it at all. - Options 66&67 have not been touched.
Check your patch cables between the 390 and the building, ensure they are not kinked/ripped/broken/shredded/broken heads/clips/loose connections/etc (high schoolers are really hard on patch cables). - I have the 390 in my office I’m testing with, which is not working either. Plugged another 390 in the same spot, no go. That’s when i plugged the 780 in and it worked.
Please try a dumb mini-switch between a 390 and the building’s port - let us know if that changes things. - this is the port I still need to do. However, we just placed Aerohive AP’s up in our school, which requires us to have our state trunk ports on the switches. Ont the other hand, I specified the port to trunk, but being the 780 worked, this shouldn’t be an issue either.
Did you do a bios update on the 390? Have you tried updating the bios? - Have not done that yet.

Running FOG version 1.4.2

These machines imaged back in the Summer, but for some reason they now decide to get the TFTP timeout error. Plugging an Optiplex 780 with a Intel NIC in it works perfectly fine on the same drop the Realtek is plugged into.

i tried to download the latest kernel and rename it, then point that host to use that specific kernel, but still did the same thing.

the DHCP sever is and always has been set to use undionly.kpxe.

This also isnt specific to this drop, there are other 390s doing the same thing on the other side of the building.

Said it couldn’t resolve the URL’s. We recently dropped our DC it was pointing to. So I edited the interfaces file to an updatde DNS IP. So basically, it was DNS, mixed with a DUH moment on my side. Thanks for pointing to the log file to shine my stupidity (－‸ლ)

Server

• FOG Version: 1.3.0
• OS: Ubuntu 14.04

Description

Tried going from 1.3.0 to 1.4.2 this morning but get error saying"

adding needed repository failed. Has the upgrading method changed? I still use
cd /opt/foginstall; svn up; cd bin; ./installfog.sh

I do all the cab extractions before placing them in FOG. It copies the driver folders over, and it works. Of course your scripts look different than mine because I didn’t edit it that far from the original from the other post.

I personally like the page the way it is. (Still running 1.3.0).

@Tom-Elliott I was afraid of that, thanks Tom.

Ok so in the GUI say the hostname is 12345 because thats how we manually registered them. Can I use the client to update the hostname in the GUI from whats on the machine? so 12345 turns into 12345-abcde?

I know I could remove them and wait for them to show as pending hosts, but that isnt practical with 3000 hosts, then having to reassign snapins to those hosts.

Thanks.