This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1995861 - rear does not recognize intel imsm disks properly
Summary: rear does not recognize intel imsm disks properly
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rear
Version: 7.9
Hardware: x86_64
OS: All
unspecified
high
Target Milestone: rc
: ---
Assignee: Pavel Cahyna
QA Contact: CS System Management SST QE
URL:
Whiteboard:
Depends On:
Blocks: 2002810
TreeView+ depends on / blocked
 
Reported: 2021-08-20 00:23 UTC by Ryan Mullett
Modified: 2023-09-21 23:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2002810 (view as bug list)
Environment:
Last Closed: 2023-09-21 23:39:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-6957 0 None Migrated None 2023-09-21 23:39:33 UTC
Red Hat Issue Tracker RHELPLAN-94166 0 None None None 2021-08-20 00:26:09 UTC

Description Ryan Mullett 2021-08-20 00:23:48 UTC 
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 
    |          |
    |__________|__2048s Primary GPT partition table.	
    |	       |	
    |	       |	
    |	       |	
    |	       |	
    |	       |	
    |__________|__445392896s Secondary GPT partition table	
    |	       |	
    |__________|__468862128s RAID volume metadata
    +----------+ 


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
Comment 3 Pavel Cahyna 2021-09-09 18:39:09 UTC 
Yes indeed, support for this is missing and needs to be written. I did some investigation in bz1543794 already (about the same issue, but without a customer case). Since this is a new feature, I can't promise it will get added to RHEL 7, but I will at least work on it in RHEL 8.
Comment 6 RHEL Program Management 2023-09-21 23:35:39 UTC 
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 7 RHEL Program Management 2023-09-21 23:39:38 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.
Note You need to log in before you can comment on or make changes to this bug.