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.

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.

@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?

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

@dhenken

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

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

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

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

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

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…

1. Deploy the image to a hard drive with enough space to accept it with it set to shutdown immediately after the image is deployed.

2. On the next boot of that machine capture the image with a different name without booting into windows.

3. Attempt to deploy that newly captured image to a smaller hard drive than the machine it was captured from.

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.