GPT Partition error / Partition 4 is too big for the disk

[enzoGislard]

Hello guys,

Sorry if i post a new topic about this problem. I have seen different topics about it and i tried different solution without success. Sorry for mistake I’m a french student in internship I will try to explain as best I can.

FOG Version 1.5.7.54

If you want to help me here is the problem :

I capture a image you do 48.80 GiB, used to deploy different workstation in our network. we use 512gb nvme drives usually, but we have buy 256gb nvme drive to test.

And we are facing an error when deploying the image on these disks.

So i tried to launch a debug deploy to test different solutions, but if I’m here it’s because none of them worked.
Here all information about partitions :

I tried to create manual partition and to launch the command “sgdisk -gl /MyImages /dev/nvme0n1”. But another error appeared :

So when i see the different information i know that the problems it’s about the size of the partitions, but i have 256 Gb on my nvme drive, so why i can’t deploy my image (capture from a 512 nvme drive).

Sorry if it’s not clear (and for mistake), if you have any question. i just want to deploy my image on my PC, how i can resolvd this problem of partitions please.

Thanks.

Enzo

[Quazz]

@enzogislard This is a known problem on newer Windows 10 versions.

They put a partition (recovery I think) after the main Windows partition now, which FOG doesn’t handle that well currently. (it expects ‘data’ partitions to be last)

You can use a partition manager program to move the partitions around.

If you capture it after moving the Windows partition to the end of the disk, then it should work as expected.

[enzoGislard]

@quazz Hi, excuse me, i didn’t specify the OS I am trying to deploy its a Centos7. I’m really sorry to have forgotten to specify that.

i tried with a better shrink, but i don’t understand him telling me that partition 4 is too big when there is nothing on it.
Here the partition on my PC that i have capture (single disk - resizable).

⚡ root@yard18  ~  lsblk            
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   1.9T  0 disk 
├─nvme0n1p3 259:3    0 175.9G  0 part /
├─nvme0n1p1 259:1    0   200M  0 part /boot/efi
├─nvme0n1p4 259:4    0  31.4G  0 part [SWAP]
└─nvme0n1p2 259:2    0     3G  0 part /boot
sda           8:0    0   1.8T  0 disk 
 ⚡ root@yard18  ~  df -h
Filesystem                      Size  Used Avail Use% Mounted on
devtmpfs                         32G     0   32G   0% /dev
tmpfs                            32G  632M   31G   2% /dev/shm
tmpfs                            32G   19M   32G   1% /run
tmpfs                            32G     0   32G   0% /sys/fs/cgroup
/dev/nvme0n1p3                  174G   45G  120G  28% /
/dev/nvme0n1p2                  2.9G  173M  2.6G   7% /boot
/dev/nvme0n1p1                  200M   12M  189M   6% /boot/efi

[Quazz]

@enzogislard I think it is a similar problem here, even if Centos.

If you move the swap partition before the root partition and then capture it again (in resizable mode) it should work I reckon.

Are you capturing in resizable mode already? Other modes will fail since your source disk is much larger than target disks, even if the partitions on it are smaller than the target disks (could be mistaken about this though)

[enzoGislard]

@quazz Ok, i’ll try with this method, and yes i used “single disk - resizable”. But i have question about it. if i used the type of image why fog capture the fourth partition ? there nothing on it ?

Than for your help I come back to you once I have tried by moving the partitions.

[Quazz]

@enzogislard It doesn’t care about whether or not there is data on it, the structure gets captured and deployed.

[enzoGislard]

@quazz Ok, so fog just deploy the partition thanks to the sector, but if one sector exceeded the sector of the disk, he can’t remove the sector not used by the partition and deploy the other sector after that ?

Sorry for my questions, but this is my first time using the fog, so i like have more information about how it work (i discover this tool there are 1 month and i like it )

[Sebastian Roth]

@enzoGislard It’s exactly as described by @Quazz that FOG is not moving partitions because in the old days legacy BIOS often used fixed sector position information and would break if we move things around. There is a lot that can go wrong and so FOG still worked this way even with GPT/UEFI systems.

I am working on this and hope to get this changed for GPT/UEFI systems at some point.

[enzoGislard]

@sebastian-roth Thank you for your help, I just deployed the new image after the partition swap (I moved partition 4 before the unallocated memory) and it worked !

Good afternoon :).

[Sebastian Roth]

@enzoGislard Over the weekend I worked on this stuff and there is a first init file for testing if you are still keen to give it a try. I have only tested Windows deployment so far.

[enzoGislard]

@sebastian-roth I would be happy to give you a feedback if I have the opportunity to test your new init (I am an intern so opportunities do not arise all the time :))