Error trying to restore GPT partition tables on multiple Dell machines
-
@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.
-
@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.)
-
@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.
-
@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.
-
@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:4While 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…
-
@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? -
@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
-
@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.
-
@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.
-
@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?
-
@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.
-
@Tom-Elliott I’m out of the office now. Will be able to test again on Tuesday and will let you know the outcome
-
This post is deleted! -
@Tom-Elliott @Sebastian-Roth Getting the following error when I ran through debug mode again:
-
@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?
-
@Tom-Elliott Ok, so this is what I’ve done and got:
Want me to try to deploy again now?
-
@vanopy don’t try to deploy yet as it will still error out the same way.
What’s output when you run:
partprobe /dev/sda; fdisk -l /dev/sda
-
@Tom-Elliott This is the output I’m getting:
-
@vanopy Is this what your d1.minimum.partitions file looks like?
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"
-
@Tom-Elliott I believe so, this is how it looks: