September 24, 20241 yr Hello guys. I turn to you as the last hope. I have changed hardware and transfered my disk to a knew server. All went well and it booted up just fine. untill i was going to mount my disks. 7 out of 9 show up as no filesystem. i have done all the xfs_repair fixes that i can find on the interwebs. But i only get that it failed and i should try again. This is what xfs_repair say. Quote root@VAULT:~# xfs_repair /dev/sdc1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 2912, counted 32 sb_ifree 1564, counted 29 sb_fdblocks 45611577, counted 73198201 - 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 = 0 - agno = 3 - agno = 2 - agno = 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... SB summary counter sanity check failed Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 SB summary counter sanity check failed Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 xfs_repair: Releasing dirty buffer to free list! xfs_repair: Refusing to write a corrupt buffer to the data device! xfs_repair: Lost a write to the data device! fatal error -- File system metadata writeout failed, err=117. Re-run xfs_repair. root@VAULT:~# vault-diagnostics-20240924-2236.zip
September 25, 20241 yr Community Expert You are using a RAID controller, did that come from the old server or it's new to this server?
September 25, 20241 yr Author It is a new one. As i went from a ml350 g6to a dl380 g7. But the disks have been assign at the right spot.
September 25, 20241 yr Community Expert That can be the problem, RAID controllers should not be used, but if you use one, you usually cannot change to a different one, or a new one, and keep the data. I would recommend reconnecting the disks to the old server to see if they still mount there or if the MBR has been destroyed/changed.
September 25, 20241 yr Author Did that. Same issues. Did the xfs repair but same result. tried to convert the new raidcontroller to it mode but fails to innitiate the hp SPP after selecting what firmware to update. Did not even manage to burn the iso file to a bootable cd. 🥺 as parity and 2 other disks managed to mount im confused. tried to find a way to use testdisk software. But cant find a good bootable release.
September 25, 20241 yr Community Expert 1 hour ago, Rumint said: Did that. Same issues. Did the xfs repair but same result. RAID controllers can change the MBR, or even the partitions, you can try to see if a disk can still be emulated with the old server, and if yes, you'd need to rebuild one disk at a time, like this, if that doesn't work, best bet is to restore from a backup, or use a file recovery app like UFS explorer, if no backup is available.
September 25, 20241 yr Author sadly it does not seem to emulate the disk. and as it is a sas disk i will have to figure out how to connect it to another PC to access it with software like UFS. vault-diagnostics-20240925-1708.zip
September 25, 20241 yr Community Expert Try running xfs_repair on the emulated disk to see if that one can be repaired, start the array in maintenance mode and type xfs_repair -v /dev/md8p1
September 25, 20241 yr Author vault-diagnostics-20240925-1815.zip Sadly no progress. Quote Phase 1 - find and verify superblock... - block cache size set to 177768 entries Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - 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 = 0 - agno = 1 - agno = 2 - 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... SB summary counter sanity check failed Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 SB summary counter sanity check failed Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 xfs_repair: Releasing dirty buffer to free list! xfs_repair: Refusing to write a corrupt buffer to the data device! xfs_repair: Lost a write to the data device! fatal error -- File system metadata writeout failed, err=117. Re-run xfs_repair.
September 25, 20241 yr Community Expert You appear to still be using the new server, I mentioned trying this with the old server.
September 25, 20241 yr Author its the old server. it the same brand and model of raid card. im trying to configure the "new" server and its raid card to run in IT mode. so it is not connected to unraid at all.
September 25, 20241 yr Community Expert In that case I'm afraid that IMHO the only option is using something like UFS explorer.
September 25, 20241 yr Author i feared that. but i will report back if i managed to save it with UFS explorer. Is there any difference between UFS explorer and UFS recover?
September 25, 20241 yr Community Expert 3 hours ago, JorgeB said: If you mean UFS Explorer Standard Recovery, it's the same It appears that they are not the same and there is now a different (slightly cheaper) version. The main difference I can see that looks likely to be relevant to Unraid is the ability to handle simple ZFS file systems.
September 26, 20241 yr Community Expert 9 hours ago, itimpi said: It appears that they are not the same and there is now a different (slightly cheaper) version. AFAIK that's the one users usually get, the cheaper one, it's been available for some time.
September 26, 20241 yr Community Expert 22 minutes ago, JorgeB said: AFAIK that's the one users usually get, the cheaper one, it's been available for some time. Fair enough. I think that at the time I got a copy of UFS Explorer (many years ago now) the cheaper version was not available so I have no idea if it is as useful as I have never tried it.
October 7, 20241 yr Author So. update. i managed to recover almost every file. Thare some witout any filetyp that are left. that i cannot recover sadly. otherwise the server is back up again with new hardware. Hopefully without further issues.
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.