#389 Wrong calculations for proportional partitioning on smaller disk

[mirh]

So.. I was cloning a standard hdd with Windows (500GB, just 80 used) to a new ssd (250GB).
I just straightaway run for the lulz the default clone settings plus -k1 (expecting if not any that I'd have had to manually resize the main data partition like I did in [0d970f124f#64db] IIRC).. but to my surprise it could also come up with a tentative "proportional partition table" by working with free space within partitions.
(hell, you even knew that the system partition is kinda special and that there's no point into retouching its dimensions)

All of this praise to underline just how far ahead CLZ is.
Yet somehow it seemed to stumble into some pretty silly bug.

The ratio for target disk size to original disk size is .4800112691.
MS Windows (Vista or 7) "system reserved partition" found. Not to expand this partition.
The partition table to write in /dev/sdf:
*****************************************
label:dos
unit:sectors

/dev/sdf1 : start= 2048, size= 204800, Id=7, bootable
/dev/sdf2 : start= 206848, size= 468212960, Id=7
/dev/sdf3 : start= 468419808, size= 442378, Id=27
*****************************************
Running: LC_ALL=C sfdisk --force --wipe always /dev/sdf < /tmp/new_sf.WKKPH0
Checking that no-one is using this disk right now ... OK

Disk /dev/sdf: 223.57, 240057409536 bytes, 468862128 sectors
Disk model: SanDisk SDSSDA24
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5b10ee6c

Old situation:

>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x00ab6611
/dev/sdf1: Created a new partition 1 of type 'HPFS/NTFS/exFAT' and of size 100MiB
/dev/sdf2: Created a new partition 1 of type 'HPFS/NTFS/exFAT' and of size 223.3 GiB.
/dev/sdf3: No free sectors available.
Failed to add #3 partition: No space left on device.
Leaving.

This was done by EXTRA_SFDISK_OPT="--force --wipe always" ocs-expand-mbr-pt -icds --batch /tmp/d2d-pseudo-tmp-cnvted/sdf-pt.sf /dev/sdf 2>&1

It's arguable if the recovery partition should be also treated as "sacred" and untouchable, or just left up for the grabs of resizing... But nonetheless the final partition is 468419808 + 442378 sectors, which is 58 sectors bigger than the disk's 468862128.

[Steven Shiau]

Well, for larger disk to the smaller one, the program ocs-expand-gpt-pt might fail due to some partition which we do not know how to clone it if the destination is smaller than the source one.
In this case, I suggest you try to use fdisk to create the partition table on the destination disk, and use the option "-k", i.e., not to create partition table again when Clonezilla is run.

Steven

[mirh]

Ocs-expand-mbr-pt you meant probably, and yes I did eventually worked this around by manually creating a final 451MB partition and then cloning individual partitions separately.

But there was no mysterious partition (putting aside that even even if it was the case, I would argue it should be possible to just keep it that size and call it a day good with the remaining calculation) and this is what's puzzling me. As you can see from the first link of the thread, it was just a basic "once W7" disk with three partitions (the screenshot could be as well be mine, if just so it didn't happen to come from a disk half as large).

I thought perhaps there might have been some rounding error with the scaling ratio, but spec and stats agree the number of sectors was just right.
And I was also ready to blame whatever dead ass old version of sfdisk ubuntu/debian may have been shipping, but the 3.0.1-8 release notes say that was built from sid.