skirven Posted August 28, 2021 Share Posted August 28, 2021 (edited) Hi folks, I re-arranged some drives from a SATA bus perspective, and also moved the Mobo and drives to another chasis, and now I can't get the drives to mount, which seems odd. - I know my Parity is probably borked at this time, and that's OK. The command xfs_repair -v /dev/md1 (and 2) runs fine, but a "blkid" doesn't list the devices, yet a "fdisk -l" clearly shows the drives and they are gpt xfs formatted. root@Tower:~# xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 737056 entries Phase 2 - using internal log - zero log... zero_log: head block 0 tail block 0 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 1 - agno = 0 - agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Sat Aug 28 17:18:08 2021 Phase Start End Duration Phase 1: 08/28 17:14:57 08/28 17:14:58 1 second Phase 2: 08/28 17:14:58 08/28 17:15:01 3 seconds Phase 3: 08/28 17:15:01 08/28 17:16:40 1 minute, 39 seconds Phase 4: 08/28 17:16:40 08/28 17:16:40 Phase 5: 08/28 17:16:40 08/28 17:16:44 4 seconds Phase 6: 08/28 17:16:44 08/28 17:18:06 1 minute, 22 seconds Phase 7: 08/28 17:18:06 08/28 17:18:06 Total run time: 3 minutes, 9 seconds done root@Tower:~# blkid /dev/loop0: TYPE="squashfs" /dev/loop1: TYPE="squashfs" /dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="7A2A-1AD5" BLOCK_SIZE="512" TYPE="vfat" /dev/sdc1: PARTUUID="78528c66-769f-4615-bb80-16e54e790894" root@Tower:~# #### root@Tower:~# fdisk -l Disk /dev/loop0: 11.98 MiB, 12562432 bytes, 24536 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 Disk /dev/loop1: 19.78 MiB, 20738048 bytes, 40504 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 Disk /dev/sda: 14.91 GiB, 16008609792 bytes, 31266816 sectors Disk model: Cruzer Fit 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: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2 31266815 31266814 14.9G b W95 FAT32 Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: ST4000VN008-2DR1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/sde: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EZRX-00S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: A86E76E5-F1A9-48B2-A90A-76DDD4A35F72 Device Start End Sectors Size Type /dev/sde1 64 5860533134 5860533071 2.7T Linux filesystem Disk /dev/sdd: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EZRX-00D Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 4748A929-FA9E-4DC8-9168-D48D8611E052 Device Start End Sectors Size Type /dev/sdd1 64 5860533134 5860533071 2.7T Linux filesystem Disk /dev/sdc: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EZRX-00S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 8CA4D20E-5072-4555-BC00-89062C80AD84 Device Start End Sectors Size Type /dev/sdc1 64 5860533134 5860533071 2.7T Linux filesystem Disk /dev/md1: 2.73 TiB, 3000592928768 bytes, 5860533064 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 Disk /dev/md2: 2.73 TiB, 3000592928768 bytes, 5860533064 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 root@Tower:~# I'm already in the process of replacing the drives, and I'm also not in a panic (yet), so I'd rather at this point, take my time and not impact this further. Any help would be appreciated! Stephen tower-diagnostics-20210828-1338.zip Edited August 31, 2021 by skirven signature line Quote Link to comment
skirven Posted August 29, 2021 Author Share Posted August 29, 2021 I also just had a random kernel panic. Might it be wise to replace the USB drive? The build was done in 2015, so it does have some age on it. -Stephen Quote Link to comment
JorgeB Posted August 29, 2021 Share Posted August 29, 2021 On the main GUI page click on each disk and change fs from auto to XFS, start array, disks should now mount. Quote Link to comment
skirven Posted August 29, 2021 Author Share Posted August 29, 2021 Well! That was a little too easy. I think I did try that, but probably not *after* the xfs_repair. I'm running some preclears on some other disks, so the array is offline, but the disk I expected to be there, was. I'll come back and close this out in a day or so, in case something else comes up. Thanks! Stephen Quote Link to comment
JorgeB Posted August 30, 2021 Share Posted August 30, 2021 14 hours ago, skirven said: but probably not *after* the xfs_repair. Unlikely that was the problem, unless there were also filesystem corruption besides the main problem, main problem is this: On 8/28/2021 at 10:21 PM, skirven said: but a "blkid" doesn't list the devices This is what Unraid uses to detect the filesystem when set to auto, since it can't detect it won't try to mount, blkid not showing correct output means something is wrong there, but you're not the first with this and as long as the filesystem is manually set it shouldn't cause any other issues, but you must remember that if in the future you do a new config you'll need to set this again. Quote Link to comment
skirven Posted August 31, 2021 Author Share Posted August 31, 2021 Solved! Thank you very much for the assist. I ended up setting up the array as xfs after the xfs_repair, and the drives mounted. I did still have kernel panics on the preclear, but I'll watch the drives, and do have a stable array at the moment. Thank you! Stephen 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.