#1195 Issue closed: ReaR picked up wrong disk size when re-creating the disk partition

Labels: bug

j100ng opened issue at 2017-02-07 18:26:

Relax-and-Recover (rear) Issue Template

Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):

  • rear version (/usr/sbin/rear -V):
    Relax-and-Recover 1.17.2 / Git

  • OS version (cat /etc/rear/os.conf or lsb_release -a):
    LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
    Distributor ID: RedHatEnterpriseServer
    Description: Red Hat Enterprise Linux Server release 7.2 (Maipo)
    Release: 7.2
    Codename: Maipo

  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

EXCLUDE_BACKUP=(${EXCLUDE_BACKUP[@]} /tmp /var/lib/rear)
export TMPDIR
  • Are you using legacy BIOS of UEFI boot? No
  • Brief description of the issue:
    When I try to restore my server using ReaR, I got an error when attempting to recreate the disk partition.
+++ parted -s /dev/sda mkpart '"rear-noname"' 180623507456B 9592801067007B
Error: The location 9592801067007B is outside of the device /dev/sda

My server has 3 600G HD configured as RAID 5. The total disk space should have been 1.2T.
Attached is the output of fdisk: fdisk-sda.txt

I tried tracing the log when ReaR created the backup ISO. It reads from /sys/block/sda/size and got 2341994496 as the # of blocks on disk array. It then reads from /sys/block/sda/queue/logical_block_size and gets 4096 as the # of bytes per block. This explains why the wrong calculation of getting 9+ TB.

+++ echo /dev/sda
+++ return 1
++ devname=/dev/sda
+++ get_disk_size sda
+++ local disk_name=sda
++++ get_block_size sda
++++ '[' -r /sys/block/sda/queue/logical_block_size ']'
++++ echo 4096
+++ local block_size=4096
+++ '[' -r /sys/block/sda/size ']'
+++ BugIfError 'Could not determine size of disk sda, please file a bug.'
+++ ((  0 != 0  ))
+++ local nr_blocks=2341994496
+++ local disk_size=9592809455616
+++ echo 9592809455616
++ devsize=9592809455616
+++ parted -s /dev/sda print
+++ grep -E 'Partition Table|Disk label'
+++ cut -d : -f 2
+++ tr -d ' '
++ disktype=gpt
++ echo 'disk /dev/sda 9592809455616 gpt'

I am new to RHEL & ReaR, any suggestion on how come fdisk gets the correct disk size calculation but not ReaR? Is there a configuration error when I set up ReaR?

  • Work-around, if any:

gdha commented at 2017-02-13 13:53:

@j100ng could you paste the /var/lib/rear/layout/disklayout.conf file please?
Interesting bug - could you also tell us what should be the corrective actions?

j100ng commented at 2017-02-13 17:28:

Attached are the disklayout.conf as requested and also the actual log file when recover error occured.

My disk configurations has nothing special and thus can't understand why encounter such error. I'd like to establish is it a configuration issue, or a software bug or system error? I have also open up a case with RedHat in parallel cause it seems like the info in /sys/block/sda/ are wrong, thus leading to ReaR calculated the wrong partition size. I'd appreciate your help to determine if it's not configuration or software bug.


gdha commented at 2017-02-14 08:30:

To summarize we see with fdisk the following:

Disk /dev/sda: 1199.1 GB, 1199101181952 bytes, 292749312 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt

#         Start          End    Size  Type            Name
 1          256       128255    500M  EFI System      EFI System Partition
 2       128256       194815    260M  unknown         Basic data partition
 3       194816      5437695     20G  Linux LVM       Basic data partition
 4      5438976      5512191    286M  Microsoft basic primary
 5      5512192    292749055    1.1T  Linux LVM

And, the disklayout.conf file has:

disk /dev/sda 9592809455616 gpt
part /dev/sda 4194304000 8388608 EFI0x20System0x20Partition boot /dev/sda1
part /dev/sda 2181038080 4202692608 Basic0x20data0x20partition hidden /dev/sda2
part /dev/sda 171798691840 6383730688 Basic0x20data0x20partition lvm /dev/sda3
part /dev/sda 2399141888 178224365568 primary none /dev/sda4
part /dev/sda 9412177559552 180623507456 rear-noname lvm /dev/sda5

During rear recover we see in the log file:

+++ parted -s /dev/sda mkpart '"EFI System Partition"' 8388608B 4202692607B
+++ parted -s /dev/sda name 1 '"EFI System Partition"'
+++ parted -s /dev/sda mkpart '"Basic data partition"' 4202692608B 6383730687B
+++ parted -s /dev/sda name 2 '"Basic data partition"'
+++ parted -s /dev/sda mkpart '"Basic data partition"' 6383730688B 178182422527B
+++ parted -s /dev/sda set 3 lvm on
+++ parted -s /dev/sda name 3 '"Basic data partition"'
+++ parted -s /dev/sda mkpart '"primary"' 178224365568B 180623507455B
+++ parted -s /dev/sda name 4 '"primary"'
+++ parted -s /dev/sda mkpart '"rear-noname"' 180623507456B 9592801067007B
Error: The location 9592801067007B is outside of the device /dev/sda.

@j100ng Perhaps, you could run rear -dD savelayout to capture the debug output? Maybe, we can see where it goes wrong? That kind of input will RedHat also require. It could be helpful to attach the RH bugzilla reference number to this issue as well.

j100ng commented at 2017-02-14 14:22:

I have attached 2 files here

debug output of "rear -dD savelayout"

tar file of related info like /etc/rear/.conf & /sys/block/sda/

I don't have a RH bugzilla reference since I raised my issue, Case # 01787845, into RH Customer Portal. Don't think anyone else can read it.

j100ng commented at 2017-02-23 18:39:

RH confirms that there is an issue with detecting the disk layout. See https://bugzilla.redhat.com/show_bug.cgi?id=1426341. The workaround RH support suggested is for me to modify /usr/share/rear/lib/layout-functions.sh to hard code get_block_size() to always return 512 on my servers.

jsmeix commented at 2017-12-01 13:46:

Cannot be fixed until ReaR 2.3 release
so that I postpone it for ReaR 2.4.

gdha commented at 2018-02-23 17:43:

Could be linked with PR https://github.com/rear/rear/pull/1733 ?

jsmeix commented at 2018-02-26 13:10:

Yes, it is somehow related to issues
like https://github.com/rear/rear/pull/1733
and https://github.com/rear/rear/issues/1731
and https://github.com/rear/rear/issues/102

But I think this issue here is not the same issue.

I cannot fix and clean up the whole disk layout code
in one single pull request, cf.

In general in relation to the whole disk layout code
you may also have a look at what I had written about
"ReaR's disk layout code skeleton in the closet" in
in particular my currenly latest reasoning
about a "clean design" (of the disk layout code) in

gdha commented at 2018-05-10 08:30:

1.17.2 is an old release, and has been replaced with the 2.0 within RedHat. This is not a show stopper and it might be fixed, but we cannot promise any date. Change milestone also to 'ReaR future'

jsmeix commented at 2018-08-01 10:03:

I think this issue here is the same as https://github.com/rear/rear/issues/1884
where the latter should get fixed by https://github.com/rear/rear/pull/1885
so that I will close this issue here
when https://github.com/rear/rear/pull/1885 got merged.

gdha commented at 2018-11-05 13:02:

Issue #1885 has been merged. Red Hat is official supporting their version of rear-2.00.
We can close this issue here. With the latest RH rear-2.00-6.el7.x86_64 it could be fixed. If not, please submit a software case at RH

[Export of Github issue for rear/rear.]