#1300 Issue `closed`: 32G recover on 256G disk -> message: size reduced to fit on disk¶

Labels: bug, fixed / solved / done

ProBackup-nl opened issue at 2017-04-14 16:39:¶

rear version: 2.00 git
OS version: Arch Linux
rear configuration files: NETFS USB
Are you using legacy BIOS or UEFI boot? UEFI
Brief description of the issue: Recovery on larger drive causes 1 out of 3 partitions to be reduced in size.

Source:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G  2.1G   18G  11% /
/dev/sda3       9.3G   17M  9.3G   1% /home
/dev/sda1      1022M   44M  979M   5% /boot

Destination¶

/dev/nvme0n1, 256GB, unit B: 256060514304B

Steps to recover¶

# rear recover
...
1) View disk layout (disklayout.conf)
...
5) Continue recovery
...
#? 5
Partition home on /dev/nvme0n1: size reduced to fit on disk.

Diskrestore.sh layout¶

unit compact¶

mkpart boot EFIBOOT 2M 1.07G
mkpart root root 1.07G 173.9G
mkpart home home 173.9G 256.0G

unit B¶

mkpart boot EFIBOOT 2097152B 1075838975B
mkpart root root 1075843072B 173924794047B
mkpart home home 173924794368B 256060497407B

home partition after = 256 - 173.9 = 82G

Disk size = 256060514304B
Home end  = 256060497407B
Result    =       +16897B

It seems that there is no size reduction at al, only an incorrectly displayed size reduction warning message in 100_include_partition_code.sh.

This is the code that triggers the "size reduced to fit on disk" message:

...
let start=2097152 # start after cylinder 4096*512 (for grub2 - see issue #492)
let end=0
...
while read part disk size pstart name flags partition junk; do
    ...
    end=$(( start + size ))
    ...
    if [[ "$device_size" ]] && (( end > $device_size ))

jsmeix commented at 2017-04-19 11:55:¶

Frankly and simply put:
Since a longer time I have the dim feeling the whole
partitioning calculation code needs some "cleanup".

But currently I fail to understand how the
partitioning calculation code works, cf.
https://github.com/rear/rear/issues/1269#issuecomment-290032733
and subsequent comments.
I need much more time to thoroughly look at it
but currentyl I do not have that time for ReaR.
Perhaps at the eariest in May I have again
more time to work on ReaR.

And I never really used or tested the disk migration mode.

In general I think disk migration is a bottomless (snake)-pit.

I think we should not even try to do things right like migrate
a system on a single 150 GiB traditional spinning harddisk
onto two SSDs each with 100 GiB.

But I think what must work with ReaR is to migrate
a system on a single disk onto a single bigger disk.

I think what may work with ReaR is to migrate
a system on several disks onto same-or-bigger disks like
a 100 GiB /dev/sda onto a new 100 GiB /dev/sda and
a 200 GiB /dev/sdb onto a new 300 GiB /dev/sdb

But this case could become tricky e.g. for things like
a 100 GiB /dev/sda onto a new 200 GiB /dev/sda and
a 200 GiB /dev/sdb onto a new 200 GiB /dev/sdb
or even
a 100 GiB /dev/sda onto a new 300 GiB /dev/sda and
a 200 GiB /dev/sdb onto a new 200 GiB /dev/sdb

jsmeix commented at 2017-04-21 14:16:¶

Hopefully I find some time during May
to have a closer look what the partitioning code
actually does - but no promises...

jsmeix commented at 2017-04-26 12:08:¶

@ProBackup-nl
I found no time to check the details
but I guess this issue here is related to
wrong partitioning calculation results on bigger disks
that meanwhile should (hopefully) be fixed
with https://github.com/rear/rear/pull/1332 merged.

Now 'bc' is used for partitioning calculations
so that now 'bc' is a mandatory tool for ReaR
('bc' is in REQUIRED_PROGS in default.conf).

I close this issue because I assume it is fixed
by https://github.com/rear/rear/pull/1332
If not, please reopen it.

ProBackup-nl commented at 2017-05-10 21:57:¶

@jsmeix There is not likely a math issue here, because the system hasn't got mawk on board:
which: no mawk in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl) only the unaffected GNU awk is running on the source OS:

# ls -l /usr/bin/awk
lrwxrwxrwx 1 root root 4 Nov  6  2016 /usr/bin/awk -> gawk

[Export of Github issue for rear/rear.]

#1300 Issue closed: 32G recover on 256G disk -> message: size reduced to fit on disk¶