1

I have replaced all my 2TB disks in my raid(6) with 4TB mdadm --grow /dev/md0 --size=max and fdisk reports the following error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. and gdisk is even scarier.

root@nas:~# gdisk /dev/md0
GPT fdisk (gdisk) version 0.8.10

Warning! Read error 27; strange behavior now likely!
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 27 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

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

Bringing my raid back to it's original size corrects the problems. Should I concern myself with those error from fdisk & gdisk and what would be the correct course of action ?

3
  • It seems you may have a GPT partition table and RAID competing for the same disk space. Either you should have RAID on the disks and the GPT on /dev/md0 or you should have GPT on the disks and RAID in a partition from each disk. But you've got GPT and RAID on the full disks. I think. In this case you will get corruption - eventually - of the RAID array or its data or both May 15, 2021 at 23:15
  • My raid in on partition and not on full volumes, and then, I have a partition on the raid itself. It worked very well for year. I only got this problem now that I'm trying to change the raid size, but the problem arises only with the gpt inside the raid.
    – Camion
    May 16, 2021 at 1:50
  • Not sure if this works the same with RAID or not, using md0 in place of sdX. Be sure to have good backup. gpt partition table in middle of drive sudo gdisk /dev/sdX Command (? for help): To move backup to end of drive launch gdisk, then type x, then type e, then type w to save your changes or q to exit without change, if not correct.
    – oldfred
    May 16, 2021 at 2:33

2 Answers 2

2

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

This is expected. The backup GPT table lies at the end of your disk. If you grow (or shrink) your disk, its end mill move accordingly and thus fdisk will not be able to find the backup GPT table anymore.

Should I concern myself with those error from fdisk & gdisk and what would be the correct course of action ?

This is harmless since the main GPT table is used in normal operations. It's good to have a backup table, though, so you have to recreate it: use gdisk, don't modify the current partition table and just write it (w command) to the disk. This operation will rewrite the backup GPT too and from now on gdisk shouldn't complain anymore.

7
  • That's what I suspected. However, I still have a doubt about the mdadm: component size of /dev/md0 unchanged at ... messages
    – Camion
    May 16, 2021 at 1:55
  • @Camion This is unrelated. See mdadm's manual about --grow: you cannot specify any arbitrary value ("multiple of the chunk size, and must leave about 128Kb of space at the end of the drive"). Open a new question, with full details on your raid array, if you want -but fail- to specify anything other than max.
    – xhienne
    May 16, 2021 at 10:15
  • Yeah, ok. fair enough. This not really unrelated, but they are separable. I posted it here: unix.stackexchange.com/questions/649984/…
    – Camion
    May 16, 2021 at 23:05
  • In fact, the problem is that there is a limit at 16TB on linux md raid, which make my grown volume even smaller that it's original size.
    – Camion
    May 24, 2021 at 15:45
  • @Camion Thanks for the feedback. I don't understand why that 16T limit would allow --size=max but not --size=3751825920K which actually means the same. Anyway I'm glad you found out.
    – xhienne
    May 25, 2021 at 22:18
1

The problem was related with my using a 32bit kernel. In version 4 kernel the RAID maximum accessible size with a 32 bits kernel is RealSize modulo 16TiB, and in version 5, the maximum size is a little less than 16TiB.

So As soon as I went over 16TiB, the partitioning software was unable to read or write the secondary partition table, which is stored at the end of the disk and it caused the error 27.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .