October 1, 20223 yr Hi, Decided to upgrade a 6.9.2 server to 6.11.0. Ran "Update Assistant" before and removed Nerdpack. "Update Assistant" said 'good to go'. After the update (running 6.11.0) disk 1 was disabled (Unmountable: Wrong or no file system). This seemed to be the only problem (did not search further). No files were accessable on disk 1, they are not simulated. I downgraded to 6.9.2, and disk 1 worked again (disk was mounted). Took a diagnostics. I can access files on disk 1, at least no problems with 1 at random chosen file. Upgraded to 6.11.0 again, and disk 1 was again disabled. Took again a diagnostics. I am now back on 6.9.2. How do I best solve this? Is there a XFS filesystem error that 6.9.2 can handle and 6.11.0 not? Would a rebuild get rid of that XFS filesystem error (or whatever the problem is)? I don't have a spare drive, could buy one, but prefer not to if not needed. tv-tower-diagnostics-6.9.2.zip tv-tower-diagnostics-6.11.0.zip Edited October 4, 20223 yr by Wimpie
October 1, 20223 yr Author It seems I misnamed the diagnostics, 6.9.2 is 6.11.0 and reversed. Anyway, I get this from 6.11.0: Oct 1 17:52:18 TV-Tower emhttpd: Mounting disks... Oct 1 17:52:20 TV-Tower emhttpd: shcmd (102): mkdir -p /mnt/disk1 Oct 1 17:52:20 TV-Tower emhttpd: shcmd (103): mount -t xfs -o noatime,nouuid /dev/md1 /mnt/disk1 Oct 1 17:52:21 TV-Tower kernel: SGI XFS with ACLs, security attributes, no debug enabled Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Metadata CRC error detected at xfs_sb_read_verify+0x11e/0x1aa [xfs], xfs_sb block 0x0 Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Unmount and run xfs_repair Oct 1 17:52:21 TV-Tower kernel: XFS (md1): First 128 bytes of corrupted metadata buffer: Oct 1 17:52:21 TV-Tower kernel: 00000000: 58 46 53 42 00 00 10 00 00 00 00 00 74 70 25 49 XFSB........tp%I Oct 1 17:52:21 TV-Tower kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Oct 1 17:52:21 TV-Tower kernel: 00000020: 24 04 07 d5 8a d8 4e 24 b9 9b ad 55 55 e3 a8 49 $.....N$...UU..I Oct 1 17:52:21 TV-Tower kernel: 00000030: 00 00 00 00 20 00 00 04 00 00 00 00 00 00 00 80 .... ........... Oct 1 17:52:21 TV-Tower kernel: 00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................ Oct 1 17:52:21 TV-Tower kernel: 00000050: 00 00 00 01 0a ea 85 1b 00 00 00 0b 00 00 00 00 ................ Oct 1 17:52:21 TV-Tower kernel: 00000060: 00 05 75 42 b4 b4 02 00 01 00 00 10 00 00 00 00 ..uB............ Oct 1 17:52:21 TV-Tower kernel: 00000070: 00 00 00 00 00 00 00 00 0c 09 08 04 1c 00 00 05 ................ Oct 1 17:52:21 TV-Tower kernel: XFS (md1): SB validate failed with error -74. Oct 1 17:52:21 TV-Tower root: mount: /mnt/disk1: mount(2) system call failed: Structure needs cleaning. Oct 1 17:52:21 TV-Tower root: dmesg(1) may have more information after failed mount system call. Oct 1 17:52:21 TV-Tower emhttpd: shcmd (103): exit status: 32 Oct 1 17:52:21 TV-Tower emhttpd: /mnt/disk1 mount error: Wrong or no file system Oct 1 17:52:21 TV-Tower emhttpd: shcmd (104): umount /mnt/disk1 Oct 1 17:52:21 TV-Tower root: umount: /mnt/disk1: not mounted. Oct 1 17:52:21 TV-Tower emhttpd: shcmd (104): exit status: 32 Oct 1 17:52:21 TV-Tower emhttpd: shcmd (105): rmdir /mnt/disk1 Oct 1 17:52:21 TV-Tower emhttpd: shcmd (106): mkdir -p /mnt/disk2 While under 6.9.2 I get: Oct 1 17:41:07 TV-Tower emhttpd: Mounting disks... Oct 1 17:41:07 TV-Tower emhttpd: shcmd (166): /sbin/btrfs device scan Oct 1 17:41:09 TV-Tower root: Scanning for Btrfs filesystems Oct 1 17:41:09 TV-Tower emhttpd: shcmd (167): mkdir -p /mnt/disk1 Oct 1 17:41:09 TV-Tower emhttpd: shcmd (168): mount -t xfs -o noatime /dev/md1 /mnt/disk1 Oct 1 17:41:09 TV-Tower kernel: SGI XFS with ACLs, security attributes, no debug enabled Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Deprecated V4 format (crc=0) will not be supported after September 2030. Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Mounting V4 Filesystem Oct 1 17:41:09 TV-Tower kernel: XFS (md1): Ending clean mount Oct 1 17:41:09 TV-Tower kernel: xfs filesystem being mounted at /mnt/disk1 supports timestamps until 2038 (0x7fffffff) Oct 1 17:41:09 TV-Tower emhttpd: shcmd (169): xfs_growfs /mnt/disk1 Oct 1 17:41:09 TV-Tower root: meta-data=/dev/md1 isize=256 agcount=11, agsize=183141659 blks Oct 1 17:41:09 TV-Tower root: = sectsz=512 attr=2, projid32bit=0 Oct 1 17:41:09 TV-Tower root: = crc=0 finobt=0, sparse=0, rmapbt=0 Oct 1 17:41:09 TV-Tower root: = reflink=0 Oct 1 17:41:09 TV-Tower root: data = bsize=4096 blocks=1953506633, imaxpct=5 Oct 1 17:41:09 TV-Tower root: = sunit=0 swidth=0 blks Oct 1 17:41:09 TV-Tower root: naming =version 2 bsize=4096 ascii-ci=0, ftype=0 Oct 1 17:41:09 TV-Tower root: log =internal log bsize=4096 blocks=357698, version=2 Oct 1 17:41:09 TV-Tower root: = sectsz=512 sunit=0 blks, lazy-count=1 Oct 1 17:41:09 TV-Tower root: realtime =none extsz=4096 blocks=0, rtextents=0 Oct 1 17:41:09 TV-Tower emhttpd: shcmd (170): mkdir -p /mnt/disk2 Nothing is changed, except the upgrade. Why do I get this with 6.11.0? Oct 1 17:52:21 TV-Tower kernel: XFS (md1): Metadata CRC error detected at xfs_sb_read_verify+0x11e/0x1aa [xfs], xfs_sb block 0x0 Edited October 1, 20223 yr by Wimpie
October 2, 20223 yr Community Expert Solution Have you tried the process described here for handling unmiountable disks in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page?
October 2, 20223 yr Community Expert Like mentioned the solution for that is to check the filesystem on that disk.
October 4, 20223 yr Author Real life is very busy, but found now some time... Running the filesystem check on disk 1 in unRAID v6.9.2 resulted in this: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x47542a, xfs_sb block 0x0/0x200 superblock has bad CRC for ag 0 would zero unused portion of primary superblock (AG #0) - 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 = 1 - agno = 0 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. So should I run the repair now without the -n flag (let it correct the error)? No problem running this under 6.9.2, or should I do it under 6.11.0? Thanks
October 4, 20223 yr Community Expert 19 minutes ago, Wimpie said: So should I run the repair now without the -n flag (let it correct the error)? Correct. I guess it can be done under either one, since this one is also detecting the problem, it's not detecting at mount like v6.11, likely due to some extra checks in the newer kernel.
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.