Resizable partition is not expanding
-
Re: Hard drive resize is not expanding##### Server
- FOG Version: 1.3.5 RC 10
- OS: Red Hat Enterprise 6.8
Client
- Service Version:
- OS: Ubuntu 16 & Windows 7 dual boot
Description
Re: Hard drive resize is not expanding
Today I’m trying to download an image created with FOG 1.3.2 to another computer, and then I discovered the resizable partitions are not expanding. So I update the server to the latest dev version. Still get the same problem, then I upload a new image with the FOG 1.3.5, then downloaded it again, still get the same problem, but better, this time Windows partition seems expanded, but the Linux partiton is still only 22GB.
Here are the current partition table on the problem computer:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 519291975 52261960 24.9G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / SolarisHere is the partition table on the computer I’m taking the image (they both have the same size hard drive):
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 765794303 298764288 142.5G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / SolarisHere is the d1.partition (this used to be called d1.original.partitions under FOG 1.3.2) file on the FOG server:
cat d1.partitions
label: dos
label-id: 0x242a986c
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 204800, type=7, bootable
/dev/sda2 : start= 206848, size= 466823168, type=7
/dev/sda3 : start= 467030016, size= 298764288, type=83
/dev/sda4 : start= 765794304, size= 15626240, type=82Here is the d1.original.partitions file created under FOG 1.3.2 on FOG server:
cat d1.original.partitions
partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2 : start= 206848, size=466823168, Id= 7
/dev/sda3 : start=467030016, size=298764288, Id=83
/dev/sda4 : start=765794304, size= 15626240, Id=82And I’m sure the resizable partition works perfectly under FOG 1.3.2.
Thanks,
Hongyun -
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.
-
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.
For example:
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.
-
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.
-
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.
Thanks!
-
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.
-
By repull, I mean rerun the fog installer.
-
This post is deleted! -
@Tom-Elliott There is something wrong. After I reinstalled FOG, uploaded a resizable partition, then downloaded the image to another computer. Both the base image computer and the new computer’s partition table got changed.
Here is the partition table before upload the image:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 765794303 298764288 142.5G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / SolarisHere is the partition table on the base image computer after upload the image:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 516360375 49330360 23.5G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / SolarisHere is the partition table on the new computer:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 383646 381599 186.3M 7 HPFS/NTFS/exFAT
/dev/sda2 383647 870205150 869821504 414.8G 7 HPFS/NTFS/exFAT
/dev/sda3 870205152 961146436 90941285 43.4G 83 Linux
/dev/sda4 961146438 976772677 15626240 7.5G 82 Linux swap / SolarisWhen I define the image, I used Linux as the Operating System, but it looks like the partition table changes are only affecting the Linux partitions, should I choose a different Operating System for the image?
Now I feel regret, I should have upload a non-resizable image first, I didn’t expect it will change the partition table when uploading an image…
-
@Hongyun said in Resizable partition is not expanding:
Here is the partition table before upload the image:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 765794303 298764288 142.5G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / Solaris
Here is the partition table on the base image computer after upload the image:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 467030015 466823168 222.6G 7 HPFS/NTFS/exFAT
/dev/sda3 467030016 516360375 49330360 23.5G 83 Linux
/dev/sda4 765794304 781420543 15626240 7.5G 82 Linux swap / Solaris
Here is the partition table on the new computer:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 383646 381599 186.3M 7 HPFS/NTFS/exFAT
/dev/sda2 383647 870205150 869821504 414.8G 7 HPFS/NTFS/exFAT
/dev/sda3 870205152 961146436 90941285 43.4G 83 Linux
/dev/sda4 961146438 976772677 15626240 7.5G 82 Linux swap / SolarisI’m seeing changes on all three.
First one is the “original”
Second one is the shrunken state.
Third one is the “expanded” form. Linux looks expanded, and NTFS looks expanded. Is this not happening? -
@Tom-Elliott The first one is the original, the second one is the original after I upload image, upload shouldn’t make any changes on the partition, right?
-
@Hongyun It does make changes, but it should reapply the original partition table.
-
@Tom-Elliott then in this case, it didn’t reapply the original partition table, I have to use gparted to resize the partition.
-
@Hongyun What’s the contents of the new image’s:
d1.partitions and d1.minimum.partitions
-
@Tom-Elliott previous numbers I gave you are all the result of fdisk command
$ cat d1.partitions
label: dos
label-id: 0x242a986c
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 204800, type=7, bootable
/dev/sda2 : start= 206848, size= 466823168, type=7
/dev/sda3 : start= 467030016, size= 49330360, type=83
/dev/sda4 : start= 765794304, size= 15626240, type=82$ cat d1.minimum.partitions
label: dos
label-id: 0x242a986c
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 204800, type=7, bootable
/dev/sda2 : start= 206848, size= 466823168, type=7
/dev/sda3 : start= 467030016, size= 48807402, type=83
/dev/sda4 : start= 765794304, size= 15626240, type=82 -
Did you mess with the partition layouts before having fog capture it? It looks, to me, like this is the case. The d1.partitions should be different from the d1.minimum.partitions files. d1.partitions is the “original” layout, so if they are the exactly the same, then you will have some issues.
-
@Tom-Elliott No, I didn’t change any partition settings, I only installed some updates, and then started the upload process. And this is a newly created image, I might have changed it to non-resizable, and then changed back to resizable, but these changes are on FOG WebGUI, before I issue the upload task.
-
Please re-run the installer and try again?
I know it’s a lot of back and forth, but it should work (hopefully).
At least the original and new sizes appear to be expanding on the same originating disk, I have not yet had the chance to test orig < smaller drive and orig > larger drive yet. Just same size disk for now. All appears to be working atleast in that regard.
-
@Tom-Elliott Yeah! It’s resized properly this time. Thank you so much for your quick response and quick fix!!!
-
Want to give a shot on both upload and deploy (or did you already do this?)
