Best posts made by adukes40

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

@abibbas I am fairly new to FOG, but i believe that is an older version and they are going to suggest upgrading to the latest trunk version.

https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

but to be safe you can wait for one of them to confirm that statement

@george1421 I will label step by step best i can.

1. go to machine, and enter PXE
2. TFTP loads
3. when the bash prompts comes up we enter ./autoimage.s, this run the imaging script
4. the script then appears on the screen with questions such as: what OS do you want to use, what room is this for, what is the SLA, and which printer config do you wish to use. the LOC variable is determines after windows installed and is populated based off the gateway being used. The others I just mentions are entered by hand.
5. once everything is enters there is a verification at the end of the script and if it is correct we type: yes and the script pulls the correct OS, and takes those other values and stores them in a .txt file.
   once all the imaging is done, windows starts, and runs our first auto logon script which basically runs dpinst, and sets the environment variables based on the info in those txt files.
6. next the second script runs which reruns dpinst to catch any usb 3.0 drivers left to install, joins the domain, runs a zenwokrs command to install applications. and reboots. after this reboot the ctrl alt delete screen comes up and the machine is ready.

Maybe that clears it up some. If not, I can try to vpn into my machine and grab that ./autoimage.s script so you can see what I am talking about.

I can’t tell you as much in the technical sense, but last week when I updated to 8255 I was still running the 0.10.6 verison of the client and things were breaking. After updating it to 0.11.2, everything worked like magic. I would suggest updating the client to the the new 0.11.2 version.

@Wayne-Workman … you beat me to it. I was just reading that section about an hour ago, and was getting ready to link that, hopefully it was still a viable solution

@george1421 Without looking I do not know for certain. But now that you say it I think it is just an * which is why it names it TECHNOL-blahblah

@Joe-Schmitt Went ahead and turned that off. Took forever to get through the GUI, but managed. Still running sluggish and timing out, and flooding the pipe. That will clear up here at 6PM because all the student workstations are set to shutdown.

EDIT: Actually the settings didn’t take. Now that the workstations have shutdown off I can get into the GUI at free will. It is NOW turn off (auto updating of the client)

@Tom-Elliott Alright, my issues seems to be checking out now. All looks good so far. Thanks Tom!

As talked about on the Hangout today, I mentioned that my snapins were not running. the client version I was running was 0.10.6, although I updated FOG to the latest release which included 0.11.2. I just did a test image to see what would happen. The host was imaged with 0.10.6 on the image, and the client updater turned on. During imaging it updated to 0.11.2, and ran the snapins.

During the Hangout, Wayne mentioned the importance of having the client updated to the latest, as Tom and Joe work closely together to have FOG and the client work together.

I just want to post that this indeed was the case, and my snapins are now working perfectly fine once the client version updated to the latest.

Thanks all

Just as a slight update. I came in this morning and traffic from the master sites was basically Null, and imaging from remote nodes seems to kick off. (there are some weird lines the show up before the image kicks off, will need to get a screen of those, might not be a concerning issue) Testing the image now to see if we are able to complete imaging. Also Tom I do believe I set the Snapins back to ‘’ instead of ‘abc’.

I just had this issue as well. I migrated a DHCP scope from an old server to the current server. It now has two scopes. For what ever reason, the boot options disappeared from the original scope but stuck with the migrated scope. I added the options 66 and 67 back to the original scope, and it worked.

/shrug