I had the same issue, updating the plugin.class.php file did the trick.

Thank you.

Maybe buy something like an active HDMI Switch just to make it happy (e.g. I found Vention HDMI Splitter Switch 5 input 1 output HDMI Switcher for $15). Also the specs of the board show a DSI/eDP interface. Maybe there is some kind of cheap adapter/or mini-TFT you could hook up to that.

But let’s see what you find out with tcpdump and take it from there.

Edit: Ahh, google is your friend again… (possibly related, but maybe not)
https://github.com/raspberrypi/firmware/issues/211
https://www.raspberrypi.org/forums/viewtopic.php?t=11259
https://communities.intel.com/thread/76913

Thanks for the info and suggestion George.

@filisdiez This is for sure not a general FOG problem as we don’t have other users reporting this as far as I know. I can’t replicate this issue either. So I am fairly sure this is something within your environment. Try opening the URL I posted for all the FOG servers you have and see if you always get the proper version printed in the browser.

Looks this could be some kind of HTTP redirect issue. Maybe try this: tail -f /var/log/apache2/*.log (or for CentOS/Redhat: tail -f /var/log/httpd/*_log). Then boot up a client for registration and keep an eye on the logs the moment you see the error on the client screen. Stop the tail log (Ctrl+c) right after you saw the error on the client screen and post a picture of the logs here.

@wayne-workman yes but I would set a windows task to manage the updates. I found fog daily work fails once the client fails. Then I don’t have daily info that I was aiming to collect.

@tom-elliott said in Updating DataBase Failed:

@zago123 FTP is port 21.

To add to what Tom posted, FTP actually uses 2 communications ports. From the fog server to the target (command channel) and then from the target back to the fog server (data channel). So ports 20 and 21 are used for a fully ftp connection.

@tom-elliott

Thanks for the reply. Everytime I reinstall the fog server am I going to lose all my settings and hosts and images?

@hanz Thank you very much for your feedback.

I switched over to chat because the Q&A turn around was faster.

The first issue was the OP had dhcp option 60 defined. This caused the pxe booting client to think the fog server was a proxydhcp server. When the fog server failed to respond the client just gave up. It ignored the dhcp option 66 and 67 settings that were defined.

When the OP removed dhcp option 60 then a new issue popped up with some incorrect policy settings in his windows 2012 dhcp server. After that was fixed and he rebooted the fog server everything started working!!

I’m solving this thread since its now working.

@entr0py said in Error Restoring Images - Clients having identity crisis:

MSI

Can I ask you to post to this thread: https://forums.fogproject.org/topic/10987/what-can-we-do-when-we-don-t-trust-uuid With the inventory data from one of those MSI boards? We only need one entry unless you have different computer models than mainstream Dell,HP,Lenovo. We are looking for a good example of different mobo manufacturers and how they populate smbios (what FOG queries to identify the target machines).

@jhalbert You need to setup the location plugin: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

Assign your nodes locations, and assign those hosts at that remote site to the same location. After this, those hosts will only image using that location’s server.

@quazz I currently have a colon : isolating the host name and the path in my configuration. I can boot into the Win10 recovery properly. I’m suspecting the files are not in that directory or the permissions are set such as to not allow access via NFS. Either way this process will not give the OP what he wants. Will it boot the recovery program, Yes. Will it allow a complete restore, No. The swim files are still on the FOG server with no way for the recovery program to access them. I’m not done with the document yet, but it looks like Win10 will have to follow the same process as Win7 with a WinPE environment connecting to a network share to run the setup.exe program to install Win7/Win10.

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/10

@Sebastian-Roth and @Tom-Elliott Thank you so much for your help. Backed-up my current images and cleanly installed from the latest GIT-repo 1.5. Coping back the same hooks worked again. Not sure what happened during the upgrade but fog is back in production now.

Thank you
Chakri

@sebastian-roth
Updated to working this morning. I’ll post an update after we get a few machines imaging. Thanks again for your help.

@Deimos Ok, great to hear this is fixed! I am marking this solved then. Feel free to open new threads in case you run into new issues.

@degaro While this response may be a bit snarky; my response would be, what would you have learned if it worked perfectly right out of the box? What do you now know that you didn’t just a few hours ago? You DO learn more and remember it longer when you have failures than success.
The FOG developers can only protect the IT admin so much. I agree that the question needs to be worded better. Maybe something like:

Would you like to have the FOG server act as the DHCP server for your network? [y/N] Y

The default is no, but the IT admin can still pick yes. The developers really can’t stop that.

@Avaryan Well it looks like this got us past the DHCP issue of the inital posting. So adding that ID to the kernel source code does seem to help.

Please check your apache error log right after you see this error on screen. See my signature on where to find the log on your FOG server.

Just dug around, and it would appear that you are right about being able to use GPO. Is there a way to automate this? If not I’m probably just going to go back to sneakernetting this from a flash drive. We haven’t joined our computer to a domain yet so I can’t really push it that way.

@Taspharel This hopefully helps:

chmod 777 /var/www/fog/service/ipxe chmod 666 /var/www/fog/service/ipxe/bzImage*

Then try kernel update again.

@Deimos Sure, all fine. Take your time and thanks in advance!

We should be able to collaboratively work on this here: https://demo.firepad.io/#6XlP080kbJ

Would be great if you open a new “German Translation” thread anyway. I am sure it’s good to post it there and discuss things.