@Tom-Elliott Should now be corrected for.

I just looked through what was happening with this in the installer files.

and I decided it just wasn’t important enough to even bother with.

I’m just that one weird guy that was trying to build a config file for DHCP without actually using DHCP.

Please disregard, sorry.

@Wayne-Workman @Jbob

Push set for updated Client Version.

This issue is solved in version 6150

It is solved with the last version 6150

@Wayne-Workman yes. This is because the Storage Nodes can also be responsible for the “Checking in/Completion” of tasks.

@jgurka I’m willing to help you understand how the classes and what not operate within fog, and would also help with php in general. I’d more prefer to discuss that over chats as I’m sure we don’t want 4028, people passing out at their keyboards with glossed over eyes from forum posts describing the little details and intricacies.

@Tom-Elliott
Yes but that wasn’t the problem.
In funcs.sh script, I saw:
case $osid in
[1-2])
.
.
.
[5-7]|9)
.
.

And missing *) in the case test, so only 1,2,5,6,7,9 partition types were correctly tested.
And my image was 50 type (linux)

But these lines in funcs.sh have been totally rewrited, now the last case test is present

Thx

@Tom-Elliott It’s working now!!
The upload process took “horrible” 15 minutes, and i was forced to drink a coffee…(everything is a reason for a coffee 🙂 )
After uploaded a new image, d1.mbr was created.
The image was sucessfully created and deployed.
Thanks again.

Thank you so much for all… after upgrading the fog this issue has been resolved.

@Tom-Elliott said:

We are up and rolling after the latest SVN. Thank you Tom!

@GFm I’m going to solve this post then. THanks for the patience and understanding.

With the last revision I can see the multicast scheduled tasks 🙂
1_1453826902792_Tasks_Scheduler_2.jpg 0_1453826902792_FOG LOG Viewer_Scheduler_2.jpg

Thanks !!!

@Arrowhead-IT Scratch that, it totally worked after a restart. So if you go breaking your permissions just run the script posted and restart and violia!

These tasks are now showing up. @Developers

0_1453386801773_upload-69e4d0e8-31e0-4ff5-a2a5-a2ac047b970e

@Tom-Elliott As always, no worries, Tom. You the man! Everything is fixed 🙂

Fixed in latest.

This should now be fixed and more “refined”

This has been sorted out in latest svn 6018. Thanks!

@george1421 said:

@Tom-Elliott The probably the easiest solution is to create a procedure (wiki page) that if you need to update your fog server you need to do:

Update the settings in the /opt/fog/.fogsettings Rerun the installer Update the IP address for the storage node on the FOG system where you changed the IP address Update the IP address on a any master storage node that may reference this FOG server Update the FOG_WEB_HOST value update the FOG_TFTP_HOST value

I can I’ll marked this as addressed (Solved), since its not a technical solution but a procedural one that resolves the issue.
[Edit] I would, but it appears I can no longer mark topics as solved[/Edit]

Added here: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address