Error resizing GPT tables when deploying to smaller drive

[dhenken]

@tom-elliott

Got in this morning and the newly captured image gave the same error when deploying to a smaller drive as my original post. The D1.Partitions and D1.Minimum.Partitions files are once again exactly the same.

I am now re-running a capture with shutdown again after modifying the d1.fixed.partitions filed to read “:1:2:4”. I did not create a brand new image, simply modified the d1.fixed.partitions file in the existing image folder and scheduled a new capture with shutdown.

The capture takes a long time off these spinning drives. I will report back in when I test trying to deploy this again.

[Quazz]

@dhenken Those files will be modified by the capture process so it won’t change anything. It’s information for the deployment process.

[dhenken]

Ok.

Re-captured the image following the instructions from yesterday.

The D1.Partitions, D1.Fixed.Partitions, and D1.Minimum.Paritions still look exactly the same. I have uploaded them so they can be examined.

Still same error message from the original post when trying to deploy.

2_1525447495447_d1.partitions.txt 1_1525447495447_d1.minimum.partitions.txt 0_1525447495446_d1.fixed_size_partitions.txt

[dhenken]

@dhenken

Tried again with :1:2:4 in the fixed.partitions file and it gave the same error as well.

[Sebastian Roth]

@dhenken Tried 1:2 instead yet?

[dhenken]

@sebastian-roth

Yes.

The file was originally :1:2 . I was trying to add the :4 to see if that would get it to work. I have a 60GB SSD arriving today. As a workaround I am going to pull the image off a drive so small that I will never be deploying to a smaller drive.

But so far no luck on the original issue.

[Quazz]

@sebastian-roth I don’t know if I’m interpretating the files incorrectly, but shouldn’t d1.minimumpartitions
and d1.partitions files be different under resizable in terms of size for the partitions? It looks like it noted the same size in both scenarios for the Data partitions, so the problem seems to be that during capture the system thinks it can’t resize it.

[dhenken]

@quazz

Yeah I think that sums it up pretty well. There is no difference between my d1.partitions and d1.minimum partitions files. This causes a scenario where I can only deploy to a equal or larger size drive.

To my knowledge there is nothing unusual about these machines that would be causing this to occur. The image was pulled from a Dell Optiplex 5050 with the latest firmware. I also pulled an image from an Optiplex 9020 to rule out a model issue and got the same error.

These machines do use Faronics Deep Freeze. I am not sure if possibly deep freeze is doing something to the partitions to make them non-resizable?

[Quazz]

@dhenken Only one way to figure out. Uninstall Deep Freeze and see if that changes the situation after capture.

There’s a good chance that’s what’s blocking though.

[dhenken]

Turns out the error was related to DeepFreeze. A program that we use to prevent users from making changes to the public use computers in our Library.

The issue was resolved by opening the DeepFreeze console on the machine I was capturing from and clicking the button “Set Clone Flag”. This prepares the system for imaging and allows the hard disk partitions to be resized. After doing this step our deployments have all gone smoothly.

Thank you for all the help. Even though my issue was not FOG related. Hopefully our troubleshooting can help someone else down the road.