[SOLVED] "Unmountable: Unsupported partition layout" after upgrading 6.8.3 to 6.9.2

[mehappy]

SOLVED: Ran gdisk on the drive in question and everything works again.

I upgraded from 6.8.3 to 6.9.2 and noticed my disk4 is giving the message, "Unmountable: Unsupported partition layout". I haven't made any hardware changes recently. I've tried the following to no avail:

• rebooting
• reseating the power and sata cables on the drive
• restoring back to the 6.8.3 backup

 

Anyone know how to fix this, or is the best option going to be to try to format & rebuild from parity? I've attached diagnostics.

tower-diagnostics-20210820-1619.zip

Edited August 22, 2021 by mehappy

[mehappy]

Update, I ran gdisk on this as a hunch and here's the results. 
 

root@Tower:~# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.4

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: OK
Backup partition table: OK

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.
****************************************************************************

Command (? for help):   q

 

Is it a good idea to proceed to write the table to the disk? I'm not super familiar with gdisk, but saw this as a fix for someone with the same issue here: 

 

[trurl]

https://wiki.unraid.net/Manual/Storage_Management#Running_the_Test_using_the_webGui

[trurl]

1 hour ago, mehappy said:

try to format & rebuild from parity?

This would have been a very bad idea. Format is NEVER part of a rebuild.

 

Format means "write an empty filesystem to this disk". That is what it has always meant in every operating system you have ever used.

 

When you format a disk in the parity array, Unraid treats this write operation just as it does any other, by updating parity. It has to so parity remains valid. But that means if you rebuild a formatted disk, the result is a formatted disk.

[trurl]

1 hour ago, mehappy said:

ran gdisk on this as a hunch

I don't know about that one. @JorgeB wrote the post you linked, you might wait on his advice, but I suspect it is past bedtime where he is.

[mehappy]

1 hour ago, trurl said:

https://wiki.unraid.net/Manual/Storage_Management#Running_the_Test_using_the_webGui

 

I ran the check via the GUI with options -nv:
 

Phase 1 - find and verify superblock...
        - block cache size set to 679024 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 19606 tail block 19606
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 2
        - agno = 7
        - agno = 3
        - agno = 4
        - agno = 6
        - agno = 1
        - agno = 5
        - agno = 8
        - agno = 9
        - agno = 10
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

        XFS_REPAIR Summary    Fri Aug 20 19:42:59 2021

Phase		Start		End		Duration
Phase 1:	08/20 19:42:58	08/20 19:42:58
Phase 2:	08/20 19:42:58	08/20 19:42:58
Phase 3:	08/20 19:42:58	08/20 19:42:59	1 second
Phase 4:	08/20 19:42:59	08/20 19:42:59
Phase 5:	Skipped
Phase 6:	08/20 19:42:59	08/20 19:42:59
Phase 7:	08/20 19:42:59	08/20 19:42:59

Total run time: 1 second

 

[JorgeB]

11 hours ago, mehappy said:

Is it a good idea to proceed to write the table to the disk?

Yes, that might fix it, and if it doesn't there's the rebuild option.

[mehappy]

15 hours ago, JorgeB said:

Yes, that might fix it, and if it doesn't there's the rebuild option.

Won't writing the partitions using gdisk screw up screw up parity? 

Edit, is this the process to follow?

1. Stop array

2. Run gdisk

3. Assign drive back 

4. Start array

5. Maybe everything is fine? 

6. If not, how do I get Unraid to be able to mount the disk?

Edited August 21, 2021 by mehappy

[JorgeB]

9 hours ago, mehappy said:

Won't writing the partitions using gdisk screw up screw up parity? 

No, partiton info is outside parity.

 

9 hours ago, mehappy said:

3. Assign drive back 

What do you mean? You never unassign the drive, just run gdisk with the array stopped, reboot and start array normally.