Error resizing GPT tables when deploying to smaller drive
-
@dhenken one way you could try is to deploy the image to a disk that accepts it, create a new image definition mimicking the original image definition with exception of the name. Don’t allow the machine you just deployed to to start into Windows. Instead create the task with shutdown enabled after task is complete. Assign the new definition to that machine and try to capture it. If you can then post the partition files again. If we have any luck the new image will work fine. At worst it captures in the same state but at least gives us a starting point at where to look.
-
OK will do. I have captured a couple images and this same error seems to happen to them all, but I don’t know that I have tried it exactly the way you describe.
Just to make sure I understand you. You want me to…
-
Deploy the image to a hard drive with enough space to accept it with it set to shutdown immediately after the image is deployed.
-
On the next boot of that machine capture the image with a different name without booting into windows.
-
Attempt to deploy that newly captured image to a smaller hard drive than the machine it was captured from.
-
-
- Yes.
- Yes.
- If you want to. I’m more interested in just the new images d1.partitions and d1.minimum.partitions files. (Also the output of the d1.fixed_size_partitions, or post that too).
-
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?
-
@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.
-
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 -
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.
-
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.
-
@dhenken Those files will be modified by the capture process so it won’t change anything. It’s information for the deployment process.
-
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
-
Tried again with
:1:2:4in the fixed.partitions file and it gave the same error as well. -
@dhenken Tried
1:2instead yet? -
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.
-
@sebastian-roth I don’t know if I’m interpretating the files incorrectly, but shouldn’t
d1.minimumpartitions
andd1.partitionsfiles 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. -
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?
-
@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.
-
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.
