@Derek-Newbold As a very first step I may ask you to post a picture of the error that you see on screen when an image does not properly deploy “due to image size being set to 0”.

While I can’t be absolutely sure (there have been many changes and fixes since FOG 1.5.4) I am not aware of the image size playing any role when deploying an image to a host! It’s true that in FOG 1.5.4 the image size on client field is being updated and set to 0 if it fails deploying and that is something strange we fixed lately. It will only ever do this on captures now.

Nevertheless I don’t think the image size should influence the deployment process in any way. Please provide error messages.

@Derek-Newbold FYI I have seen ton of people running FOG in AWS with totally public IP and that works outside of any firewall issues, of course those instances involve people who have access to the local sites DHCP so they can update the tftp option in their scopes with the public IP 🙂

In my case it’s a private IP but I do have access to the networking side of things so sites throughout the organization can boot fine from HQ FOG server.

Thankyou Fernando!

@george1421 had a look at our Dell 5300 device and it doesn’t have the Thunderbolt port. Although we have resolved the issue another way, I may consider looking at getting the rest of the devices optioned with Thunderbolt ports.

Thanks!

Derek

@Derek-Newbold Good to know that php-fpm is installed and running! (Speaking of running processes, what does CPU and RAM usage look like (for processes such as apache, mysql, php-fpm, etc) when you try to do something that takes a long time for you?)

Odd that you’re experiencing performance issues despite this. Though number of clients could contribute to this.

If you have a bunch of hosts/clients, it’s also possible your database has grown quite a bit over time which can slow things down a bit.

@Derek-Newbold ok here goes…

firewall: yes those ports are correct. With just a comment. Remember that a FTP session is a two way street. Port 21 is used as the command channel and the remote site will connect back to the master fog server over port 20. FTP is a well known protocol so your firewall guys should already know this.

Location plugin. I was going to say nope, we don’t have anything… but then I look on the FOG Project wiki page: https://wiki.fogproject.org/wiki/index.php/Location_Plugin

What fog has issues with is changing the imaging LAN ip address after FOG is installed. As far as FOG is concerned that second interface is invisible. So its address can be assigned by dhcp, there or not it doesn’t matter as long as when its connected the fog server can reach the internet to download any packages needed from the host OS’ repo. Now don’t get me wrong you “can” change the fog server’s IP address after fog is installed but there are a number of places you need to change and then rerun the installer to fix the rest.

We have ended up rebuilding our image and it is now working OK. It mustn’t have liked something in our old image.

Thanks for your help and suggestions!

Use the built in kernel upgrade tool in FOG Settings -> FOG Kernel to install the down level kernels.

In the past I’ve had issues with the FOG server being able to connect to the internet through our departments firewall/proxy systems. I have managed to get it working this time tho thankfully and have downgraded the kernel!

I have also edited the php values and changed the client check in settings to 300. This has helped the CPU load on the server although it still seems a little high than what we are used too. At least it is a lot more responsive now on the web interface!

We are now having a GPT issue deploying an updated image that was captured after the upgrade (pre-upgrade images seem to deploy fine). I have started a new forum post on this though.

@Derek-Newbold I am marking this solved as we haven’t heard back from you in a while an I expect you’ve figured things out by now. Feel free to post again if you still need help on this.

@sebastian-roth I finally got around to trying this out the other day and after running a check disk and recapturing the image it is now resizing the partitions correctly upon deployment. I didn’t have to modify the ‘d1.fixed_size_partitions’ again so I’m assuming that the capture process either worked correctly after running check disk, or else it just continued to use my modified version of that file.

Thanks for your help in resolving this issue everyone, much appreciated!