@Ric41 Once the time is updated, the services have no clue until they are restarted.

service FOGMulticastManager restart service FOGScheduler restart service FOGImageReplicator restart

@laintimes I was short with my response, I do apologize. But you described that your problem is hosts are waiting in the queue for imaging (in line for 5, in line for 10, … ). This only happens when there are no more available slots. Which is why I asked you to look into Web Interface -> Task Management and see if there are any tasks in there that may be stuck.

@Steuve68
Follow Tom and George’s advice, they will lead you down the right path.

I believe this was an issue in 1.3.0 though 1.3.1 rc 2/3 and I believe it is/will be solved in 1.3.1 rc4 and later.

First check your disk usage on the remote node as Tom said. Check it with this command: df -h look for partitions with 99% or 100% usage.

@FallingWax I remember having this problem although I can’t remember what I called the thread title… it’s here in the forums somewhere.

But, basically I figured out that very large images were not completing replication within the grace window and the fog image replicator would just kill the old replication task and start it again.

I brought this issue up to @Tom-Elliott at the time and he coded a fix - the fix made the image replicator aware of prior spawned lftp instances, and it would wait for those instances to complete before trying to restart them.

Maybe something in the code base is goofed, I’m not sure. But you need to look at this setting and write down what it is:
Web Interface -> FOG Configuration -> FOG Settings -> FOG Linux Service Sleep Times -> IMAGEREPSLEEPTIME So write that down, it’s in seconds. Next you need to go through your replication logs. Tom pointed out the places in the filesystem but they are also available via the web interface here: Web Interface -> FOG Configuration -> Log Viewer -> Image Replicator. You need to figure out if the image replication sleep time is close to when the image replicator just restarts the transfer - or not. If it’s close to when it restarts, this could mean that there’s an issue with the image replicator keeping track of lftp instances that it created. There could of course be other issues that we don’t know about so you should be extra observant when looking through all of this stuff.

Through chat had @jrm run a wget to download the bzImage’s from the fogproject server. OP stated these kernels worked.

@FallingWax Check the other post we’re playing tag between?

It works. Thanks

Have a nice day.

@Joe-Bishop I increased the FOG Configuration-General Settings-FOG_MEMORY_LIMIT to 1024 and now I am able to list all hosts.

The error in the 3rd photo says (paraphrasing) that you’re trying to put a 240GB image onto a 120GB disk, that won’t work. There are a few ways to solve that issue. My recommendation is to deploy the image to a disk that is 240GB or larger and then create a new image in FOG and set it as resizable, and then capture the image you just deployed. This way you have a resizable image that will fit on a smaller disk than what it came from. In addition to that benefit, the image would also expand to use all space available on a larger disk than what it came from.

For the other errors, they are weird. Not sure what’s going on there. It would behoove of you to share what OS you’re running fog on. Also, check how much free space you have available on your server with df -h. In the output from that command, look for partitions with 99% or 100% usage - if you see that, that’s bad. If you see that and need help with it, just ask here.

@george1421 Hey George! It’s CrimsnKdA from SW. I have a old Optiplex 755 with just 1GB of RAM and a 40GB HDD and ThinStation is flying on it with our setup. I know it’s not ideal, but it’s cheap is works with what we already have. I have it pretty much tweaked perfectly for us now, getting FOG imaging working with it was the last piece here. Thanks!

@Tom-Elliott yes it is, Please mark this thread as solved, and thank you for your help.

Ok, so i install first mysql-server and so i can set a password !
Thanks for your great job !

Thank you, deleting the repo=‘php-${php_ver}’ line in .fogsettings solved the issue.

p.s.: must be due to the change from php 5 to php 7 which was not supported by default at the time I upgraded to fog Version 1.3.0-RC-10

@Wayne-Workman So far so good. I think this might have done it. Two birds with one stone.

Thanks Wayne. I’ll write on here if it ends up breaking again. 🙂

@Wayne-Workman @Joe-Schmitt

Thanks for the updated feedback. I will look into the hiding the password as suggested - the script I wrote is probably crude and ugly.

I have another (unrelated) question to ask, but tomorrow and on a new thread.

Thank you again for your time and appreciate the great help and support.

Mark.

@joshuaparker What fixed the issue? The removing the id=‘login-info-form’?

I’ve added a schema change for 1.3.1-RC-2 that is addressed under “General Settings” from the fog settings page. This is just a simple checkbox. It’s default status is “checked” of course, but can be adjusted so you don’t consistently need to make changes during updates.

Thanks so much Tom

i set the “Menu Timeout (in seconds):*” for 2 seconds and thats solved my question, with autodeployment.

I appreciate very much your and your colleagues and work to facilitate my everyday work.

Best Regards.

@Wayne-Workman
That did the trick - thanks! (the mysql stuff worked just as it is)

@Tom-Elliott Woo-hoo, capturing an image now!

A big thank you to everyone who helped track down and fix this. Your support is amazing! Looks like I have another FOSS project to add to my contribution list…