March 16, 20179 yr Hi there I just updated both my unRaid V6 servers to V6.3.2 on this machine. After a reboot I got a 'unmountable disk present' show up in the main window. I checked all connections which seem fine ... I don't think it will be the update as my 2nd machine is OK .. MB Info: Model: N/A M/B: Gigabyte Technology Co., Ltd. - Z77-D3H CPU: Intel® Core™ i3-3220 CPU @ 3.30GHz HVM: Enabled IOMMU: Disabled Cache: 64 kB, 512 kB, 3072 kB Memory: 8 GB (max. installable capacity 32 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.9.10-unRAID x86_64 OpenSSL: 1.0.2k Uptime: 0 days, 00:54:27 Main GUI window shows: Disk1: <Name & Serial No of Disk> (sde) Sorry maybe not explained enough about the problem. Not really technical. Syslog attached ... Thank you for your patience. unraid_tower-02-syslog-20170316-1434.zip
March 16, 20179 yr Community Expert You need to repair file system on disk1 (md1) https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS PS: always post the complete diagnostics, not just the syslog.
March 16, 20179 yr Author johnnie.black Thanks for quick reply, I'll try and follow the instructions on that linked page, like I said not very technical ..... BTW how do I send a 'complete diagnostics' file (for future reference). Thanks again .....
March 16, 20179 yr Community Expert Tools -> Diagnostics You can also use the GUI to repair the filesytem, though I recommend whenever possible to use the console. https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui
March 16, 20179 yr Author johnnie.black I'll use the console method..... Thanks again 'Tools -> Diagnostics' Without guys like you, where would us mere mortals be ????? !Respect!
March 16, 20179 yr Author johnnie.black Hi there again Ran the -nv option: Output: Not available Phase 1 - find and verify superblock... - block cache size set to 720680 entries Phase 2 - using internal log - zero log... zero_log: head block 253579 tail block 253575 - scan filesystem freespace and inode maps... - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 2 - agno = 3 - agno = 0 - agno = 4 - agno = 5 - agno = 6 - agno = 7 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 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (1:256931) is ahead of log (1:253579). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Mar 16 18:44:19 2017 Phase Start End Duration Phase 1: 03/16 18:44:09 03/16 18:44:09 Phase 2: 03/16 18:44:09 03/16 18:44:09 Phase 3: 03/16 18:44:09 03/16 18:44:14 5 seconds Phase 4: 03/16 18:44:14 03/16 18:44:14 Phase 5: Skipped Phase 6: 03/16 18:44:14 03/16 18:44:19 5 seconds Phase 7: 03/16 18:44:19 03/16 18:44:19 Total run time: 10 seconds Sorry I don't know what all this means Is it telling me I have a problem or is everything OK to go on to the next step Thanks ...
March 16, 20179 yr Author johnnie.black Now get this result with the '-v' option --- Not available Phase 1 - find and verify superblock... - block cache size set to 720680 entries Phase 2 - using internal log - zero log... zero_log: head block 253579 tail block 253575 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. --- help if possible
March 16, 20179 yr Author Result with the '-L' option --- Not available 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... - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 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:256946) is ahead of log (1:2). Format log to cycle 4. done ---
March 16, 20179 yr Author johnny.black Congratulations !!!!! Array back on line, you've made an old man (72) very happy....... Like I said earlier "Where would us mortals be without people like you" I need guidance Thank you very much for your very valuable time and patience...... Respect!!!!
Archived
This topic is now archived and is closed to further replies.