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.

I just spoke to the guy wanting these and the requirement has changed- I also need a small (100mb) partition for the lab, so that’ll be six partitions in all.
I’m testing a RAW image clone right now, I can’t think of a reason it wouldn’t work if FOG manages to initiate the copy on the destination…

@Omanimous said:

Changed Option 67 in DHCP to undionly.kkpxe and it seems to be working fine.

lol glad you got it working. I’m sure it will be fine.

In the future, when you have network booting issues, the boot file should always be your first thing to inspect and think about 🙂

@Tom-S said:

@Wayne-Workman
So you can have a very fast server but if the client is running an economy processor then thing may become a bit slower.

True, but when you offload the CPU work, you not only free up the server’s CPU, but you free up the server’s bandwidth.

And, while one client with an economy processor might run slow, you can run significantly more concurrently.

Untold bug fixes, greater speed on upload and download, additional features. It is well worth it in my opinion.