#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):
OUTPUT=ISO
EXCLUDE_BACKUP=(${EXCLUDE_BACKUP[@]} /tmp /var/lib/rear)
BACKUP=NETFS
OUTPUT_URL=null
BACKUP_URL="iso:///backup"
ISO_DIR="/var/lib/rear/test"
TMPDIR="/var/lib/rear/tmp"
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.
dislayout.conf.txt
rear-macso1.log.txt
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"
rear-macso1.log.txt
tar file of related info like /etc/rear/.conf & /sys/block/sda/
rear-env.tar.gz
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.
https://github.com/rear/rear/pull/1733#issuecomment-368488004
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
https://github.com/rear/rear/pull/1603#issuecomment-347860869
in particular my currenly latest reasoning
about a "clean design" (of the disk layout code) in
https://github.com/rear/rear/pull/1091#issuecomment-263819775
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.]