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…

@dadush91 So the good news is that FOG can see the disks and partitions. This looks to me like it’s a hybrid HDD with about 16GB of solid state and then 250GB mechanical, and FOG is seeing these two things as two different disks. Or you have a 16GB thumb drive or SD Card stuck in the laptop somewhere. If that’s the case, take it out and try again. If that’s not the case, try “Multiple Partition Image - All Disks” as the image type and then try to capture again. This is pictured below.

0_1483294993602_Multiple Partition All Disks.png

@Wirefall [Moderator note:] I’ve forked this users post since the issue is similar to the OP of this thread, but deals with a different version of FOG. You can find your post here: https://forums.fogproject.org/topic/9201/fog-will-not-boot-failed-to-get-an-ip-via-dhcp

@iyoung Test completed. LDAP plugin added and test login succeeded.