@itcc correct

@itcc Two ways.

Manually: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address With a tool: https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

I remoted in with teamviewer and helped the OP get things working correctly. We had to ensure that the dhcp server only bound to the imaging lan NIC adapter and not both. We also found a nuance with ubuntu where it only wanted one interface up at a time by default. Once we had both interfaces up, fog installed correctly and like the OP needed it. Solving this case.

@george1421 In that case, the issue resolved. Thank you for all the help.
Tom

TY guys, I solved it, the path in tftp options was wrong. I saw other post with same issues. many tks for help

@Greg-Plamondon The new video is interesting as is seems to show that it finds the interface eth0 but is not able to bring it up within 35 seconds. What kind of client model is this? Are you able to FOS boot this very same machine at a different location? I kind of doubt but what do I know. 😉

Tom,
Thanks for your help! I reapplied (what seemed to be the already) correct permissions, rebooted the server and now it works!

@x23piracy finally figured out snapin packs and they worked perfectly. Thanks guys

So, worked remotely and was able to help determine part of the problem.

Installed apachetop and took a look, found a lot of things still looking at servicemodule-active.php. We moved away from this call as it had some weird issues on its own. Moved the file and the GUI become much less sluggish. Worked to get phpmyadmin working as well. This wasn’t a problem with php-fpm vs. libapache2-mod-php (though I did make sure phpmyadmin would access using the php-fpm system). Part of the problem that was happening was the rewrite rules that handles api system.

Moved the rewrite rules into the directory stanza of the fog.conf. Made this update in the working-1.5.1 branch as well. I haven’t had time to test whether this move actually still allows the system to work, but it should. Will work on that this weekend (testing to see it works properly).

Also, we are still working to help purge the db of old stuff that’s no longer needed.

@tom-elliott said in Target cannot shutdown if program is open:

You were trying to say MOVE3 was modifying the abilities of the FOG Service.

Right
But MOVE3 has problems of its own. Can’t tell if the key is there or not. Now we have the server room under lock and key (3rd world country lol) so I don’t know what the error was.

@Wayne-Workman that tool helps with TCP/IP printers, not network shared ones.

@BrendoJohnso Can we see a screenshot of the printer config in the GUI (feel free to replace any sensitive information), as well as the C:\fog.log from a machine that is failing to add the printer?

You could also try a shutdown -s -f on the machine, that has helped me in some cases.

In addition to what George asked, what are the image settings for what you’re trying to upload? Does this happen on other machines as well?

[mod note] Marking as solve. I setup a teamviewer session with the OP and helped him fix this and a few other issues. At this point the OP is imaging as designed now.

In the end it wasn’t what FOG was doing, but the OP ran out of disk space on the root partition, and that caused mysql to not start. Flushing some failed uploads provided enough disks space to restart mysql and fog.

Before this thread dies, I just want to mention how much better the newest Fog Client has been. The version offered with v1.4.4 always gave us issues of not restarting the computers correctly after imaging, resulting in needing a few manual restarts. Sometimes it wouldn’t join the domain or change the hostname properly either. v11.15 has been not shown any of these issues and has worked flawlessly for us so far!

@george1421

Since it’s working, I’ll keep it as is.

Thank you for the quick resolution and for everything you do.

Tom

@Wayne-Workman I apologize I meant to say storage group, I figure ‘“default” storage group’ leaves enough context clues for the reader to infer that a “storage account” is a storage group.

@Sebastian-Roth thank you for the speedy response as well!

The solution to the issue was that I had to create a separate storage node to correlate to the storage group being created, and then setting the storage node to the corresponding storage group. The purpose for this was to better organize snap-ins to certain “task groups” like what is present in Norton Ghost, I hope that this helps.

@george1421

I got it working, I had to change the permissions slightly differently.

Cross linking with https://forums.fogproject.org/topic/11573/increased-network-traffic-since-1-5-0-upgrade-snapins , as a replication bug could cause the web GUI slow down.