These are the files as are currently in my image. I’ve manually modified “d1.fixed_size_partitions” which originally contained “1:2” and “d1.partitions” setting the size of the extended and logical partition to 99999999999 as I would like these partitions to fill the entire available space, whatever hardware or VM I deploy to. (Be it a VM with only 64GB disk or a PC with either 256 or 500GB disk)

d1.fixed_size_partitions

1:

d1.original.fstypes

/dev/sda5 extfs

d1.minimum.partitions

label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   103802882, type=5
/dev/sda5 : start=     1052672, size=    54399852, type=83

d1.partitions

label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size= 99999999999, type=5
/dev/sda5 : start=     1052672, size= 99999999999, type=83

@sebastian-roth I won’t claim to completely understand the procsfdisk code, but I’m currently suspecting the “if” clause on line 436.

436                if (match(fixedList, regex)) {
437                    continue;
438                }

When encountering a extended partion, I think it’s size should never be taken into account when trying to resize variable primary or logical partitions. So the for loop should break there in whatever case.

I’ve removed that “if” clause, leaving the “continue;” in place. This gives me:

./procsfdisk.awk -v SECTOR_SIZE=512 -v CHUNK_SIZE=512 -v MIN_START=2048 -v action=filldisk -v target=/dev/sda -v sizePos=134217728 -v diskSize=134217728 -v fixedList=1: d1.minimum.partitions d1.partitions 
# Partition table is consistent.
label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   133162498, type=5
/dev/sda5 : start=     1052672, size=   133162496, type=83

To me this seems a much more believable layout. So I’ve patched my init.xz, copying in the new procsfdisk.awk script using the postinitscript method. This seems to solve the issue for me. (… after deleting the d1p2.* files from my image as they overwrite the new layout of the extended partition.)

@sebastian-roth, no worries. Thnx for the update. I had a quick glance at the other topic but I’ll need to read I properly to make any accurate observations

Current causes I found for my own case:

• The bug in the procsfdisk.awk resize script (fixed for myself with the PR)
• After resizing partitions during a restore task the contents of the extended partition table (d1p2 in my case) is written to the disk. This contains the layout of the original small logical partitions. (solved by deleting d1p2.ebr &d1p2.img from the image)

For now I have my setup working. Just hoping I can help you guys with it.

Hi all,

been A while. I guess we’ve all been busy. Just wanted to check back in if there’s anything I can still help with on this topic?

Grtz, Harm

@sebastian-roth, no worries. Thnx for the update. I had a quick glance at the other topic but I’ll need to read I properly to make any accurate observations

Current causes I found for my own case:

• The bug in the procsfdisk.awk resize script (fixed for myself with the PR)
• After resizing partitions during a restore task the contents of the extended partition table (d1p2 in my case) is written to the disk. This contains the layout of the original small logical partitions. (solved by deleting d1p2.ebr &d1p2.img from the image)

For now I have my setup working. Just hoping I can help you guys with it.

@tom-elliott I did remove the “if” clause on lines 436 and 438. But I left the continue; statement at line 437. That way the size of the extended partition is left out of scope for the resize variables starting line 457

See here: https://github.com/FOGProject/fos/pull/52

(Feel free to reject or disregard that PR if you feel it could have been done better.)

@rodluz allthough that comment did confuse me. I don’t think it is related to my issue with calculation of the extended partition. Currently what I know of the filldisk functions is:

• It sums the sizes of all fixed partitions from the image in “original_fixed”
• It sums the sizes of all variable partitions from the image in “original_variable”
• It calculates “new_available” (new storage available for variable size partitions) by subtracting “original_fixed” from the new disk size.
• It calculates a factor to resize all variable partitions by dividing “new_variable” by “original_variable”.

My specific problem is that the size of the extended partition is added to “original_variable” whereas it this should be completely ignored in the resize factoring. (only variable logical partitions should be added).

All in all, I think when a variable partition is encountered, that iteration of the for loop should never arrive at lines 456.

On a separate note, it now occurs to me that a fixed extended partition might also not be properly handled. If the extended partition is marked as fixed, I think that “fixed” flag should be inherited to the logical partitions. As you simply can’t resize logical partitions to outside of the extended one.

Hope this all makes sense?

@sebastian-roth I won’t claim to completely understand the procsfdisk code, but I’m currently suspecting the “if” clause on line 436.

436                if (match(fixedList, regex)) {
437                    continue;
438                }

When encountering a extended partion, I think it’s size should never be taken into account when trying to resize variable primary or logical partitions. So the for loop should break there in whatever case.

I’ve removed that “if” clause, leaving the “continue;” in place. This gives me:

./procsfdisk.awk -v SECTOR_SIZE=512 -v CHUNK_SIZE=512 -v MIN_START=2048 -v action=filldisk -v target=/dev/sda -v sizePos=134217728 -v diskSize=134217728 -v fixedList=1: d1.minimum.partitions d1.partitions 
# Partition table is consistent.
label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   133162498, type=5
/dev/sda5 : start=     1052672, size=   133162496, type=83

To me this seems a much more believable layout. So I’ve patched my init.xz, copying in the new procsfdisk.awk script using the postinitscript method. This seems to solve the issue for me. (… after deleting the d1p2.* files from my image as they overwrite the new layout of the extended partition.)

While debugging my resizing issue on FOS (or rather lack of resizing), I found FOS is executing this command:

$ ./procsfdisk.awk -v SECTOR_SIZE=512 -v CHUNK_SIZE=512 -v MIN_START=2048 -v action=filldisk -v target=/dev/sda -v sizePos=134217728 -v diskSize=134217728 -v fixedList=1: d1.minimum.partitions d1.partitions
# Partition table is consistent.
label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   103802882, type=5
/dev/sda5 : start=     1052672, size=    66580992, type=83

My expectations would have been sda2 & sda5 to be around 133167104 in size. This led me to poking around in procsfdisk.awk and by adding some extra print statements I noticed “original_variable” was assigned 199999999998 which is the sum of my extended and logical partition. (While “new_variable” is the disk size minus space used by fixed size partitions)

These are the files as are currently in my image. I’ve manually modified “d1.fixed_size_partitions” which originally contained “1:2” and “d1.partitions” setting the size of the extended and logical partition to 99999999999 as I would like these partitions to fill the entire available space, whatever hardware or VM I deploy to. (Be it a VM with only 64GB disk or a PC with either 256 or 500GB disk)

d1.fixed_size_partitions

1:

d1.original.fstypes

/dev/sda5 extfs

d1.minimum.partitions

label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   103802882, type=5
/dev/sda5 : start=     1052672, size=    54399852, type=83

d1.partitions

label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size= 99999999999, type=5
/dev/sda5 : start=     1052672, size= 99999999999, type=83

@george1421 Nope. Only a EFI partition (sda1) and ext4 root (sda5)

Hi there,

I’ve spend my afternoon mudding around in the procsfdisk.awk script, as I understand that it is used to calculate and resize partition layouts when restoring a resizable image to a bigger disks. And for some reason I get some funny results in our environment while restoring a ubuntu (actually Mint) image to a bigger disk trying to fill the disk by expanding sda2 & 5

label: dos
label-id: 0x964ef18c
device: /dev/sda
unit: sectors
sector-size: 512

/dev/sda1 : start=        2048, size=     1048576, type=b, bootable
/dev/sda2 : start=     1052670, size=   103802882, type=5
/dev/sda5 : start=     1052672, size=    54399852, type=83

I wonder if someone could explain me something: From what I see, non-fixed partitions are resized based on line 541

p_size = new_variable * p_size / original_variable;

Where:
“p_size” is the partitions size
“new_variable” is the new disk’s space, not used but fixed size partitions.
“original_variable” should be the size of the original disk’s space minus space used by fixed partitions?

In my testing however it seems that “original_variable” is calculated by adding both the size of the “extended partition” (sda2) and “logical partition” (sda5). Is this on purpose or a bug?

Edit: https://github.com/FOGProject/fos/pull/52