Partition size too little with a "Single Disk - Resizable" image - svn 3537

[g.chanaud]

Hi,

I’ve changed an image from fixed size to the “Single Disk - Resizable” type and selected “All Partitions”.
I’ve uploaded correctly the image from a correct computer to reflect those changes, everything seems fine.

when i want to deploy i got the error of a “too little partition” for /dev/sda1…

So let’s check what should be done and what is done :
-I delete every partitions on the disk to have a clear partition table.
-I run the fog script (i’m in a download/debug task mode) to get the job done
-I wait for the error to appears
-I run a fdisk /dev/sda and print the partition table (the one just created by fog)

Device      Boot     Start          End          Sectors       Size         Id       Type
/dev/sda1               63        79934            79872        39M         de       Dell Utility
/dev/sda2   *        79935     32933950         32854016      15.7G          7       HPFS/NTFS/exFAT
/dev/sda3         32933951    976772158        943838208     450.1G          7       HPFS/NTFS/exFAT

/dev/sda1 is 39M but i need 42M !
Let’s see what’s inside d1.minimum.partitions (d1.original.partitions is exactly the same) in the image folder

/dev/sda1   :    start=        63,      size=              80262,           type=de
/dev/sda2   :    start=     81920,      size=           32854016,           type=7,      bootable
/dev/sda3   :    start=  32935936,      size=          943835136,           type=7

Those values are exactly the same as the real partitions sizes from the original disk.

So the d1.minimum.partitions is not applied correctly while creating the partition scheme during deployment.
The sda1 partition is too small, the sda2 is correct and the sda3 has been correctly expanded with the bytes freed by the bad sized sda1…
Any idea how to fix this ?

Thanks,
Guillaume

SVN trunk rev 3537

[Tom Elliott]

What version did you upload the original image from?

[g.chanaud]

My bad : It was at REV 3443 and it has have been fixed between those two versions ?
As the d1.minimum.partitions was fine (generated by the upload task) i thought that it was only the download task which was buggy and so updating to latest rev would fix the download/create partition scheme part.

[Tom Elliott]

It’s the upload tasks that create the d1.minimum.partitions and d1.original.partitions in the first place.

I found that there was a problem but was able to fix it. I forget exactly which revision.

https://news.fogproject.org/resize-bugs-abound/

That’s the posting. Looks like I finally figured it all out at 3487. While the partitions were resized, the d1.mbr file was not, thus making it pretty rough to correct autonomously.

Hopefully you’re not too far hindered. Just download the system to a disk that has the proper or larger size as the original, and re-upload as resizable and all should work fine.

[g.chanaud]

Hi Tom,

i deleted all files in my image directory for this particular image.
I reuploaded from the “good” computer a brand new image (so it’s an upload with the svn 3537 rev).
I’m hitting the same problem when downloading the resizable image to another computer (which is exactly the same model : a Dell3020).

partition sda1 is not created with the correct size even if the d1.minimum.partitions is correct.

Thanks,
Guillaume

[g.chanaud]

Hi Tom,

i continue to hit the same problem even with upload/download made on the latest revision. My sda1 always lack 4/5MB and thus the cloning for this paritition fail.
I can go through the code to see if i find something which can resolve the issue for me. Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?

Thanks for all your work and reactivity !

Guillaume

[cspence]

@g.chanaud said:

Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?

https://github.com/FOGProject/fogproject/tree/dev-branch/src/buildroot/package/fog/scripts

The bin directory contains the scripts that fire off the jobs (you’ll want upload and download). The usr directory has the script functions that do all the magic.

[Sebastian Roth]

@g-chanaud Sorry for digging this out. But it seams like we have this problem still in current trunk version! Not sure if you still have this setup (Dell Utility partition is a major part of the problem). Let me know if you are interested to get this fixed?!