@Tom Elliott: Yes, selinux was disabled and removed via:

sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config systemctl stop firewalld systemctl disable firewalld

Thanks for the reply, the process isn’t being interrupted at this point. I’m not relying on WOL at the moment for my needs.

@Jason-Sauders Hi, have you solved your problem ?

Just following up…

The CentOS7 install (from link on previous) seemed pretty straight-forward.
Only change was that I couldn’t rename eth0 from it’s preset ens32, but it’s working anyway.

It’s up and I’m pushing my Win7 image now.

@Wayne-Workman

Er… during your post I was trying to find a better way to describe why was 2 different post, and tried to state better what I wanted. Sorry again for being a bit confusing. Pls read what I wrote now. Anyway, p4p1 thing you suggested is a bit more dangerous than you may wanted 😄 It is like killing a moskito with gunship, full power. It will kill, but… well, a bit more damage than wanted. 🙂

My problem maybe originated that some things can be configured on the web ui, but sometimes config information is kept in different location which is ok if I dont want to reconfigure “all things” after setup. It is hard to be done if I dont know where to make changes (ip addresses are located in many places, but in config files duplicated, cannot be modified from webui. This makes things harder for debugging.

There have been major improvements made in the area of your problem on FOG Trunk. Also, 1.2.0 has known instabilities on Ubuntu 14.04 and newer. These instabilities are also fixed in FOG Trunk.

Here is how you would upgrade to trunk: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

If you don’t wish to use FOG Trunk, you’ll have to wait for help from someone more experienced than myself.

@Lasticko http://prntscr.com/7s6p7c see where it says “filename”, change it from undionly.kpxe to undionly.kkpxe

I’m gonna shelve this for a bit we break for vacation today when i get back I will hit this again and get all the logs posted.

Welp, SF is working enough again that I was able to pull down 3.18.5 . 3.0.1 is weirding out though.

@netman86 said:

Running through debug it said something about the partition table in the image being no good.

What’s the exact error? Can you get a screen shot?

Dunno how helpful this will be but I captured the two different magic packets with WireShark from the H81M-A PC.

From Fog - doesn’t work:
fromFog.png

From gWakeOnLan - does work:
fromgWakeOnLan.png

That figures … and I picked today to download and cache 3.18.5 and 3.0.1 so I won’t have to worry about them anymore.

@Wolfbane8653 That worked to delete my host! Thanks

The “Slowness” i believe you’re seeing is coming from the fact that you DONT have any internet access.

A way to fix this would be to setup the FOG_PROXY information. Have it set to 127.0.01 so things instantly fail.

This should help you out tremendously.

I finally got a chance to control the PC in question and it appears that the FOG service that was installed was the legacy service from the previous image. In addition, it wasn’t even running (or at least the tray icon wasn’t present. I uninstalled and installed the new client service and the errors went away. I am only left with this now:

[Wed Jul 15 20:58:32.249637 2015] [:error] [pid 23877] [client 192.168.0.236:49190] PHP Warning: mcrypt_decrypt(): Key of size 0 not supported by this algorithm. Only keys of sizes 16, 24 or 32 supported in /var/www/html/fog/lib/fog/FOGBase.class.php on line 241

Found out, with John, and a teamviewer session, the Group display issue was occurring due to memory limit issues. Increased to 256 and things started working.

The printer issue was corrected for in 3788, but 3789 has been pushed so you can, once again, default default printers in a group setting as well.

Thank you John for pointing out the issues with Printers.

Ok i will give that a shot this afternoon thanks

It’s possible but not simple. First you’d need apache installed on the storage node, and have the svn_folder/packages/web directory loaded as you would on a linux storage node. You would need to edit the Config so it reaches your database manually.

Once this is set, and apache/php is running, you should see the space as long as the path is correct.

@brycew Can you please try manually mounting via the steps here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_NFS

Perhaps something happened to your fog server when you rebooted… It’s the only thing I can think of.

For testing the NFS mounting manually, try the easy way first. If that fails, try the long way next and see what happens.

If those tests succeed while the FOG server is connected to your production network, then the network is not the issue, there’s something up with FOG in this case.

If those tests fail while the FOG server is connected to your production network, this could mean several things…

Move FOG back to an unmanaged switch and re-run the tests… if they fail, something happened to the FOG server during reboot. Move FOG back to an unmanaged switch and re-run the tests… if they SUCCEED, then it’s your network, guaranteed.

I had the same issue. I just used Centos 6.4. I believe after that the switch to MariaDB happend.