Description of problem:
rear fails to properly identify imsm disks properly, and complains about GPT header location

Version-Release number of selected component (if applicable):
rear-2.4-13.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install system in intel imsm raid1
2. Use rear on the system to attempt to backup

Actual results:

In /var/log/messages:
Aug 10 02:00:04 db81-0029 kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
Aug 10 02:00:04 db81-0029 kernel: GPT:445392895 != 468862127
Aug 10 02:00:04 db81-0029 kernel: GPT:Alternate GPT header not at the end of the disk.
Aug 10 02:00:04 db81-0029 kernel: GPT:445392895 != 468862127
Aug 10 02:00:04 db81-0029 kernel: GPT: Use GNU Parted to correct GPT errors.

In rear log:
2021-08-10 02:00:04.585401909 Including layout/save/GNU/Linux/200_partition_layout.sh
2021-08-10 02:00:04.599251533 Saving disk partitions.
Error: /dev/sda: unrecognised disk label
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 23469232 blocks) or continue with the current setting?
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 23469232 blocks) or continue with the current setting?
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
Warning: Not all of the space available to /dev/sdc appears to be used, you can fix the GPT to use all of the space (an extra 23469232 blocks) or continue with the current setting?
2021-08-10 02:00:04.777445593 Ignoring sdd: it is a path of a multipath device
2021-08-10 02:00:04.784109955 Ignoring sde: it is a path of a multipath device
2021-08-10 02:00:04.789783992 Ignoring sdf: it is a path of a multipath device
2021-08-10 02:00:04.795162991 Ignoring sdg: it is a path of a multipath device
2021-08-10 02:00:04.801393798 Ignoring sdh: it is a path of a multipath device
2021-08-10 02:00:04.806298611 Ignoring sdi: it is a path of a multipath device
2021-08-10 02:00:04.810031730 Ignoring sdj: it is a path of a multipath device
2021-08-10 02:00:04.813743716 Ignoring sdk: it is a path of a multipath device
2021-08-10 02:00:04.817426220 Including layout/save/GNU/Linux/210_raid_layout.sh
2021-08-10 02:00:04.819704574 Saving Software RAID configuration.
/usr/share/rear/layout/save/GNU/Linux/210_raid_layout.sh: line 44: let: sparedevices=2-: syntax error: operand expected (error token is "-")
/usr/share/rear/layout/save/GNU/Linux/210_raid_layout.sh: line 65: [: : integer expression expected
2021-08-10 02:00:04.987777082 Including layout/save/GNU/Linux/220_lvm_layout.sh

Expected results:
rear should be able to properly handle imsm volumes

Additional info:
With firmware RAID (Intel SATA RAID Controller) which create imsm RAID container and the RAID metadata saved at the end of the disk. This is not a pure hardware RAID configuration, hence the underlying device also exposed to the kernel/operating system.

~~~
/dev/md126:
Container : /dev/md/imsm0, member 0
Raid Level : raid1
Array Size : 222696448 (212.38 GiB 228.04 GB)
Used Dev Size : 222696448 (212.38 GiB 228.04 GB)
Raid Devices : 2
Total Devices : 2

State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

UUID : 3215dd43:a517d9fd:89af8255:d4d151a1
Number Major Minor RaidDevice State
1 8 16 0 active sync /dev/sdb
0 8 32 1 active sync /dev/sdc
/dev/md127:
Version : imsm
Raid Level : container
Total Devices : 2

Working Devices : 2

Member Arrays : /dev/md/vol1

Number Major Minor RaidDevice

• 8 16 - /dev/sdb
• 8 32 - /dev/sdc
  ~~~

Since we are creating the GPT partition table on RAID volume (md-X device), the secondary GPT partition is not actually saved at the end of the disk. Instead secondary GPT table saved at the end of RAID volume or before the RAID volume metadata.

disk sdb/sdc with total sectors 468862128s

------------sector 0

Now the issue is when we run rear backup tool it execute "/usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh" script which tries to collect the partition table details from the underlying device of RAID volume and reporting following error.

~~~
Aug 10 02:00:04 db81-0029 kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
Aug 10 02:00:04 db81-0029 kernel: GPT:445392895 != 468862127
Aug 10 02:00:04 db81-0029 kernel: GPT:Alternate GPT header not at the end of the disk.
~~~

We can't move GPT partition table to end of the device as it can corrupt RAID volume metadata.

I tried to add following in /etc/rear/local.conf in my local test machine, but didn't help.

AUTOEXCLUDE_DISKS=y
EXCLUDE_DEVICE_MAPPING=( 'sde' )

Aug 17 05:51:29 localhost.localdomain kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
Aug 17 05:51:29 localhost.localdomain kernel: GPT:2064383 != 3088383
Aug 17 05:51:29 localhost.localdomain kernel: GPT:Alternate GPT header not at the end of the disk.

Upstream there are two relevant bugs that don't appear to have been resolved. They have different behavior as far as the actual output, but the issue that rear is not compatible with IMSM volumes appears to be the same.

ReaR does not support RAID 1 mdraid Intel IMSM/RST based firmware RAID containers · Issue #1540 · rear/rear
https://github.com/rear/rear/issues/1540

​​mdadm do not restored on new hardware · Issue #1094 · rear/rear
https://github.com/rear/rear/issues/1094