Partition size too little with a "Single Disk - Resizable" image - svn 3537
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 ?
SVN trunk rev 3537
@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?!
Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?
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.
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 !
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.
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.
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.
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.
What version did you upload the original image from?