@Tom-Elliott Actually, the issue just appeared on our big fog system, too. And after refreshing the page, that too disappeared.

0_1470939151452_upload-2973df0c-a05c-4a51-92e1-db1d1949078f

@Tom-Elliott Yes. Thank you.

Fairly sure we got this figured out tonight. I’ve added the changes to the head state of svn and git so the fixes are now a part of 1.3.0-RC-8 so no need to wait.

Thanks @Wayne-Workman for the teamviewer which helped us narrow down what the issue was.

For all following along, it basically boiled down to file hashing taking far too long on large files. The checker would fail if the script took longer than 30 seconds and would also fail if the connection time was too long. It would also fail if the connection time was too long (timeout was defaulted to 15 seconds). So by default, if large file was not hashed within 45 seconds, it would fail the snapin completely. The fix, for simplicity sake, is to allow the hashing call to run unlimited and increase the connection timeout to a day. This could’ve been fixed had I kept a hash within DB, but I have a hard time trusting it as if somebody manually updates a file it would always fail the hash.

For Huge snapins (> 5gb) I’d recommend installing the software in your image rather than rely on the snapin system to install them. I say this, because even without hashing, having such a large file (especially spread out to many hosts) will create a lot of bandwidth usage (leaving the server less to perform imaging with if needed) and would be called that number of times to start transferring the file. Add in the hashing (which is another way The client and server help prevent bad files) and you have one big mess of Load and IO access issues.

Both of the selector issues are fixed in RC-9.

I’ve marked the thread as solved so as to ensure I don’t go crazy looking at “unsolved” threads. RC-8 will have the fix for the replication issues as well as a few other fixes that were rather not issues (in the directest sense of the word) but just redundant.

The additional fixes just ensure that if all files are matching, it doesn’t try to resync the data between the two sides (causing unnecessary load – if only for a second or two).

A part of the “whole” is it will also enable ALL services to update their loop update times properly. Only MulticastManager had been working properly apparently, not that many would’ve noticed a serious issue. It will properly check the new sleep times and start using the new sleeptime after the next cycle runs (if it isn’t already running).

For example, say your FOGMulticastManager is setup to go in 10 second intervals (which is the default) and you want FOGMulticastManager to go in 300 second (5 minute) intervals, if you updated the FOGMulticastManager sleeptime to use 300, it will update after the next check, or when this current check is complete.

v0.11.5 of the client prevents premature startups of the service. You will still need to disable the client before syprepping and restart the computer when sysprep is complete though (as described in the updated FOG Client wiki article).

@jbender So that will be available relatively soon in the “RC” cycles (unless we decide to go full fledged lol).

All is good to go now…

@Tom-Elliott I did not see that one. Thank you good sir.

@Raymond-Bel
it’s from line endings not being read properly.
^M translates to (Native) mode line endings (but it confuses installers).
fix hopefully in SVN now.

It’s not something I can tell when submitting either. It’s only when one informs me like this, so thanks.

Found the issue and was able to fix. Fix will be available for RC-6.

Thank you for reporting.

@Wayne-Workman Thanks, yes I may move to 64 bit. However it’s good that my issue has highlighted the inconsistency in the code which sounds like it only shows up in 32 bit OS’s. I’m guessing there mustn’t be too many others with my setup out there, otherwise this would have been reported a while ago. Glad its a relatively easy fix, I’ve rebuilt these boxes a few times recently and didn’t wish to have to do it again. Regards, Mark

I feel I should add, the reference error isn’t the cause of the issue, not directly at least.

@Wayne-Workman Fixed issue will be available in RC 6.

Issue would only occur in the case a user made a change, then hit the “back” button.

I’ve corrected the action of this for all elements that have these same type of actions. Will be good for RC-6.

@ablohowiak As a side note here, if you’re 100% new client in your environment, remove the legacy password in fog, just blank it out in the fog config defaults, and on hosts via groups. The legacy pass has security vulnerabilities.

Great! Compliments for the super quick response and fix. That’s what makes Fog stand out!

This is already fixed for rc 6.

Group snapins should properly deploy. Will be available for RC-5.