Error resizing GPT tables when deploying to smaller drive
-
I have captured an image from a Windows 10 computer. The image has been Sysprepped and Generalized before being captured. When I attempt to deploy this image to a equal or larger size target disk the process completes successfully. However, when I attempt to deploy to a smaller size disk I get the following error.
I have tried following the suggestions in other posts of modifying the d1.fixed_size_partitions file.
The image type is “Single Disk Resize-able”
Any ideas on what I can do to allow this to work?
-
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.
-
What language is the Windows install in the image?
How much space was in use on the partitions and how big is the targe drive?
-
54GB is the total size of the image I am trying to deploy.
English as far as I know. However I do always notice French listed when booting the OOBE image.
I am trying to deploy to a 160GB SSD when getting the error.
If I try to deploy the same image to a larger drive (for example) 250GB it complete successfully. When the system powers on the used space is 54GB.
-
Here is a screenshot of the entire image folder for the image I am trying to deploy so you can see the size on my FOG server.
-
@dhenken The images on the FOG server are of course compressed, so it doesn’t necessarily translate to its deployed size.
Inside that folder there are some text files, if you could post their contents here, that could illuminate the situation.
-
Attached .txt copies of d1.paritions and d1.minimum.partitions
1_1525364923076_d1.partitions.txt 0_1525364923075_d1.minimum.partitions.txt
-
@dhenken what version of fog are you using?
-
-
If I am reading the man page of SGDISK correctly.
The “-gl” flag indicates that is attempting to convert an MBR disk to GPT and the error code 4 means it has encountered an error trying to save the changes.
Is this normal behavior to run the -g flag? As far as I know the disk that I pulled the image from was a GPT disk.
-
@dhenken This should be fine, as indicated by working to deploy to a larger disk. If I had to guess, your d1.partitions and d1.minimum.partitions files are not much different, so the percentage it can change things is not changing. However, going to a larger or equal size drive things work fine. Again this is all speculatory, I haven’t looked deeply at the files you provided yet.
-
I can confirm that my D1.Partitions and D1.Minimum.Partitions are exactly the same.
What could be causing it to not enter the correct values in d1.minimum.partitions?
-
@dhenken when did you originally capture the image? This can happen for many different reasons, most often I see it I’d say you go to capture, it shrinks the partition, but before it actually completes the task it gets rebooted and the capture cycle happens again. Because of the second go around, the drive is already in its shrunken state so both files look identical. Another reason this could happen is if all the partitions are set as a fixed size. Even though the image is defined as resizable, if the partitions get marked as fixed size, both files would be identical as nothing changed between the two. Can you provide the d1.fixed_size_partitions file here?
-
Thanks for the reply Tom. I appreciate all the effort.
I don’t have access to the box at the moment but I am 100% sure that the d1.fixed_size_partitions file contains 1 line that is “:1:2” (without the quotes).
I captured the image about a week ago it is a fairly recent image.
-
@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.
