Error trying to restore GPT partition tables on multiple Dell machines

george1421

@vanopy We will need a screen shot of the first two commands since they scrolled off the screen in the picture.

vanopy

@george1421 Copied all the commands via Putty as you first recommended:

[root@BGImage ~]# cd /images/winv10.3
[root@BGImage winv10.3]# cat d1.partitions

label: gpt
label-id: 2B93DFE7-2C81-4C8A-9000-BEF1E8E64AA3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=1257976B-8CEF-4391-8FD8-815CAC3B26B6, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=D1113659-47AF-43F3-9E7A-BC08C44268CE, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=   996288512, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE33BD1E-F4CA-4E1A-91E7-FECA59FA53CA, name="Basic data partition"
/dev/nvme0n1p4 : start=   996528128, size=     3665920, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=295314FF-104B-45AB-A1F1-5CBFDC52CBB8, name="Basic data partition", attrs="RequiredPartition GUID:63"

[root@BGImage winv10.3]# cat d1.fixed_size_partitions

:1:2:4

[root@BGImage winv10.3]# cat d1.minimum.partitions

label: gpt
label-id: 2B93DFE7-2C81-4C8A-9000-BEF1E8E64AA3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=1257976B-8CEF-4391-8FD8-815CAC3B26B6, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=D1113659-47AF-43F3-9E7A-BC08C44268CE, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    59116948, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE33BD1E-F4CA-4E1A-91E7-FECA59FA53CA, name="Basic data partition"
/dev/nvme0n1p4 : start=   996528128, size=     3665920, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=295314FF-104B-45AB-A1F1-5CBFDC52CBB8, name="Basic data partition", attrs="RequiredPartition GUID:63"

[root@BGImage winv10.3]# ls -la

total 13025224
drwxrwxrwx  2 root root         247 Feb 28 15:13 .
drwxrwxrwx. 5 fog  root          77 Feb 28 16:53 ..
-rwxrwxrwx  1 root root           7 Feb 28 15:04 d1.fixed_size_partitions
-rwxrwxrwx  1 root root     1048576 Feb 28 15:04 d1.mbr
-rwxrwxrwx  1 root root         886 Feb 28 15:04 d1.minimum.partitions
-rwxrwxrwx  1 root root          20 Feb 28 15:04 d1.original.fstypes
-rwxrwxrwx  1 root root           0 Feb 28 15:04 d1.original.swapuuids
-rwxrwxrwx  1 root root         302 Feb 28 15:04 d1.original.uuids
-rwxrwxrwx  1 root root    13051888 Feb 28 15:05 d1p1.img
-rwxrwxrwx  1 root root    16912752 Feb 28 15:05 d1p2.img
-rwxrwxrwx  1 root root 12698745465 Feb 28 15:13 d1p3.img
-rwxrwxrwx  1 root root   608040382 Feb 28 15:13 d1p4.img
-rwxrwxrwx  1 root root         886 Feb 28 15:04 d1.partitions

MOD Edited to put into code blocks for easier visibility.

george1421

@vanopy I think we are at a point where we need an @Developers to look at what we’ve collected so far. I suspect I know what the problem is, but I’m wondering if you can test the idea out. I need you to try to find a computer that you can deploy this image to, but the target hard drive needs to be bigger than 477GB (your source disk). Since this is just a disposable test, if you have a spare 800GB or 1TiB hard drive handy, see if you can deploy to it.

I want to test 2 things:

Does size matter?
Is the disk architecture change impacting imaging?

Tom Elliott

I know I seem distant and all these days, but this really sounds like a 4K advanced disk problem.

What makes me say this?

The nvme was a 512gb disk, I assume and it’s just a guesstimate. The sata disk is also a 512gb disk, guesstimate.

But look at the layout variances in reported disk size. One shows as about 465GB (sda) while the nvme shows at 477GB (nvme).

The oversized for each partition would seem, too me, to come from calculating disk sectors at a larger size than the actual disk can use.

I very well could be wrong of course and welcome any suggestions.

@sebastian-Roth I think we need to try figuring out a suitable mechanism to upscale to 4K only (less needed as most advanced disks will allow reappropiation of the sectors into 512B) as well as downscale 4K back to 512B. I don’t know of a good approach to do such a thing yet but it seems more and more people are looking to image cross spectrum.

vanopy

@Tom-Elliott Some more info, just opened the laptop I wanted to deploy to see exactly which disk is inside, it’s a 500 GB SATA Disk. I don’t think I have any larger disks laying around to test with.

I’ve also tried to deploy the image on a newer model, which also has an nvme disk, but this was giving the same outcome and error message, like in my original post.

vanopy

@Tom-Elliott Could it be an idea, that I create a completely new golden image, but this time on the Sata disk? And try to get those deployed to my Sata and nvme disks? Just thinking out loud, will take me some time though.

Tom Elliott

@vanopy That could work, yes.

Though looking over the files you provided the information appears to be saying the SSD (nvme) is using 512B sectors, so my 4k idea is out the window then. (I wasn’t at a computer when I wrote what I did so didn’t have simple access to view the information and test my thoughts.)

vanopy

@Tom-Elliott Ok, I’ll start making my master image on the Sata disk and will let you know the outcome, will probably be on Monday since I’ll be leaving work in 1 hour. Thanks already.

Tom Elliott

@vanopy I think there’s a potential for us to be able to fix this even as is, but it would take a bit of thought first.

I wonder if it’s reverse of what I’m thinking?

Here’s why:

partition 1 = 204800 x 512 = 104,857,600 (100M)
partition 2 = 32768 x 512 = 16,777,216 (16M)
partition 3 = 996288412 x 512 = 510,099,718,144 (475.1G)
partition 4 = 3665920 x 512 = 1,510,359,040 (1.4G) (approximately obviously your screen shows slightly different.)

Now put to to a 4k only drive:

partition 1 = 204800 x 4096 = 838,860,800 (800M)
partition 2 = 32768 x 4096 = 134,217,728 (128M)
partition 3 = 996288412 x 4096 = 4,080,797,335,552 (3.7T) (Yes Terabytes)
partition 4 = 3665920 x 4096 = 15,015,608,320 (14G)

Hopefully this makes sense, and I’m only guessing based on the information.

Sebastian Roth

@vanopy said in Error trying to restore GPT partition tables on multiple Dell machines:

root@BGImage winv10.3]# cat d1.fixed_size_partitions
:1:2:4

While it could be a 512/4k block size issue as @Tom-Elliott mentioned I see another problem here, a very obvious one. See above, partitions 1, 2 and 4 are marked as fixed (for whatever reason). This prevents from deploying to a disk being just a little smaller…

vanopy

@Sebastian-Roth Ok, thanks for having a look. I don’t really have an idea why these partitions are fixed.
Is there an easy way for me to undo this, so I could try to capture/deploy this image again?

Tom Elliott

@Sebastian-Roth I would agree here too. Maybe we can modify part 4 to become part 3?

Changing the file names so d1p4 = d1p3, and d1p3 = d1p4.

mv /images/winv10.3/d1p{4,tmp}.img
mv /images/winv10.3/d1p{3,4}.img
mv /images/winv10.3/d1p{tmp,3}.img

Then Adjusting the partitions files:

d1.partitions:

label: gpt
label-id: 2B93DFE7-2C81-4C8A-9000-BEF1E8E64AA3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=1257976B-8CEF-4391-8FD8-815CAC3B26B6, name=“EFI system partition”, attrs=“GUID:63”
/dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=D1113659-47AF-43F3-9E7A-BC08C44268CE, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/nvme0n1p3 : start= 239616, size= 3665920, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=295314FF-104B-45AB-A1F1-5CBFDC52CBB8, name=“Basic data partition”, attrs=“RequiredPartition GUID:63”
/dev/nvme0n1p4 : start= 3905536, size= 996288512, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE33BD1E-F4CA-4E1A-91E7-FECA59FA53CA, name=“Basic data partition”

d1.minimum.partitions to:

label: gpt
label-id: 2B93DFE7-2C81-4C8A-9000-BEF1E8E64AA3
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/nvme0n1p1 : start= 2048, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=1257976B-8CEF-4391-8FD8-815CAC3B26B6, name=“EFI system partition”, attrs=“GUID:63”
/dev/nvme0n1p2 : start= 206848, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=D1113659-47AF-43F3-9E7A-BC08C44268CE, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/nvme0n1p3 : start= 239616, size= 3665920, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=295314FF-104B-45AB-A1F1-5CBFDC52CBB8, name=“Basic data partition”, attrs=“RequiredPartition GUID:63”
/dev/nvme0n1p4 : start= 3905536, size= 59116948, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EE33BD1E-F4CA-4E1A-91E7-FECA59FA53CA, name=“Basic data partition”

And finally d1.fixed_size_partitions to:

:1:2:3

vanopy

@Tom-Elliott @Sebastian-Roth Really appreciate the help. Just let me know if you want me to make any change or if you want to test anything.

Tom Elliott

@vanopy Would you be willing to try the things I suggested? I might suggest creating a backup of the current image just so you have the original ready to go.

If you need help just let us know and I’m sure we can help.

I’m not sure if this would work, but theoretically it would as it would place your data partition at the end of the disk and in line based on the sizes used.

vanopy

@Tom-Elliott Just made the changes as requested, but I’m still getting the same GPT error when trying to deploy unfortunately. Any other ideas/suggestions?

Tom Elliott

@vanopy I imagine the GPT Error is due to the d1.mbr file. We may have to manually run the process to get the image to push onto the machine.

Can you redo the tasking into a debug mode again? (Goto create new tasking and just before confirming there will be a checkbox to “Schedule as debug”. Check this box)

Then boot the machine you want to deploy too.

My editing of the files doesn’t change the MBR file which I believe is where you’re seeing the error.\

@Sebastian-Roth Theoretically, at least for the case of GPT, we shouldn’t need to apply the MBR file in order to build the partition data, correct? I know we’ve talked about this in the past and I really don’t know what we need the MBR for when we have the exact partition layout information in the d1.partitions and d1.minimum.partitions files. I’d think we could apply the minimum and do our adjustment calculations based of the new table.

I’m sure there’s a reason we’ve kept mbr applying though I can’t see why at the moment.

vanopy

@Tom-Elliott I’m out of the office now. Will be able to test again on Tuesday and will let you know the outcome

vanopy

This post is deleted!

vanopy

@Tom-Elliott @Sebastian-Roth Getting the following error when I ran through debug mode again:

fog debug sda.jpg

Tom Elliott

@vanopy I might suggest clearing all partition tables using sgdisk -Z /dev/sda

Then try:
(using the d1.minimum.partitions as I requested to be modified.)
sfdisk /dev/sda < /images/winv10.3/d1.minimum.partitions

From there can you get us the screenshot?

Error trying to restore GPT partition tables on multiple Dell machines

160

11.6k

17.1k

154.6k