GPT Partition Table Error when trying to apply image

[TBCS]

My fog installation recently broke and I had to move everything to a brand new installation. I had another ticket on here but nothing I tried worked so I had to totally reinstall. After that I imaged 300 odd machines of varying models but all with the same image. It worked great, but 2 other images I’ve tried to use this morning have given me GPT Partition errors.

Here’s the error I get with the debug menu

And here is the text of the d1.partitions of the offending image

label: gpt
label-id: 52125BB2-B685-4664-9E80-D66B4B9964E3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=56BBB14C-0960-4D45-8143-27E070F6BF28, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=9FAFAB3C-9C1B-400D-B2D6-B93C42D9D20B, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=   248791157, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=BEC960CC-44EA-45FD-91DC-566179E190BC, name="Basic data partition"
/dev/nvme0n1p4 : start=   249032704, size=     1034240, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=9EEF9D5F-4665-4DAA-978A-D1E793FE25B6, attrs="RequiredPartition GUID:63"

The working image says dev/sda instead of nvme, would changing that in this file fix the issue? I don’t know why it would say nvme

[george1421]

While I don’t have solid evidence of this, but I think that with Windows 2004 the disk structure was changed where that 4 partition (recovery partition) is causing us troubles.

Let see if we can test this idea. Give me a minute.

Will you give me the output of this file cat d1.fixed_size_partitions

Oh and I see you have an nvme captured image and you are deploying to a sata disk. Is the sata disk larget or smaller in size than the nvme disk?

[george1421]

@TBCS said in GPT Partition Table Error when trying to apply image:

The working image says dev/sda instead of nvme, would changing that in this file fix the issue? I don’t know why it would say nvme

This file would have been captured from a computer with an nvme disk.

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