GPT Partition Tables Error

[Bullet]

I can image other systems just fine except this model now. Was working fine up until Thursday afternoon last week.

[george1421]

I guess to get a better idea if the environment.

1. What model of computer?
2. Does this happen only with this specific computer, all computers of this model, or all computers?
3. Does this target computer have a sata disk or nvme?
4. If you swap the disk in this computer does the problem remain?

[Bullet]

the system im trying to image is an HP 650 G4 Laptop win a SATA SSD. We have tried others of the same model and get the same error. Just this model is the issue right now. All other systems are imaging fine. Have not tried drive swap yet but its been fine up until that day.

Should have included FOG 1.5.6

[Sebastian Roth]

@Bullet What size is the SSD in the HP 650 G4? As well please post the contents of the text files d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions you find in /images/650G4V2 on your FOG server.

Was working fine up until Thursday afternoon last week.

That’s interesting. Did you update the FOG server or re-upload the image? You can run ls -al /images/650G4V2 to see the date of the image files. What time were they created?

[Bullet]

@Sebastian-Roth Size on the SSD is 512gb. I uploaded a new image Friday afternoon after we saw this happening. This was to get the new 1903 update uploaded for this series.

[Sebastian Roth]

@Bullet said in GPT Partition Tables Error:

This was to get the new 1903 update uploaded for this series.

I guess the partition layout has changed and is now causing the issue. Please post the contents of the files as requested.

[Bullet]

d1.partitions

label: gpt
label-id: D56B7E90-9173-4E8B-8108-B1158E43200A
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/sda1 : start= 34, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=56969ABE-33B4-47B8-9F26-01A9874DF34F
/dev/sda2 : start= 262178, size= 737280, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=6371BB01-AF20-4B0C-9CCE-C35312C9E0A9
/dev/sda3 : start= 999458, size= 958608896, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=3ACA5C86-20A8-426F-B691-BC54DAB20B31
/dev/sda4 : start= 959608354, size= 2057216, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=36F65FEC-74D6-4637-A613-1D9576A43AD1
/dev/sda5 : start= 961665570, size= 38549504, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=930F895E-7A06-4874-B197-8540A4D41BAF

d1.minimum.partitions

label: gpt
label-id: D56B7E90-9173-4E8B-8108-B1158E43200A
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215182

/dev/sda1 : start= 34, size= 262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=56969ABE-33B4-47B8-9F26-01A9874DF34F
/dev/sda2 : start= 262178, size= 737280, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=6371BB01-AF20-4B0C-9CCE-C35312C9E0A9
/dev/sda3 : start= 999458, size= 122839912, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=3ACA5C86-20A8-426F-B691-BC54DAB20B31
/dev/sda4 : start= 959608354, size= 1211246, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=36F65FEC-74D6-4637-A613-1D9576A43AD1
/dev/sda5 : start= 961665570, size= 38549504, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=930F895E-7A06-4874-B197-8540A4D41BAF

d1.fixed_size_partitions

:1:2:1:2

[Bullet]

the 650G4V2 image was how we found this out. I then uploaded the one on friday with 1903 update and we still have the same problem.

[Sebastian Roth]

@Bullet As of now FOG was never made to move partitions on the disk to make those fit on a smaller disk. On the other hand shrinking the (last) partition has worked for a very long time and has not changed much in the last months.

Taking a quick look at he figures: Partition sda5 starts a sector 961665570 and is 38549504 sectors in size. Add those two and multiply by 512 KB sector size and you get 477 GB of minimum disk size. So my first assumption the image might just be to big because of unmovable partition start locations was wrong.

Well then let’s try something else. Please schedule another deploy task but this time as debug. Boot up the client and hit ENTER twice to get to the shell. Now run the command fog to start the deploy and step through it. After you hit the same error you will be thrown back to the shell. Now manually run the following command to see exactly what’s going wrong:

sgdisk -gl /images/650G4V2/d1.mbr /dev/sda

Take a picture of the error and post here.

As well, please upload d1.mbr from your image directory to a file share and post a link here. Without that I probably won’t be able to replicate the issue.

[Bullet]

https://drive.google.com/drive/folders/11dbLMspWPDk8Ws2cGazVOL1vak7cZw7e?usp=sharing - db1 file

https://drive.google.com/open?id=1_7iOTtGfKAzAbY-zeAhBMQ-g_mVNcSjj - Image of error.

[Sebastian Roth]

@Bullet I don’t have access to my test setup over the next days. I will get back to you on this in about two weeks.

[Sebastian Roth]

@Bullet Just had a quick look at the picture. Please try again but this time schedule a normal debug deploy task!

[Bullet]

@Sebastian-Roth I thought I tried doing that but I think I am getting lost on how to do that.

[Sebastian Roth]

@Bullet Go to the FOG web UI -> task view. Cancel all the tasks here. Now go to the hosts view, select the host you want to deploy to, Basic Tasks, Deploy. Right here there is a checkbox that says Run as Debug. Check that and then click “Create Task”.

[Sebastian Roth]

@Bullet I suggest you update to the latest FOG version 1.5.7 we just released. There is a chance this might help you here.