@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!

Actually maybe I’ll try out Centos!

Also I should mention that our slowness issue seems to still happen even after hours when the majority of our client computers would be turned off.

@rude26 if you have the FOG client installed on the image, then I think by default there should be a “FOG.log” on the C drive of the computer. That log should hopefully have a section in it about computer name and domain joining which generally has info in it about what is going on. Just bare in mind that it appends to the log, so it could have that section of info in the log multiple times, so make sure you are checking the latest info in the log. Sometimes I clear the log and then reboot and check the log again to make sure I’m looking at the latest info.

Did you set it as a “Single Disk - Resizable” image type? If so, were you creating a Windows 10/11 image?

We’ve had trouble with that lately and it turns out that Windows was putting a little partition after the main C partition on the disk. I think FOG tries to resize the last partition by default, so it ends up only resizing that small partition, thus it won’t end up fitting on any smaller disks.

To fix it we just removed that last little partition before capturing the image. I think it was just a recovery partition or something that we didn’t really care about.

Hope this helps!

UPDATE 2: I have come up with a better workaround now I think.

I installed MySQL Workbench on the FOG server as I’m not very familiar with editing SQL via CLI.

I can see that the ‘imageSize’ field of the image has been wiped out, and if I set it to something (e.g. copy the imageSize from another image, even if it’s the wrong size) I can then image another host successfully and it updates the imageSize to the correct size.

Now I’m just going to work out what value it puts in the imageSize field on a fresh image (like in my first workaround), and use that instead of a random imageSize value when this issues occurs.

If anyone knows a better solution aside from updating FOG, please let me know!

So I have come up with a workaround for now.

I duplicated the image folder on the server, then created a new FOG image using that folder.

I then set a host to image using the duplicate image and it imaged successfully, and during imaging it updated the image size in FOG to be to be 100 GiB like it should be.

We now have tried imaging a host that is having issues again with the duplicate image and it failed once again, and the image size on the duplicate image in FOG is now saying 0 GiB.

I’ll endeavor to try and update our FOG install when we find a suitable time to do so, but hoping in the meantime there might be a workaround to reset the image size issue? Is it just an SQL reference somewhere that we can update/remove?

Hi,

We are having random issues where our captured image stops deploying successfully and when this happens we notice the ‘Image Size ON CLIENT’ on the image in FOG has changed to saying it’s just 0 bytes. Any further deployments of this image just fail, so we are having to recapture our image to get it to work again.

We think it happens when an image fails to deploy to a client for whatever reason, then FOG is changing the image size to 0 bytes which in turn is causing the image to stop deploying.

We found in the recent FOG change logs some references to the image file size, so we are thinking it’s something that might be fixed in newer versions of FOG? Is there any more information about this?

Due to it being quite difficult to update our FOG install, we are wondering if there might be a quick fix we could apply to our current version of FOG to fix this particular issue?

If that is not an option, is there an easy way to just tell it to re-import/recheck the image files on the server, as the files still seem to be there?

Current FOG version: 1.5.4

Thankyou,

Derek

@Sebastian-Roth thankyou! I’ll open another topic if need be when I get a chance to look at upgrading FOG.

@Sebastian-Roth in that guide one of the first steps is to re-run the installer after changing the IP address of the OS and in the /opt/fog/.fogsettings file.

My problem is that once I change the IP address and network connection back to what we normally run FOG under, I lose my direct (unfiltered/firewalled) internet access, so I’m back to not being able to run the installer. Is there any way around that?

Sorry this post is probably going a bit off-topic now.

@Sebastian-Roth @sudburr @Boyan-Biandov

Thanks everyone! We’ve changed our image capture to a fixed disk size now and we already happened to have the <extendpartition> bit in the unattended.xml file. This arrangement is now working for us and the partition has been automatically extended on our test machine.

We don’t really need the ‘Single Disk-Resizable’ if we can get the partition to extend in another way. Our VM that we capture is set to 100GB and all our destination computers have SDD drives larger than that.

I will look into updating FOG when I get some time to focus on it properly. Unfortunately for us we have difficulty updating/installing FOG through our Departments internet filtering/firewall which we don’t have full access too. I could connect it up to a direct internet connection, but that could involve a different IP address being required. I was told FOG doesn’t really like the server having it’s IP address changed, so I wasn’t sure if I should attempt to do that or not.

@Boyan-Biandov I forgot to ask in my last post, what does your partition table look like in your image that you use your script on? I see you have it set to resize partition 2.

We have 3 partitions (although the FOG partition information files lists 4 hmm) and it’s the 3rd partition that needs resizing.

Would we need to change the script to 3 or does the numbering start at 0 so 2=3rd partition?

@Boyan-Biandov thankyou for that tip! I will try that if we fail to get FOG resizing it correctly.

Do you put that in the ‘C:\Windows\Setup\Scripts\SetupComplete.cmd’ script? Your code appears to be Powershell based, so I’m guessing you must run it in a seperate script? If so, how do you call that script to run?

Thinking about it, I’m not sure it will help us as Windows is erroring during the OOBE process (due to lack of C:\ disk space we suspect) which I think would be before it even runs the SetupComplete.cmd script where we could possibly resize the partition.

I guess what we could do is not use the ‘Single Disk-Resizable’ FOG image option, and use a fixed size one instead, then your script would probably work OK and we would have enough C:\ space still for the OOBE process to run?