Failed to resize partition error Windows 8.1 SVN 4854

[Tom Elliott]

I doubt it will be fixed. I need to look a bit more to see what the problem IS, but I am almost certain updating will NOT fix the issue presented.

[Wayne Workman]

@Tom-Elliott for the record, re-sizing GPT works fine in r4848. I know this trunk version is getting old but that’s what we are using right now in production and everything works - it’s not as fast as some trunk versions, but it does work.

I’ve verified that it works this week. I’ve done a lot of testing ( a whole lot of testing ) at work to verify the features in r4848. They are legit and working fully.

This is because I’m conducting training on FOG for my peers in approximately two weeks from now. I’m going through the paces very thoroughly to make sure I don’t make a fool of myself

[Tom Elliott]

@Wayne-Workman That’s interesting. 4848 (SVN Rev 4103) didn’t have any changes from other revisions. The last time anything for the init files changed was version 4724 (SVN Rev 4041).

[Wayne Workman]

@Tom-Elliott That’s even more interesting.

But SVN Rev 4103 resizes GPT OS partitions just fine.

[jwalters]

@Tom-Elliott Still getting the same error message. We are now running SVN 4896.

[Wayne Workman]

@jwalters

So, if this is a mechanical GPT Disk and a scratch installation, FOG should not be trying to resize /dev/sda2 normally , instead, it should be trying to resize /dev/sda4

If this is a mechanical MBR disk and a scratch installation, FOG Should be trying to resize /dev/sda2 normally

Can you tell us more about the HDD in this system? Is it a SSD, mechanical, or a hybrid?
Also, has this disk every been formatted with GPT before? Because if it has, it could have GPT Structures left over on it that could cause problems. You could try to use DBAN to zero the disk and then reinstall windows on that disk and try to capture the image.

Also, is any bitlocker in the Firmware or in Windows enabled? Encryption can mess with resizing and compression as well.

[jwalters]

@Wayne-Workman The drive in this computer is a 256GB SSD. It is a GPT disk. The drive was originally formatted from the factory and has not been reformatted since.

I think we’re on to something here because as you said partition 2 of a GPT disk should not be resized under any circumstance. Partition 4 is the Windows partition and is the one that should be resized.

If I reboot the computer after the failure message and try again to upload the image it will go through as if everything is OK. Partition 4 resizes correctly and it appears to upload the image. When I restore this image to another system it is not bootable. I failed to mention this earlier but this has been happening ever since we did the first upgrade.

Is there any way to force fog to only attempt to resize partition 4?

[Wayne Workman]

@jwalters Probably… But it might be faster to format the drive, and install the OS from scratch…

I don’t know how to tell FOG to not resize a particular partition… that’s a question for the @Developers

[Wayne Workman]

@jwalters So you know, /dev/sda2 on your system you’re trying to upload from is likely a manufacturer restoration partition, and is likely set as the bootable partition.

[Tom Elliott]

If you’re not trying to resize a specific partition (while leaving others as resizeable) i think you’d be best to know your particular layout.

Resize is meant to be more or less automated in selecting the appropriate stuff and there isn’t any mechanism that I know of that will accurately fix this. At least not now.

If you know all the systems will have exactly the same as the uploading system does (or larger) you can use one of the multipart options rather than a resize.

[Wayne Workman]

@Tom-Elliott Or… obliterate the drive, and install from scratch so that it doesn’t have silly things like manufacturer restoration partitions…

[Tom Elliott]

That’d work too I suppose.