DegradedArray and primary GPT table is corrupt

SwAkE · 7. Januar 2018

Hi to all, I request your help with this issue of corrupted GPT table and degraded raid.
Configuration is a raspi 3 booting from a SD card and two SSD disks on USB adapters. Worked fine for a couple of months till this appeared in the e-mail:

Code

A DegradedArray event had been detected on md device /dev/md0.
Personalities : [raid1]
md0 : active raid1 sda[1]
      244067456 blocks super 1.2 [2/1] [_U]
      bitmap: 2/2 pages [8KB], 65536KB chunk
unused devices: <none>

fdisk -l reports two primary GPT tables are corrupt:

Code

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1         8192   122879   114688   56M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       122880  7028735  6905856  3.3G 83 Linux
/dev/mmcblk0p3      7028736 31116287 24087552 11.5G 83 Linux


The primary GPT table is corrupt, but the backup appears OK, so that will be used.


Disk /dev/sda: 232.9 GiB, 250059348992 bytes, 488397166 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D262C86A-4531-4381-B68F-6E58602A358F




The primary GPT table is corrupt, but the backup appears OK, so that will be used.


Disk /dev/sdb: 232.9 GiB, 250059348992 bytes, 488397166 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6DB82E81-AFFE-4C8D-AF66-347D51D16BA5


Device     Start       End   Sectors   Size Type
/dev/sdb1   2048 488397132 488395085 232.9G Linux filesystem


Disk /dev/md0: 232.8 GiB, 249925074944 bytes, 488134912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Alles anzeigen

No error found in the output of smartctl -s on -a /dev/sda and smartctl -s on -a /dev/sdb therefor I think both disks are just fine and it is a 'logical' corruption rather than a 'physical' failure.

I guess the GPT table issue has to be solved first and then rebuild/recover the raid. The question is: how?

SwAkE · 7. Januar 2018

Some more information:
cat /proc/mdstat

Code

Personalities : [raid1]
md0 : active raid1 sda[1]
      244067456 blocks super 1.2 [2/1] [_U]
      bitmap: 2/2 pages [8KB], 65536KB chunk


unused devices: <none>

blkid

Code

/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="7D5C-A285" TYPE="vfat" PARTUUID="000b5098-01"
/dev/mmcblk0p2: LABEL="omv" UUID="5d18be51-3217-4679-9c72-a54e0fc53d6b" TYPE="ext4" PARTUUID="000b5098-02"
/dev/mmcblk0p3: UUID="fa36508a-b3c4-4499-b30a-711dd5994225" TYPE="ext4" PARTUUID="000b5098-03"
/dev/sda: UUID="7a4d2874-d310-fef1-9527-4c4f0b07ebdf" UUID_SUB="3f719b2a-5b97-bd31-1f27-7d2cfb00b536" LABEL="n-01:SSD250" TYPE="linux_raid_member"
/dev/md0: LABEL="mirror01" UUID="2d91f5fe-5fd8-416f-921e-46f8f3d7c7fb" TYPE="ext4"
/dev/sdb: UUID="7a4d2874-d310-fef1-9527-4c4f0b07ebdf" UUID_SUB="9de8b332-cbe1-62f4-59a5-8bb912b11f98" LABEL="n-01:SSD250" TYPE="linux_raid_member"
/dev/mmcblk0: PTUUID="000b5098" PTTYPE="dos"

mdadm --detail --scan --verbose

Code

ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=n-01:SSD250 UUID=7a4d2874:d310fef1:95274c4f:0b07ebdf
   devices=/dev/sda

From my understanding the above shows /dev/sdb is missing from the array.

ness1602 · 8. Januar 2018

I would still inspect this HDD better. Try with HDD sentinel.

Jetzt mitmachen!