1.4.2 Unallocated space after deployment
nrg last edited by nrg
- FOG Version: 1.4.2 SVN 6074
- OS: Ubuntu 14.04 LTS
- Service Version: 0.11.12
- OS: win10 enterprise build 1703
Image created on a 120GB SSD, syspreped, setupcomplete command, and has no unallocated space on the image.
When the image is deployed to a client computer with 128GB SSD hard drive, there seem to be a random 38MB unallocated space. I did not notice this until I used the same image on a 1TB SSD computer. It showed a random 6GB of unallocated space. So there must be a bug where it’s not imaging and resizing 100% of the drive.
I did find this issue on most of my client computers. I’m manually extending the hard disk to get rid of the unallocated space. I did not see this issue before going to 1.4.2 on my other images.
i always make my image on 120gb ssd because I have multiple computers with 128gb and 256gb ssd.
The image is set to
ImageType ID: 1 Name: Single Disk - Resizable
partition everything. compression 6
nrg last edited by
Thank you Tom for the explanation. I will redo the image on a 128gb ssd from now on with my setup. consider this solved
The math is trying to set the size based on math from the originating disk vs the nee disk size. There will always be some variance. In the past this didn’t seem to be an issue but this was because there were major issues in how the resizing was happening to begin with. By “not seeing this is the past” I presume you mean from fog versions before 1.3.5? I say this because the code was fairly heavily modified to work more properly from 1.3.5-rc-10 with minor adjustments made in 1.4.0-rc-1. for 1.4.0-rc-1 the adjustments were made to ensure a block size of 512 was being used to ensure alignment of sectors. It’s this alignment that I suspect you’re seeing as the “unallocated” space. This is most likely due to you disk being 4k but aligned to the nearest 512 sector. I don’t consider this a problem because trying to get things to expand beyond a certain point should be handled as needed by the admins. 6gb extra space isn’t too hard or too much in the larger scheme. 1tb less 6gb is still 994gb usable space. It also leaves some room for buffer which is not a bad thing I don’t think.
It may be that the resizing math is off a little. That might be accidental or on purpose. If the partition is undersized, things work. If FOG tries to oversize it, the process fails. This is the file that does all that: https://github.com/FOGProject/fogproject/blob/15f4251be29ad0abf37addffeac5a65913d3df88/src/buildroot/package/fog/scripts/usr/share/fog/lib/partition-funcs.sh