After building RAID in RSTe mode (IMSM), there will be an error when executing partprobe

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux
  • RSTe RAID or other fake RAID
  • Intel IMSM RAID container or VROC RAID

Issue

  • After using two disks to build RAID1 in RSTe mode and execute partprobe, the following error appears:
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/sda appears to be used, you can fix the GPT to use all of the space (an extra 26288 blocks) or continue with the current setting?
  • Getting below warning while executing fdisk -l:
GPT PMBR size mismatch (1781612543 != 1875385007) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 93772464 blocks) or continue with the current setting?   <<<<
Model: ATA SAMSUNG MZ7L3960 (scsi)
Disk /dev/sda: 1875385008s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start       End          Size         File system     Name                  Flags
 1      2048s       1230847s     1228800s     fat32           EFI System Partition  boot
 2      1230848s    135448575s   134217728s   linux-swap(v1)                        swap
 3      135448576s  1781610495s  1646161920s  xfs

Resolution

  • If this problem occurs in a non-RAID environment, please refer to parted reports "The backup GPT table is not at the end of the disk".
  • If the problem occurs on RSTe RAID or other fake RAID, this information is expected.
  • If it's an IMSM raid then you can use the IMSM's volume management capabilities to create multiple volumes instead of creating partitions over mdN device. Reach out to IMSM vendor for more information on IMSM's volume management or steps.

Root Cause

  • RSTe is fake raid and puts a signature at the end of the disks so mdraid can build the software raid using the data written by the RSTe/BIOS.
  • It's basically how all fake raid/mdraid works. They all write a signature data structure at the end of the device that mdraid can read and understand as to how to assemble the mdraid disk (number of members, raid level, stripe, etc.).

  • RSTe/BIOS when bios are set to raid and not ahci uses the same signatures on disk to figure out block mapping if the disk happens to be the boot device. If a user ran parted to build a GPT table outside of the mdN device, this will cause this type of issue.

  • Normal disk:

sdX:|--------------------------------------------------------->
    0                                                        end
    +--+---------+-----------------------------------+--------+
    |  | Primary |       ...                         | Backup |           
    |  |   GPT   |                                   |   GPT  |          
    +--+---------+-----------------------------------+--------+
  • mdN/RSTe or other fake raid disk:
mdN:|------------------------------------------->
    0                                          end           
    +--+---------+----------------------+--------+------------+
    |  | Primary |       ...            | Backup | Fake Raid  |
    |  |   GPT   |                      |   GPT  |    Info    |
    +--+---------+----------------------+--------+------------+
  • That error would be normal against a mdraid member and warnings on sdN disk should be ignored.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments