samtrois Posted January 26, 2018 Share Posted January 26, 2018 Recently I upgraded to 6.4.0 and also installed a new HDD, though I'm not sure which happened first. I have since been having a few problems. The main 'scary' one definitely showed itself directly after the 6.4.0 update/reboot. The array is taking forever to "Start", and I put that in " " because for all intents and purposes it seems to be started, ie , all my shares are available in windows, and my dockers are starting and working (mostly, I think something is up with LetsEncrypt). There just seems to be nothing to access in 'Array Operation' on the Main tab. It does seem to come up eventually though (... I also started getting a lot of alerts from Fix Common Problems. **** /var/log is getting full (currently 100 % used) **** I have had similar issues when I first started, but that was due to pointing dockers to wrong shares and mappings etc, and has been working perfectly fine for months, so am not sure what is causing it to fill up now, maybe it is the issues with LetsEncrypt? Prior to the recent update and new HDD, I was also having trouble with some stubborn old Plex metadata files, that will not delete. tried with Krusader / Dolphin and MC. and gives some variation of "file cannot be deleted because it is in use, or because it is not empty". But strangely enough, I can rename and move the files around without a problem, and are now sitting in a share called 'Delete' From what I have seen in logs there seems to be a lot of this repeating, indicating some kind of file system corruption? Jan 26 12:20:47 Tower kernel: XFS (md5): Metadata corruption detected at xfs_inode_buf_verify+0xae/0xbe [xfs], xfs_inode block 0x6ab7f378 Jan 26 12:20:47 Tower kernel: XFS (md5): Unmount and run xfs_repair Jan 26 12:20:47 Tower kernel: XFS (md5): First 64 bytes of corrupted metadata buffer: Jan 26 12:20:47 Tower kernel: ffff880118933000: 6b f3 36 02 96 ea 88 96 5e 97 d9 10 f3 d6 cc f8 k.6.....^....... Jan 26 12:20:47 Tower kernel: ffff880118933010: 0c ac 2d 0b 24 1b 58 2a a2 06 5d a9 3e b3 28 1c ..-.$.X*..].>.(. Jan 26 12:20:47 Tower kernel: ffff880118933020: 89 ce 79 1a 21 46 9d 3d 5b 08 5c 75 ec f8 f1 33 ..y.!F.=[.\u...3 Jan 26 12:20:47 Tower kernel: ffff880118933030: 5b 4b 0d 0c 89 a1 57 b6 83 ea c8 0f ac 19 54 81 [K....W.......T. I have attached the full syslog from Diagnostics for a better look. Thanks Sam syslog.txt Link to comment
JorgeB Posted January 26, 2018 Share Posted January 26, 2018 You need to check filesystem on disk5 https://lime-technology.com/wiki/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Link to comment
samtrois Posted January 26, 2018 Author Share Posted January 26, 2018 Thanks for pointing me in the right direction, but what exactly is telling you its to do with disk 5?? Also, that link says Quote You should see a page of options for that drive, beginning with various partition, file system format, and spin down settings. The section following that is the one you want, titled Check Filesystem Status. There is a box with the 2 words Not available in it. This is the command output box, where the progress and results of the command will be displayed. Below that is the Check button that starts the test or repair, followed by the options box where you can type in options for the test/repair command. The options box may already have default options in it, for a read-only check of the file system. For more help, click the Help button in the upper right. But, I've have had to reboot since the first post, but still 2+hrs since this boot and my Array still hasn't started. Link to comment
JorgeB Posted January 26, 2018 Share Posted January 26, 2018 2 minutes ago, samtrois said: but what exactly is telling you its to do with disk 5?? Jan 26 12:20:47 Tower kernel: XFS (md5): Unmount and run xfs_repair md5=disk5 Link to comment
JorgeB Posted January 26, 2018 Share Posted January 26, 2018 4 minutes ago, samtrois said: But, I've have had to reboot since the first post, but still 2+hrs since this boot and my Array still hasn't started. It won't start until you fix disk5 Link to comment
JorgeB Posted January 26, 2018 Share Posted January 26, 2018 Forgot to mention, since you have array autostart enable you need to disable it first by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no", reboot and then start the array in maintenance mode and check filesystem on disk5. Link to comment
samtrois Posted January 26, 2018 Author Share Posted January 26, 2018 2 hours ago, johnnie.black said: Forgot to mention, since you have array autostart enable you need to disable it first by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no", reboot and then start the array in maintenance mode and check filesystem on disk5. Ok sounds doable, will I have to edit the file with the flash drive on another computer? Or should I be able to export the share? or do it in the terminal with MC? Is it weird that my file shares and dockers are working now without the array started? Link to comment
JorgeB Posted January 26, 2018 Share Posted January 26, 2018 Just now, samtrois said: Ok sounds doable, will I have to edit the file with the flash drive on another computer? Or should iI be able to export the share? or do it in the terminal with MC? Either way works. Just now, samtrois said: Is it weird that my file shares and dockers are working now without the array started? It might end up starting and you'll have your shares but the data on disk5 will be missing. Link to comment
samtrois Posted January 27, 2018 Author Share Posted January 27, 2018 So I edited the file on another computer and did the filesystem check, lots of this kind of stuff repeating. Metadata corruption detected at xfs_inode block 0x6ab7f218/0x4000 Metadata corruption detected at xfs_inode block 0x6ab7f218/0x4000 bad magic number 0x2357 on inode 2472790357 bad version number 0xffffffcc on inode 2472790357 inode identifier 15397536120431671180 mismatch on inode 2472790357 bad CRC for inode 2472790358 entry "513eb73d201d957422e978554d61b307c5adc13a" at block 0 offset 280 in directory inode 2453041179 references non-existent inode 2472790648 entry "Contents" in shortform directory 703841572 references non-existent inode 2472790659 would have junked entry "Contents" in directory inode 703841572 would clear inode number in entry at offset 280... entry "5d1a517fb35416e6a493c5885e8754a1319412a0" at block 0 offset 400 in directory inode 2453041179 references non-existent inode 2472790649 would clear inode number in entry at offset 400... entry "com.plexapp.agents.imdb" in shortform directory 5031522251 references non-existent inode 2472790544 would have junked entry "com.plexapp.agents.imdb" in directory inode 5031522251 entry ".." at block 0 offset 80 in directory inode 7280332855 references non-existent inode 2472790708 entry "com.plexapp.agents.imdb" in shortform directory 5031522258 references non-existent inode 2472790569 would have junked entry "com.plexapp.agents.imdb" in directory inode 5031522258 So I did the repair, It was surprisingly quick, and I think its all fixed. It was obvious to do with those stubborn old metadata files I couldn't delete, and I have removed them successfully. Thanks so much johnnie for your help. Link to comment
samtrois Posted January 28, 2018 Author Share Posted January 28, 2018 I seem to be stuck again "Array Starting - Starting Services" I've recently removed the listings in my Docker repositories as per the thread linked below. and have been trying to get Letsencrypt working again so there is potentially some port issue? But these syslogs are full of so much info, nothing looks as glaringly obvious as before, until the log starts spamming Jan 28 13:56:51 Tower shfs: share cache full Jan 28 13:56:51 Tower shfs: share cache full Jan 28 13:56:51 Tower shfs: share cache full EDIT: It has started now after a couple of hours, didn't change anything, so have updated the attached syslog. 1: syslog.txt 2: syslog.txt Link to comment
Squid Posted January 28, 2018 Share Posted January 28, 2018 11 hours ago, samtrois said: 1: syslog.txt 2: syslog.txt Diagnostics would be far better to see Link to comment
samtrois Posted January 28, 2018 Author Share Posted January 28, 2018 Sorry, tower-diagnostics-20180129-0749.zip Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.