@tom-elliott thanks Tom! ok it’s working now, I forgot to change from dev branch to working one since my latest trouble. Everything is fine now! 🙂 keep on good work!

@coxm If you pxe boot the machine yes.

Thanks. I found the problem. Solved.

@sebastian-roth we had an extensive IM chat session. The OP found where the issue was and identified the need for snponly.efi for a specific hardware configuration. I had him start with the examples from the fog wiki and work from there. Where we left it was he was going to see if he could collect the system uuid to see if we could write a better dhcp filter to only send i386-efi/snponly.efi for that specific model and send ipxe.efi for the remainder of the arch 0007 hardware types.

well that really didn’t help readability at all.

But it looks like its a database issue. You might want to review this thread and see if it addresses the issue. https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

Especially if FOG was working one day and its broken the next day without any intentional changes.

@sebastian-roth Thank you very much! You are brilliant!

You saved to me an invaluable time!

I carried out the test of your procedure and all functions perfectly.

Thank you still for your assistance, and thank you for this software!

I love FOG ! It is the best !!

@sebastian-roth Thanks so much! That worked. ( I had those pre-config settings before when I ran the 1.4.0; however, I had reverted to a previous snapshot and didn’t re-configure them for round 2).

Thanks again,
Tamara

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