Error resizing GPT tables when deploying to smaller drive

[dhenken]

Deploying to a larger drive right now.

What is weird to me is that based on this screenshot taken while restoring /dev/sda3 it clearly understands that the partition is only 51.2GB. If it was unable to resize the image wouldn’t it show 250GB at this point since that is whats in the d1.partitions file and the minimum size file is identical?

[Tom Elliott]

@dhenken partclone only captures used blocks. That would show the same with or without resizing. If it didn’t understand the file system you would see the whole size.

[Tom Elliott]

Further clarification. The size of device is whatever it was when it was originally shrunk. So you’re correct there. Though I still suspect fix partitions playing somewhat of a role here. If I had to guess you fixed file is :1:2:4

[dhenken]

@tom-elliott

Just started capturing the new image after deploying the broken one to a larger drive.

I am feeling optimistic about this one. I saw that before the capture started text was displayed that indicated it was skipping resizing sda1 and sda2. It then did a resize test on SDA3 and it was successful. I don’t think I saw this before which leads me to think it was seeing all disks as fixed.

I might not be able to report back the results until tomorrow since capturing an image off this spinning disk might take a while.

Thank you for all the effort on helping me with this. I will report back when it is complete.

[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.