Failed to resize partition error Windows 8.1 SVN 4854

[jwalters]

Ever since we upgraded from SVN 3488 to 4854 we have been unable to successfully upload or restore a Windows 8.1 image. The computer is an HP Elitebook Revolve G3 with a 256GB SSD (if that matters…). I have tried everything that I can think of but I can’t come up with a solution. I am doing a chkdsk and a full actual shutdown prior to attempting to upload the image. This is the same process I always used when using SVN 3488 and it worked perfectly. I have other Windows 7 images on this server that work perfectly.

Here are the settings that I’m using for the image: I need to keep the image type resizable because we also have a few 128GB models of this laptop around.

This is the error that I’m getting when I try to upload the image to the FOG server:

Any help would be greatly appreciated.

[Wayne Workman]

Can you look at the “general settings” of the host you uploaded from before?

Many times with newer tablets (not sure if this is a tablet), specifics need entered for kernel arguments and host primary disk arguments.

Also - if you can do a debug upload and then list the devices you see in /dev that would help too.

[Sebastian Roth]

Are you sure it’s the exact same install you trying to upload from? Maybe it had MBR style partitions in the old days but is GPT now? Just a wild guess.

[jwalters]

I just checked the old server and there were no Kernel or Disk arguments entered. I don’t have a clue where to begin for figuring out whether arguments are needed. This device is a laptop with a touchscreen.

[Wayne Workman]

re-update to the latest. there was a minor upload bug recently that has since been fixed.

Try again and let us know what happens.

[jwalters]

@Wayne-Workman Thank you. I will have our server updated and report back once that is finished. Thanks

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