Medic1

Members
  • Posts

    18
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Medic1's Achievements

Noob

Noob (1/14)

1

Reputation

  1. Fixed with the xfs_repair -vL command using the above link. Thanks.
  2. Hi all, I've had a new stable server for about a month. Yesterday while browsing through files I received a windows credential login error while accessing the shares through explorer. I didn't notice any errors with the tower but while troubleshooting I decided to do a clean reboot. Unfortunately I didn't collect diagnostics. I was able to reboot the server cleanly but I have lost access to one of my drives. Disk 1 is showing Unmountable: Wrong or no file system I have lost a significant amount of data. I have not rebuilt parity, and a parity check currently running is showing 0 errors after about 22 hours of running. I don't see the files nor the file contents any more. I don't understand how parity can be valid if there's a whole drive that's suddenly unmountable. tower-diagnostics-20230131-1353.zip
  3. Thank you. Everything looks to be working correctly now.
  4. Yes. I recently formatted to XFS and was in the process of moving data from smaller drives on to it. The drive itself is about 2 years old I think and has been working in the array with no issues until now.
  5. new diagnostics are attached. tower-diagnostics-20221228-2037.zip
  6. Ok so running the array now and the disk2 is back. The 2 nvme cache drives are still being emulated for some reason. Thoughts?
  7. Not sure. Should be on the cache drive, no?
  8. The cache drives are disabled with contents emulated. Not sure why. The cache drives are NVME and as far as I know haven't had an issue before. Repeating the test with -L gave this: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 64, counted 46400 sb_ifree 57, counted 293 sb_fdblocks 2908768556, counted 2740391589 - 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 - 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 = 4 - agno = 0 - agno = 3 - agno = 9 - agno = 2 - agno = 10 - agno = 8 - agno = 6 - agno = 7 - agno = 5 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... Maximum metadata LSN (1:103640) is ahead of log (1:8). Format log to cycle 4. done
  9. I was in the process of using unBALANCE to move data from one drive to another in order to remove a smaller drive from the array. While planning the move it appeared that none of my files were available through explorer/unraid GUI. The folder structure was there but there were no files contained in any of the folders. I decided to reboot and the array showed one of the drives (disk2) as "unmountable: wrong or no file system". I have checked the filesystem as described here: https://wiki.unraid.net/Manual/Storage_Management#Drive_shows_as_unmountable These are the results: Phase 1 - find and verify superblock... - block cache size set to 1438032 entries Phase 2 - using internal log - zero log... zero_log: head block 103768 tail block 103704 ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_icount 64, counted 46400 sb_ifree 57, counted 293 sb_fdblocks 2908768556, counted 2740391589 - 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 = 3 - agno = 2 - agno = 5 - agno = 1 - agno = 7 - agno = 6 - agno = 8 - agno = 4 - 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 Wed Dec 28 19:18:46 2022 Phase Start End Duration Phase 1: 12/28 19:18:37 12/28 19:18:37 Phase 2: 12/28 19:18:37 12/28 19:18:37 Phase 3: 12/28 19:18:37 12/28 19:18:42 5 seconds Phase 4: 12/28 19:18:42 12/28 19:18:42 Phase 5: Skipped Phase 6: 12/28 19:18:42 12/28 19:18:46 4 seconds Phase 7: 12/28 19:18:46 12/28 19:18:46 Total run time: 9 seconds I have also attached the tower diagnostics file. Can someone help with explaining how to proceed? tower-diagnostics-20221228-1932.zip
  10. Well. I'm having a good New Year's... I found the source of the problem. The VGA to DVI adapter wasn't working... Seriously. After hours of troubleshooting and starting the RMA process it comes down to a $4 part. I'm happy I didn't actually send the board off to RMA. Haha.
  11. Good point. I'll have to try to find a different vga to dvi adapter and maybe a different monitor... As for ipmi... That's something I'll have to research
  12. So I'm going through the troubleshooting process with Supermicro. I sent a video to them of the motherboard powering up and they said it appears to be working normally (except of course there's no video). He asked me to make sure the jumper was set to allow video, which it was. I checked the CPU. No bent pins. Thermal paste is the amount that came with the stock cooler. It looked fine when I checked. Confirmed i3 2100. I'm thinking about buying a new processor anyways to test that out. I need one for an HTPC build so I figure it's not wasting money. I *think* the psu is fine. It's lighting up the LEDs on the motherboard appropriately (LE7 and LE4), and the fans keep spinning so I don't think that's the problem. The other thread seemed to indicate that there was a yellow light, and the fans would stop shortly after starting. I'll keep you updated when i find out what the problem is.
  13. As for the power supply this is from the website "The latest ATX12V v2.31 and EPS 2.92 standards and it is backward compatible with ATX12V 2.2 and ATX12V 2.01 systems" A quick search didn't reveal anything about an ivy bridge i3 2100...
  14. Thanks for the replies guys. I was not aware that the i3 2100 came in an ivy bridge version. The order receipt says its sandy bridge but ill check to make sure when I get home. It's an i3 2100. Not an e3 1200