Really liking unRAID 6 so far, the new web interface is top notch! One issue I seem to have run into is when trying to use the new "Diagnostics tool" to collect my syslog and all the info we used to have to gather manually. When I run the tool the webGUI does it's thing but when it redirects me to the download I get a file not found error. Could someone tell me where this file is stored at on the machine so I can retrieve it manually?

 

 

So for some background information on how this problem arose, I had been running unRAID v5 unattended for some time now and hadn't touched the server or really done anything with in about 4 months since I have been busy with school/work. Now that the semester is over I decided this weekend would be a good time to backup my array to my mass of external hard disks in case anything catastrophic were to happen to the array. So I hooked up my first three external disks and started the copy operation and walked away.

 

I came back about 30 minutes later to check on it and received a whole slew of messages on the screen citing a kernel panic event (I apologize for this image being kind of blurry): http://gyges.feralhosting.com/weirdcrap/panic1.jpg

I attempted to retrieve a system log so I could post it here however the keyboard was completely unresponsive, the web interface was refusing any sort of connections, and I could not Telnet/SSH into the machine whatsoever. So I gave in and did a hard reboot of the machine.

 

Thinking this was just a one time fluke I started the machine, let the parity check finish, and attempted the copy operation again. This time I received a slightly different kernel panic error: http://gyges.feralhosting.com/weirdcrap/panic2.jpg

Again I was unable to gain any sort of access to the machine so I was forced to perform a hard reboot again. So I got on the forums and did some searching around and read a number of helpful threads. I shut the machine down and checked the file system on the flash drive in case it had some sort of issue, I checked the motherboard for any signs of damage (swollen caps, leakage, etc), and made sure that all the drives and cables were all connected firmly. Finding nothing amiss I attempted the copy operation one more time, mostly because I was concerned about how long it had been since I last backed up the array due to school/work obligations and once again received the first kernel panic message.

 

I considered posting here asking for help however I figured that since I was still running v5 I wouldn't get very far and most users would simply tell me to upgrade to v6 and see if the issue is fixed so I did.

 

 

Since the upgrade I have not received any more kernel panic errors so it appears that issue has been addressed however I am now receiving some reiserfs errors on Disk2 (md2 according the syslog). I am assuming these errors are due to my repeated hard reboots of the machine after the kernel panicked mid-copy. I have read the asking for help thread here: http://lime-technology.com/forum/index.php?topic=39257 and have looked over the wiki check disk filesystems page here: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems and I just wanted to clarify the proper procedure for addressing the issue.

 

 

This is the results of the reiserfs check on md2:

 

block 70254674: The level of the node (22659) is not correct, (1) expected

the problem in the internal node occured (70254674), whole subtree is skipped

bad_indirect_item: block 85863480: The item (9958 14005 0x1 IND (1), len 24, location 1088 entry count 0, fsck need 0, format new) has the bad pointer (0) to the block (75359200), which is in tree already

bad_indirect_item: block 85863480: The item (9958 14005 0x1 IND (1), len 24, location 1088 entry count 0, fsck need 0, format new) has the bad pointer (1) to the block (75359201), which is in tree already

bad_stat_data: The objectid (9961) is shared by at least two files. Can be fixed with --rebuild-tree only.

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (0) to the block (473532665), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (1) to the block (473532666), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (2) to the block (473532667), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (3) to the block (473532668), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (4) to the block (473532669), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (5) to the block (473532670), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (6) to the block (473532671), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (7) to the block (473532672), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer ( to the block (473532673), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (9) to the block (473532674), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (10) to the block (473532675), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (11) to the block (473532676), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (12) to the block (473532677), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (13) to the block (473532678), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (14) to the block (473532679), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bad pointer (15) to the block (473532680), which is in tree already

bad_indirect_item: block 85863480: The item (9960 9961 0x1 IND (1), len 340, location 364 entry count 0, fsck need 0, format new) has the bfinished

Comparing bitmaps..Bad nodes were found, Semantic pass skipped

2 found corruptions can be fixed only when running with --rebuild-tree

###########

reiserfsck finished at Sun Dec 13 17:18:33 2015

###########

 

bad_indirect_item: block 476557637: The item (9958 14006 0x1 IND (1), len 140, location 2968 entry count 0, fsck need 0, format new) has the bad pointer (34) to the block (85864329), which is in tree already

bad_stat_data: The objectid (14672) is shared by at least two files. Can be fixed with --rebuild-tree only.

vpf-10640: The on-disk and the correct bitmaps differs.

 

So based on what the check returns I should run whatever command it recommends?

Since it is telling me to run rebuild-tree I can accomplish this through the webGUI in maintenance mode or do I need to run this at the terminal? And to maintain parity I should always use the unRAID style drive reference of mdx?

As a precaution I should probably check all the other disks as well?

I've never had to do it, but here is the process for running reiserfsck.

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Running_reiserfsck

 

Since it is prompting you to --rebuild-tree it sounds like you need to.  But you may have some file damage.