Error trying to restore GPT partition tables on multiple Dell machines

[vanopy]

Dear,

I’m very new to FOG imaging, so probably something went wrong on my side, but I can’t seem to figure out what exactly. I’ve already been troubleshooting for quite some time before opening this ticket.

I’ve captured a new Windows10 Pro image (by following all the steps here: https://www.theitcave.com/post/561).
I managed to get it working yesterday and deployed it to another type of Dell, but since that was the 1st image and I forgot quite some things, I decided to remove that one and create another one, which is what I tried today.

I’m able to capture the image, but I can’t deploy it anymore, whatever I try, tried adjusting quite some settings in the BIOS and adjusting several settings for the image, nothing seems to help, I keep getting the following error message:

Any idea what I’m doing wrong and how I can get to deploying again?
Please let me know if you would need more information.
Thanks for looking into this!

[george1421]

What version of FOG are you using as well as what version of the FOS kernels (bzImage) are you running?

[Sebastian Roth]

@vanopy Please try this: Cancel that deploy task and create a new one for this same machine but tick the checkbox for debug just before you hit the schedule button in the web UI. Then boot up the client, hit ENTER twice and you will find yourself on a command shell. Type fog and hit ENTER again to start. Now step through the things (ENTER … again) till you hit the error. Now you will get back to the shell. Type sgdisk -gl /images/winv10.3/d1.mbr /dev/nvme0n1 which will error out again. Take a picture of the error message and post here.

[vanopy]

Dear,

I’m using FOG 1.5.5 with bzImage version 4.19.1
The detailed error I’m getting is the following:

Any idea what went wrong and how I can fix this?
Thanks for your help.

[jmason]

If the laptops have more than one hard drive and they are newer dells, it could be related if not the same issue regarding nvme drive initialization order as you will find in my post started a few weeks ago:

https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message.

It is an interesting read.

[Sebastian Roth]

@vanopy Are you sure you captured the image as resizable?

[vanopy]

@Sebastian-Roth Yes, 100%

[george1421]

@vanopy Will you do this for us? On your golden (source system). Schedule a capture/deploy again, but before you schedule the task, check the debug checkbox. Then pxe boot the computer. After a few enter key presses you should be dropped to a linux (FOS) command prompt. At the FOS command prompt key in lsblk and post the results here. Do the same on this target computer that is giving this disk size issue. Post both results here so we can see the disk geometry.

[vanopy]

@george1421 Of course

This is from my captured machine:

This is from my machine I’m trying to deploy:

[george1421]

@vanopy Excellent there are two things that jump out at me.

1. You are going from an nvme disk to a SATA attached disk.
2. The target computer hard drive is slightly smaller than the source disk.

Understand this is not an indication of error, only an observation.

Ok now on your fog server. Login to the linux console then navigate to /images/winv10.3 directory. (Hint: if you use putty (free app) you can copy and paste without pictures if that is easier).

Key in the following:

1. cat d1.partitions
2. cat d1.fixed_size_partitions
3. cat d1.minimum.partitions
4. ls -la

These commands describe the image as it exists on the fog server.

[vanopy]

@george1421 OK, done:

[vanopy]

@george1421 Do you need screenshots from all the commands I’ve entered? Or is there anything you want me to show you specifically?

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

1. Does size matter?
2. 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.