0

I'd like some help to understand problems I am currently experiencing with a RAID 1 Array, created from Intel RSTe and managed with mdadm.

Overall RAID 1 Configuration

Both /dev/sda and /dev/sdb are of FSTYPE isw_raid_members.

Here is the output of lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

sda                                   477G isw_raid_member   disk  
├─sda1                                512M vfat              part  
├─sda2                                488M ext2              part  
├─sda3                              452.1G crypto_LUKS       part  
└─md126                             453.1G                   raid1 
  ├─md126p1                           512M vfat              part  /boot/efi
  ├─md126p2                           488M ext2              part  /boot
  └─md126p3                         452.1G crypto_LUKS       part  
    └─isw_hggicbcjd_Volume0p3_crypt 452.1G LVM2_member       crypt 
      ├─ubuntu--vg-root             388.3G ext4              lvm   /
      └─ubuntu--vg-swap_1            63.8G swap              lvm   [SWAP]
sdb                                   477G isw_raid_member   disk  
├─sdb1                                512M vfat              part  
├─sdb2                                488M ext2              part  
├─sdb3                              452.1G crypto_LUKS       part  
└─md126                             453.1G                   raid1 
  ├─md126p1                           512M vfat              part  /boot/efi
  ├─md126p2                           488M ext2              part  /boot
  └─md126p3                         452.1G crypto_LUKS       part  
    └─isw_hggicbcjd_Volume0p3_crypt 452.1G LVM2_member       crypt 
      ├─ubuntu--vg-root             388.3G ext4              lvm   /
      └─ubuntu--vg-swap_1            63.8G swap              lvm   [SWAP]

Problems

Individual disks report the following when running sgdisk --verify /dev/sda

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

When running the same command on the array itself sgdisk --verify /dev/md126, things get messier.

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 950198272 sectors, needs to be 950198536 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 950198502, but backup header is at
950198535 and disk size is 950198272 sectors.
The 'e' option on the experts' menu will probably fix this problem

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 5 problems!

Solution

It seems like running gdisk /dev/md126

  • (r) recovery and transformation options (experts only)
  • (e) load main partition table from disk (rebuilding backup)

would make sense to fix the corrupted GPT backup but should this action be performed on /dev/md126 or on individual drives /dev/sda and /dev/sdb?

Your input would be greatly appreciated!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.