GPT Partition Table Error when trying to apply image

[TBCS]

The output of that file is

:1:2

The sata disk is slightly smaller (120GB vs 128GB)

[george1421]

@TBCS Is this source image windows 10 v2004?

In the first picture you were in debug mode, are you still in debug mode on the FOS Linux console?

[TBCS]

@george1421 the source is windows 10 2004, and yes I still have the FOG debug mode computer open in the same state I took the picture in. The image that works is also Win10 2004

[george1421]

@TBCS in the FOS linux debug console key in the following (assuming your disk is /dev/sda) fixparts /dev/sda That will reset the gpt table.

Then key in fog to restart debug imaging. If it fails again then we need to get a bit hacky.

[TBCS]

@george1421 I get this error I’m sorry I’m not familiar enough with linux to know the equivalent fdisk command

[george1421]

@TBCS Yeah I also told you the wrong command lets try gdisk /dev/sda if it drops you to a command prompt inside gdisk just key in w and then e to exit.
\

[TBCS]

@george1421 The command was successful but I still get the same error

[TBCS]

@george1421 Is there any way that I can remove that partition now after the capture has already happened? This image definitely used to work, and the other 2004 image works. Is it related to disk size? If I capture from a specifically small disk will this not be an issue?

[george1421]

@TBCS

But I really think the problem is that recovery partition with the 2004 based images. MS is doing something with them to lock its position on the disk. That is why the resize to a smaller disk is not working. My recommendation if you are using FOG for imaging and don’t need the recovery partition just remove it from your source / master /golden image. Then single disk resizable will work as it should.

This is the hacky part I mentioned. In the d1.partitions file. Make a backup of that file,call it d1.partitions.save or something. Then in the d1.partitions file delete that last line that mentions partition 4. Save the file and restart the deployment again. Lets see if that is enough to fool the installer to link there is only 3 partitions.

[TBCS]

@george1421 I’d love it if that worked I’ll try it now

[george1421]

@TBCS If that doesn’t work make backups of the other d1.xxxx files and then remove the references to that 4th partition. Since its at the end of the disk we can (hopefully) tell FOG to forget about it and pretend that it didn’t get captured.

[TBCS]

@george1421 You’re always there when I need you, you’re doing the Lord’s work. In the future I’ll have to be sure to capture Win 10 2004 images on the smallest possible drive I’ll ever use and/or delete the recovery partition before capturing. Seems to be applying perfectly fine (one of the files wasn’t plaintext though so I had to hope and pray a bit with that one)

[george1421]

@TBCS yes the d1.mbr is binary. Did you find you needed to fix all of them for the image to deploy correctly?

[TBCS]

@george1421 Yes all of these files aside from the .img files (I guess I could delete the 4th one) although the swapuuids I think was blank. And for d1.mbr it took a bit of guessing but there was some plaintext. I tried all but d1.mbr initially but that wasn’t enough.

[george1421]

@TBCS ok good to know thanks.