@sebastian-roth Thanks for your reply, we will try the alpha version.

My teammate ask me to say a big thank you because since 2008 we use fog and we see you’r answer are very quick and we are very happy to use fog.

did i need to do something to indicate the post as resolved ?

@sebastian-roth I would be happy to give you a feedback if I have the opportunity to test your new init (I am an intern so opportunities do not arise all the time :))

Alrighty, so my work-arounds for this issue were to use a virtual drive of 28GB to make the original image, alternatively you can delete the 4th partition to make imaging completely compatible, but you lose the ability to do an OS reset in Windows.

If you move the partition to where it used to be in v1909, Windows can’t find it and that also loses the ability to reset, so if you have to move it, just delete it i guess…

another alternative if using clonezilla you can image and use gparted to first move the 4th partition to the end of the drive, then resize the 3rd partition, this seems to work fine without losing the option to reset, tested on 2 different machines, a Clevo Laptop and an HP All in One.

Otherwise typically just make sure the drive you are imaging to with FOG is generally larger than the source disk you imaged from and everything should be fine… generally speaking…

@brakcounty To get some more information, can you please schedule a debug deploy task (same as you would do a normal deploy task but just before you hit the last button in the web UI there is a check box for debug). Boot up the client as usual and let it boot up. Then you need to hit ENTER twice to get to the shell. Now type fog and ENTER again to start and step through all the process till you hit the error. It will throw you back to the shell. Now type:

sgdisk -gl /images/Win10Standard_GPT_EFI/d1.mbr /dev/sda

It surely will fail. Take a picture of the screen and post that here.

@phm2000 said in Error trying to restore GPT partition tables:

I have same problem with fog 1.5.7, is there a solution ?

Sorry but with this kind of problem there is no general solution that works for everyone. Please open your own topic in the forums and post all your own details: full contents of the file d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions.

Hey @Tom-Elliott

I confirm that now everything works correctly. The error message was on one of the 2 partitions on the hard drive was too full. I will refine the settings and make you a return on the minimum size of available space to deploy.

I confirm that I capture and deploy on the same machine and therefore even hard drive. So no space problem available.

We can pass the inviter in resolve
As soon as I have the information on minimum available space I will add them in this topic

@+

@Sebastian-Roth @Tom-Elliott
After an update to the current subverion it’s working again. Thanks.

fixparts /dev/sda worked for me.
thanks