mehappy Posted August 20, 2021 Share Posted August 20, 2021 (edited) 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 Quote Link to comment
mehappy Posted August 20, 2021 Author Share Posted August 20, 2021 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: Quote Link to comment
trurl Posted August 20, 2021 Share Posted August 20, 2021 https://wiki.unraid.net/Manual/Storage_Management#Running_the_Test_using_the_webGui Quote Link to comment
trurl Posted August 20, 2021 Share Posted August 20, 2021 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. Quote Link to comment
trurl Posted August 20, 2021 Share Posted August 20, 2021 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. Quote Link to comment
mehappy Posted August 20, 2021 Author Share Posted August 20, 2021 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 Quote Link to comment
JorgeB Posted August 21, 2021 Share Posted August 21, 2021 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. Quote Link to comment
mehappy Posted August 21, 2021 Author Share Posted August 21, 2021 (edited) 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 Quote Link to comment
JorgeB Posted August 22, 2021 Share Posted August 22, 2021 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.