Resizable partition is not expanding
By repull, I mean rerun the fog installer.
Please repull and try deploying again.
I doubt it will fix the issue entirely, but it should bring back expanding disks in, what I suspect, will be a more appropriate manner.
Hongyun last edited by
No, the image is not double captured. I will try to capture a fixed partition image today to see if it will work, since most of my lab computers are using the same size hard drives, but it would be nice to have the resizable partitions work.
Things I do know:
We need to capture the image based on the starting point of the partition, regardless of if the partition has been shrunk. This is because the “start” points is where the data begins for that partition.
On deploy, we should NOT need to be so cautious to the start point whether the partition is a fixed size or not because we get to place the data whereever it may be needed.
Good news, I know what’s wrong. I still have a hard to believing that it “worked” once before, though that’s just my crazy thoughts.
So I built my own GPT based system and captured the image of it.
This worked beautifully, What hasn’t worked as well is the resizing of GPT.
So here’s what’s happening, from what I can see (during deploy process):
sfdisk is applied.
maths are done to attempt filling the disk.
Because the partition start isn’t shifted to the right, the freshly built sfdisk isn’t allowed to be applied.
Why does this occur particularly in GPT, it seems? This I haven’t quite figured. I can tell you it’s because of the strangeness of GPT partitions as they’re typically defined. Rather than shifting the next partitions start partition (whether they’re of fixed size or not) to a point that it might be able to able use, it’s trying to use the original start partition as defined in the sfdisk file, and not shifting start point of the other partitions.
I don’t know if this is trying to use the “full disk” for one partition rather than trying to evenly distribute it though. It feels like this might be what’s happening, though again I’m not 100%.
The reason this may be happening, I suspect, is because GPT lay’s out the disk much different than a typical MBR layout would be.
Typical MBR Layout will, typically, have the “larger” of the partitions at the end of the table.
Partition 1 will be a smaller boot partition.
Partition 2 will be the “data” partition (the one we want to resize).
I don’t know, and suspect this could cause issues, how this affects multiple-boot systems currently. It might have a layout like:
partition1 smaller windows boot partition/recovery?
partition 2 windows data (wants to be resized)
partition 3 linux swap or data
partition 4 linux swap or data.
Ultimately where the partitions are at shouldn’t matter, I just don’t know of a good way to approach it. This is particularly true in the case of “fixed” partitions, as we try not to adjust the start partitions at all for fixed partitions.
Was this image, by chance, double captured? Meaning, it was started the capture process, then restarted for some reason?
I’m asking this because, what I’m understanding of this particular image and the partition files you presented, the files are identical. I believe this might be a proponent of the problem. I will go ahead and look at the files dealing with 1.3.2 and 1.3.5 to see if I can see anything that sticks immediately out. While I’m sure there have been some changes, all of them in regards to resizing have been fairly minimal.