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.

Just what I was looking for- thanks!

So, I’m not quite sure what the issue was but I couldnt wait to get back to imaging. I ended up getting new install going and now its working fine.

@Wayne-Workman; Hi Wayne. Just installed Kabuntu 14.04 LTS and it worked perfectly. So for my immediate needs, I think I’ll be good to go. On the Mageia side, apparently this issue started in the previous release 4. I looked at the mysql 127.0.0.1 vs localhost issue and sure enough there was a host resolve problem. So #mysql -u root -h 127.0.0.1 -P 3306 would refuse, but #mysql -u root -h localhost -P 3306 worked. So I added the line: ‘bind-address = 0.0.0.0’ to /etc/my.cnf below the ‘skip-networking’ line.
That seemed to let everything in sql work without passwords. That got rid if all of the mysqli error message in the apache error_log. However, It’s still not creating the ‘fog’ database and I have the same blank webpage.
It doesn’t appear to be throwing any exceptions even though the database is never created. So I’m still at a loss. What user is being used for mysql? Is it the ‘fog’ user?

@bitloader You can run DHCP on a 40 dollar Raspberry Pi… It will never fail lol, all solid state… it uses like 5 volts, connect it to a small battery backup and in a power loss, it will run for 2 weeks lol.

Ok we will give that a go. Thank you for the help.

@SantRamos Smells like an IP conflict…

Ok, After some more googling, I was able to find how to change to .kkpxe.
I did this:
sudo gedit /etc/dhcp/dhcp.conf
and changed it in there
after that I stopped and started the dhcp service.
That certainly helped becuase now I get past the “initialising devices” hang-up.
However, now it goes just a little farther and reboots.
the last thing in the screen I see is
init.xz…<OK>
then it reboots.
Can anyone point where to go next?
any key words I can google/search?
Thanks

I edited your messages, please use </> to past your code