FOG Not resizing partitions
-
@Tom-Elliott I think I had that in my previous post? However I’ll post it here again for you, I assume this is what you are after? To me it looks like it shouldn’t have the ‘:2’ in it however I’m not sure how to fix that?
administrator@NHS-FOG-01:/images$ cat /images/ADOBEIMAGEWIN7/d1.fixed_size_partitions :1:2
-
@Derek-Newbold Sorry for not getting back any earlier. As I see it the issue is that with the new version of FOG (at least in your case, don’t think this applies to everyone!) does see both partitions (sda1 and sda2) as fixed size. So surely it won’t deploy to a smaller disk and neither would it expand on a bigger disk. So if you change
d1.fixed_size_partitions
by Hand and just make it read1
(no space or colon or anything else in that one line) then I am pretty sure it will work as expected.Now why doesn’t it generate
d1.fixed_size_partitions
properly? The only thing I can think of is you are seeing this message when capturing:New fixed partition for (/dev/sda2) added.
. This is because this partition is labeled asRECOVERY
orRESERVED
for an unknown reason. Please check in the windows disk management tool. Usually those labels not used for the C:\ (system) partition and we use those to detect so called “boot” or “recovery” partitions. -
@Sebastian-Roth To add on, I think removing the 2 from the file will certainly help (at least in getting to to expand to larger disks).
-
@derek-newbold This likely has nothing to do with the issues you’re having, but you might want to consider this workflow instead:
You have a base guest VM that you build out with everything you want it to have, then once you have it where you like it, you create a snapshot.
Anytime you need to capture this guest VM, you first create a clone of it. Then you finish up whatever else you need to do to the cloned VM before sysprep’ing and capturing it.
Anytime you need to add/change something in the base VM, you do so, then verify if everything is still good with the base. If so, you delete the snapshot to permanently commit the changes, then create a new snapshot.
-
Hi Sebastian,
Thankyou for your reply. This makes sense to me, I have checked the partitions and the ‘C:’ partition has the label ‘Boot’ so I assume that is why it is being detected as not resizable (see screenshot below). Would it be advisable to try and change the boot partition to be on the ‘System Reserved’ partition instead if possible? Or just continue with the manual fix that you mentioned?
Also I tried manually changing ‘d1.fixed_size_partitions’ to just have ‘1’ and then reimaged a host, this time it tried to resize the ‘sda2’ partition however it failed and came up with ‘Cluster accounting failed’ errors and that ‘NTFS is inconsistent. Run chkdsk /f’. Do you have any advice on what might cause this and how I can stop it from happening? Again, I had no problems with the old version of FOG doing the same processes so I’m unsure what is causing these issues.
Thankyou again,
Derek
-
@Derek-Newbold Please read through this https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit and make sure you to a proper filesystem scan in windows (jst as the message suggested). Then capture the image again and try deploying it!
-
Then you might want to get on 1.4.4 and try again. I suggest this as there was a bug in init’s moving the start position of the next partition improperly. 1.4.4, we believe, fixed this.
-
@derek-newbold What’s interesting, to me however, is your partclone shows SDA2 as being 23.4GB partition, but the windows image shows the drive as being a 100mb reserved partition. Is the partition 2 in the d1.fixed_size_partitions file.
-
@tom-elliott said in FOG Not resizing partitions:
What’s interesting, to me however, is your partclone shows SDA2 as being 23.4GB partition, but the windows image shows the drive as being a 100mb reserved partition. Is the partition 2 in the d1.fixed_size_partitions file.
Windows disk management does not show the partitions in order in that list (which is super stupid I find)…
-
@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!