I may have found the issue here. I was curious as to why FOG was refusing to resize the disk, so I thought I’d try a manual resize in linux/gparted. Booting in to the gparted live cd, gparted could see the drive and all of the partitions but it was failing to read the contents of partition 4. I Googled this and it looks like it may have been caused by bad sectors and running chkdsk /f had fixed it for others so I tried that, went back in to gparted and now everything looked fine. So I’ve run a new capture and it appears to have shrunk the 4th partition as expected. I’m currently deploying it to one of the drives that was failing and all is looking good so far. I’m not sure what caused the issue in the first place, I hadn’t modified the partition table at all, I had just installed an admittedly fairly large number of programs to an existing image and tried to recapture it. @Quazz @Sebastian-Roth @EduardoTSeoane Thanks for your help on this folks!

@JackWallington Please answer George’s questions first. As well let me add this one. Do you have a D-Link DGS-3620 switch between your HP desktop and the FOG server? If not you still might check to see if some kind of DOS attack prevention is enabled on a switch connecting those two - more information see here.

OK. Will do. Thanks!

Found the issue and was able to fix. Fix will be available for RC-6. Thank you for reporting.

@Ph3noM Fog doesn’t set a DB password - if fog sets up the DB on a new server, it’s left blank. The installer (at least in FOG 1.3.0 beta) asks you for a DB password just in case you set one in the back end. And of course if that’s the case (and 99% of the time it is) then the field in /opt/fog/.fogsettings would be blank as well.

@Wolfbane8653 thanks for the help. I thought there might be issues running both svn and git but it went smoothly. Thanks again.