[Solved] [6.11.0] Disk is not recognized after upgrade to 6.11.0 from 6.9.2

[Wimpie]

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, 2022 by Wimpie

[Wimpie]

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, 2022 by Wimpie

[itimpi]

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?   

[JorgeB]

Like mentioned the solution for that is to check the filesystem on that disk.

[Wimpie]

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

[JorgeB]

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.

[Wimpie]

Ran the repair under 6.9.2 and it solved the problem.

 

Thanks