Problem resizing partitions on install
-
Server
- FOG Version: 1.3.5
- OS: Centos7
Client
- Service Version:
- OS:
Description
There is an error when I try to deploy a image to a computer with a smaller HD than the one used to capture the image (280GB). I have tried with two different computers with 80GB and 180GB HD, with same error.
Here is a capture of the error screen in the 80GB HD:
And the contents of the image files:
d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 79872, type=7, bootable
/dev/sda2 : start= 2923520, size= 52866560, type=7
/dev/sda3 : start= 155704320, size= 308224, type=7d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 152780800, type=7
/dev/sda3 : start= 155704320, size= 821068288, type=7 -
I don’t see how this is a bug.
Your minimum partitions second partition appears to be 270 gigs? Maybe my math is off as I’m stuck to a cell phone.
-
could you tell us more about how the partitions are laid out? which ones are restore/recovery/system/efi partitions?
-
@Junkhacker @Tom-Elliott Now I’m rebuilding the whole partition schema in order to have all the information detailed. I will post it in less than an hour.
Thank you
-
In order to clarify if it’s a normal behaviour or a bug, I have repartitioned and checked the partition schema and sizes of the partitions.
The starting point is a computer with a 298GB HD with three primary partitions:
sda1: NTFS, System Reserved. Size: 1,38GB
sda2: NTFS, Boot. Size: 30,11GB with 3,74GB free space
sda3: NTFS. Size: 266,59GB with 266,43GB free spaceAfter doing a “sysprep”, I captured the HD with fog and this are the content of the config files in the image directory:
d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 63135760, type=7
/dev/sda3 : start= 66059280, size= 559078065, type=7d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 60416, type=7, bootable
/dev/sda2 : start= 2923520, size= 52801536, type=7
/dev/sda3 : start= 66059280, size= 261120, type=7When I try to restore this image into a computer with a smaller HD (80GB) that should be enough to fit the three partitions, it gives me the same error.
I made the deployment as a debug task and using the “ismajordebug=1” kernel argument. Here are the screen captures:
I hope this helps to clarify what is happening. Let me know if you need more tests.
Thank you very much
-
@michelsantana Very good information. Thank you. So to clarify, as you’re not the first to have the error, partclone IS indeed running, but before it can complete the tasking it throws the error in the last picture, correct?
-
So to understand what’s happening.
Resizing works on this formula (now)
Take the original partition information (d1.partitions).
Figure out the original partition sizes and gather the percentage of difference between partitions.
Take the new disk size information.
For each resizable partition resize by the percentage gathered earlier.In your case
Partition 1 was originally:
1495793664 bytes or about 1.5 gb.
Partition 2 was originally:
32325509120 bytes or about 32.3 gb.
Partition 3 was originally:
286247969280 bytes or about 286 gb.
In total your disk was:
320070320640 or about 320 gb.
The resizing structure in percentage of use is
Partition 1:
0.4% the size of the original disk approximately.
Partition 2:
1.0% the size of the original disk approximately.
Partition 3:
89.4% the size of the original disk approximately.Taking this into consideration for the “smaller” drives:
Partition 1 is being set to:
373817344 bytes or approximately 370 mb – far smaller than the original. This is fine as the minimal space needed for the partition is 30932992 bytes or approximately 30mb.
Partition 3 is being set to:
71568982016 bytes or approximately 71 gb – far smaller than the original. This is fine as the minimal space needed for the partition is 133693440 bytes or approximately 133 mb.
Total disk size is 80026009600 bytes or approximately 80 gb (based solely on the pictures you’ve provided at least.)Below is the portion of what you’re seeing as failing.
Partition 2 is being set to:
8082136064 bytes or approximately 8.0 gb – far smaller than the original but also smaller than the minimal space needed which is 27034386432 bytes or approximately 27 gb.Hopefully this helps clarify what you’re seeing. This isn’t a bug (persay) but I will see if there’s a way for me to more appropriately pull in the information as it “should” not care as long as there’s enough space to place the data. in the mean time, you might want to make partition 2 a “fixed” size partition. Making it a fixed size partition will not make the disk scale appropriately though. While the 80gb would work fine, at a disk size of around 64gb (in this case) the last partition would end up being equal or smaller to the second partition.
-
@Tom-Elliott Exactly. Partclone starts and deploy the first partition, but when it tries to deploy the second, throws the error.
-
@Tom-Elliott That is exactly what happens. Now I’m trying to deploy the whole image into the computer with 80GB disk fixing the size of the second partition and then resize the partitions and capture again from that computer. That should guarantee that this deployment will work in disks of at least 80GB and above.
I will post the results.Thank you
-
@michelsantana Fixing the partition would work. As I said earlier, however, I’m going to try to figure out a way to know the “minimum” size as well as the “original” size. It may be a bit before I have a method that will work.
One of the problems I foresee, is because of the “percentage” handling. This is always “possible” even if the disk is larger than the “size” required. Having a nice mechanism to ensure the size will at least be as large as the size needed for a partition would be a better route, I think.
This can work now, of course, but only if you don’t mind losing the “scaling” capabilities.
-
I’ve made a modification to how to implement a bit more properly.
Mind trying it?
wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz -
@Tom-Elliott Applied the patch, captured the image from a 300GB HD and ended with this parameters:
d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 286721536, type=7
/dev/sda3 : start= 289645056, size= 335495680, type=7d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors/dev/sda1 : start= 2048, size= 60416, type=7, bootable
/dev/sda2 : start= 2923520, size= 53114368, type=7
/dev/sda3 : start= 289645056, size= 235008, type=7Then I deployed the image in debug mode to a 80GB HD. The captures of the partition process (deploy in debug mode)
There were no errors and seems that everything is working fine. Finally I’ve got three partitions with the right proportions (338MB, 36,69GB and 42,93GB).
Thank you very much for your help!
P.S.
I would be great in future releases to have information about the partition layout of the images in the “Image Management” section, and also to have the possibility of fixing the size of one partition there, without the need of editing the file d1.fixed_size_partitions -
@michelsantana The partition data is stored in the DB. The Fixed size partitions, ideally, should not be editable really. Being able to edit manually is “useful” but ultimately just a bandaid.
Hopefully editing this file will no longer be needed.
That said, you should not have needed to recapture the image for the fix to work, but glad that it did work for you.
-
@Tom-Elliott Understood
I will probably do a custom report to have the information about the images and their partition layout. Thank you again!
