#2182 Issue closed: When resizing 420_autoresize_last_partitions.sh does not leave 33 blocks at end of GPT disk

Labels: bug, fixed / solved / done

jsmeix opened issue at 2019-07-15 12:34:

Current ReaR master code:

When 420_autoresize_last_partitions.sh resizes the last partition
on a GPT disk it does not leave 33 LBA blocks at the end of the disk
so that then 100_include_partition_code.sh runs its code

        sysfs_name=$(get_sysfs_name "$device")
...
            block_size=$( get_block_size "$sysfs_name" )
            device_size=$( get_disk_size  "$sysfs_name" )

            ### GPT disks need 33 LBA blocks at the end of the disk
            # For the SUSE specific gpt_sync_mbr partitioning scheme
            # see https://github.com/rear/rear/issues/544
            if [[ "$label" == "gpt" || "$label" == "gpt_sync_mbr" ]] ; then
                device_size=$( mathlib_calculate "$device_size - 33*$block_size" )
...
        if [[ "$device_size" ]] && (( end > $device_size )) ; then
            LogPrint "Partition $name on $device: size reduced to fit on disk."
            Log "End changed from $end to $device_size."
            end="$device_size"
        fi

which is not wanted.

When 420_autoresize_last_partitions.sh resizes the last partition
on a GPT disk it should leave 33 LBA blocks at the end of the disk
so that 420_autoresize_last_partitions.sh produces a fully correct
disklayout.conf file where no further automated adjustments by
a subsequent script like 100_include_partition_code.sh are done,
cf. https://github.com/rear/rear/issues/1731#issuecomment-368018282

jsmeix commented at 2019-07-18 11:36:

With https://github.com/rear/rear/pull/2188 merged
this issue should be fixed.


[Export of Github issue for rear/rear.]