FOG 1.3.0 RC23 Multicast not working - StorageNode

[Duncan]

@jhuebner said in FOG 1.3.0 RC23 Multicast not working - StorageNode:

@Duncan Then you need to do the truncate stuff in the database mentioned somewhere else

Truncated but still no joy.

Il go and do some fault finding now.

Cheers for all the help so far @Tom-Elliott @jhuebner @ryanxplosion

[Tom Elliott]

@Duncan What did you truncate?

Please try:

TRUNCATE TABLE multicastSessions;
TRUNCATE TABLE multicastSessionsAssoc;
DELETE FROM tasks WHERE taskTypeID='8' AND taskStateID NOT IN ('4','5');

[Duncan]

@Tom-Elliott

first time truncated:

TRUNCATE TABLE multicastSessions;
TRUNCATE TABLE multicastSessionsAssoc;
DELETE FROM tasks WHERE taskTypeID='8';

Didnt make a difference.

Just ran the ones you gave me there, still stuck at partclone screen.
Restarted FOGMulticastManager service and mysql service for good luck too.

[Tom Elliott]

@Duncan said in FOG 1.3.0 RC23 Multicast not working - StorageNode:

Restarted FOGMulticastManager service and mysql service for good luck too.

You recreated teh taskings and restarted the clients?

[Duncan]

@Tom-Elliott said in FOG 1.3.0 RC23 Multicast not working - StorageNode:

Try these steps please:
rm -rf /etc/php* /etc/apache2*
apt-get purge php5* php7* apache2* libapachephp

Edit the /opt/fog/.fogsettings file.
Change out the php_ver to read with php_ver=‘7.1’
Change out the php_verAdds to read with php_verAdds=‘-7.1’
Delete the packages line.
Rerun the installer.

Is it worth doing this on my FOG server also. I only did my master storagenode

[Tom Elliott]

@Duncan
You can do this on the server too… Though I still think the DB needs to be cleaned up first.

[Duncan]

@Tom-Elliott

Your probably right. Iv had this DB from FOG 0.32…

[Wayne Workman]

@Tom-Elliott This line could fail:
https://github.com/FOGProject/fogproject/commit/5ead9f7a9dfd822aae06bb99de41769b87988ddb#diff-4d38e5a470509891be8d02be2ec77126R37

The output should be sent to the installation log, and the echo line below it replaced with:

[[ $? -eq 0 ]] && echo "Done" || echo "Failed"

[Tom Elliott]

@Wayne-Workman The issue is where this is happening in the source, so the data to log to may not be fully ready and available to start logging to.

If this doesn’t work, the installation steps will fail anyway. That’s why I didn’t focus too much the error stat information.

[Wayne Workman]

@Tom-Elliott Ok then, but it would still be good to have “Done” / “Fail” messages I think. That’s simple to do.

[Tom Elliott]

@Wayne-Workman Yep, for now I’m not overly concerned. It will work one way or the other (fail later or we can fail it immediately). Eitherway, there’s at least a potential solution that prompts for user input first anyway.

[Tom Elliott]

Just returning here to let everyone know that, I don’t fail due to it, but the messages will report as Fail/Done depending on the status for the removal bits and pieces.