AppleJon Posted January 4, 2017 Share Posted January 4, 2017 Hi, Seam like I lost acces to share and the web interface after a force reboot of the machine. I have a iKVM access to the command promt. Can ping and see the machine on the network and browse the flash folder. Any idea were I should start from? Link to comment
AppleJon Posted January 4, 2017 Author Share Posted January 4, 2017 Running V6.2.4 with one VM (windows) and 2 dockers (emby + bitsync) that auto run on startup Link to comment
JorgeB Posted January 4, 2017 Share Posted January 4, 2017 If you have console access type diagnostics and upload the zip saved to the flash drive. Link to comment
AppleJon Posted January 4, 2017 Author Share Posted January 4, 2017 Here is the log unraid6-diagnostics-20170104-0751.zip Link to comment
JorgeB Posted January 4, 2017 Share Posted January 4, 2017 You need to check filesystem on disk1 (md1). https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 Thanks for pointing me in that direction. running it now. seem to be taking quite some time and not getting any info as of yet. Will report later. Will leave it so its thing over night probably. Link to comment
JorgeB Posted January 5, 2017 Share Posted January 5, 2017 Xfs_repair doesn't usually take that long, what was the command you used? Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 xfs_repair -v /dev/md1 just have a blinking cussort after that and can type stuff in the consol but enter just jump down cant really write new comment after that so can just do a manual rebooting of the system. Could be that the drive is not responding and looking up the machine? Link to comment
JorgeB Posted January 5, 2017 Share Posted January 5, 2017 Try rebooting, xfs_repair can take some time but you should get immediate feedback on the first couple of phases, similar to: xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 170360 entries Phase 2 - using internal log - zero log... zero_log: head block 175750 tail block 175750 - scan filesystem freespace and inode maps... - found root inode chunk Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 Tried two other times and still get nothing multiple hours after I enter the command if my array is in maintenance or not up should I still be using "md1" naming? Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 can somewhat run it on other drives see attached screen grab Link to comment
JorgeB Posted January 5, 2017 Share Posted January 5, 2017 Array is not in maintenance mode. Link to comment
JorgeB Posted January 5, 2017 Share Posted January 5, 2017 You have autostart enable, so edit disk.cfg (flash\config) and change startArray="yes" to "no". Reboot and you can then access the GUI to start in maintenance mode. Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 ok getting somewere now: running with -n give me: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0x105fc7a89/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan agi unlinked bucket 20 is 1239857364 in ag 3 (inode=7682308308) sb_icount 173824, counted 173248 sb_ifree 412, counted 654 sb_fdblocks 363487512, counted 363879812 - 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 - 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 = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 7682308308, would move to lost+found Phase 7 - verify link counts... would have reset inode 7682308308 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. with -v Phase 1 - find and verify superblock... - block cache size set to 9227624 entries Phase 2 - using internal log - zero log... zero_log: head block 1146861 tail block 1145904 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Link to comment
JorgeB Posted January 5, 2017 Share Posted January 5, 2017 You need to use -L, it's normal in this situation and usually there's no data loss. Link to comment
AppleJon Posted January 5, 2017 Author Share Posted January 5, 2017 Array is back online and web interface is running also thank for the help. Did not figure auto start would behave this way and block the web access. Nice to know Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.