gshipley

Awesome! Thanks mate. I have been struggling all day and this solved my issue.

Wow, late to this thread but yeah, I created and still maintain a docker for bliss and the template provided in this thread is correct. I did update it a few months ago to work correctly with file permissions. I pushed a new version yesterday actually. I should probably ping squid to get it added to community applications as I have been using it for almost 6 months with no issues.

Yeah, pretty much any subsonic client will work with this for iOS. However, you will not get the dedicated audiobook style features. My favorite one is called SubHub.

Bumping this as I am seeing the same problem...

Where is the bash_profile that gets used when unraid boots? I want to make some changes to it like: TERM=xterm But I am under the impression that if I modify the /root/.bash_profile that it will get rewritten on reboot. Maybe this isn't the case but I can't reboot my server right now to test it out.

Have you ran a reiserfck --check /dev/md(drive letter) on it? If so, did it suggest that you run with rebuild-tree?

Currently using the following: http://www.newegg.com/Product/Product.aspx?Item=N82E16817139006 CORSAIR TX Series CMPSU-750TX 750W ATX12V v2.3 SLI Ready CrossFire Ready 80 PLUS BRONZE Certified Active PFC Compatible with New 4th Gen CPU Certified Haswell Ready I also have a spare (new in box) power supply as well that is not currently being used. Rosewill ATX 12V 750-Watt 80 PLUS BRONZE Certified Power Supply Hive-750 http://www.amazon.com/gp/product/B005ILWYT6?psc=1&redirect=true&ref_=oh_aui_detailpage_o06_s00 I really appreciate the help!

Attached is the complete diagnostics information. Upon reboot the unmountable drives changed from 7, 8 and 10 to 7 and 14. hog-diagnostics-20150805-1126.zip

Yeah, sorry for the confusing wording. When I said rebuilding I did indeed mean rebuilding the data drives based off of parity. The last data drive should be rebuilt in a few minutes. I will reboot after that and provide more logs. The previous thread in question is: https://lime-technology.com/forum/index.php?topic=41875.0

Bumping this. Am I asking the question wrong or wording it so it confuses people or is it just weird error that most haven't seen and can't help out with? I honestly have searched for answers but if it is a common issue, I am happy reading doc if someone can point me to the right one.

syslog attached: If you haven't viewed my other threads, I recently upgraded my system mobo/cpu/ram and hit the virt sata add-on card problems with marvel controllers. I am using a new 8x pcix add on card with the on mobo ports to eliminate the bad cards. Once i got all the new hardware "working" things were fine for a day and then I had a drive failure (red x) with a ton of read errors. So I replaced the drive. Once parity rebuilt I had another drive failure so I replaced that one as well. Now while parity is rebuilding on that drive (I just recently rebooted) three of the drives are showing as unmountable again. disk7 for example is one that had a million read errors during party rebuilt so I did the following: reiserfsck --check /dev/md7 When that finished it wanted me to do it with a rebuild-tree. So I did that. It finally finished and I rebooted again which is when drive7 as well drive 8 and 10 are showing as unmountable. Instead of continuing down the road I have been I thought it was probably time to ask for help to see if you guys see anything in the syslog that is pointing to larger problems than just my old sata card corrupting some drives. Any help is appreciated before I throw this thing in the bin and move over to drive pools on windows (I kid, I kid). All of my non-replaceable items have been backed up at this point to other machines (pictures etc) and I just have media (movies/tv etc) that is replaceable if need be. Screenshot also attached. What makes me think its still a hardware (non drive) related issue is I am seeing these in the syslog on the brand new drive4: Aug 4 22:43:24 Hog kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 18330 does not match to the expected one 3 Aug 4 22:43:24 Hog kernel: REISERFS error (device md4): vs-5150 search_by_key: invalid format found in block 484016440. Fsck? Aug 4 22:43:24 Hog kernel: REISERFS error (device md4): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [21144 22288 0x0 SD] Maybe parity rebuilding is just rebuilding corrupted files or something? hog-syslog-20150804-2232.zip

I am currently rebuilding parity and only have 1.5 hours left. In the meantime, I thought I would brag about my new system. Before I was running anywhere from 70-100% cpu load depending on if the server was sitting idle. Memory (2gb) was around 60% when idle and 100% when doing anything of note. Check out this screenshot of the new system.

Rob, thanks for all of the help. So, I figured a few things out that may be helpful to others. I actually turned IMMU and all virt settings back on without issues. The problem did end up being both sata add-on cards in combination with virt on. On the new Mobo ( GA-Z97X-UD5H-BK) with the i7-4790k Devils Canyon CPU, my old PCI sata cards with cause these hangs every single time and sometimes system crashes. I tried both cards independently while only hooking up one drive and would still get the issues. Since these cards are so old and only support 3.0Gbs it was probably time for an upgrade anyway. Old sata add-on cards causing the issue: SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA II (3.0Gb/s) Controller Card New cards that work great out of the box: SUPERMICRO AOC-SAS2LP-MV8 PCI-Express 2.0 x8 SATA / SAS 8-Port Controller Card I think all my frustration came from the following scenario: With virt disabled, old cards worked but I still saw those reiserfs mount errors which made me think the cards were still bad. I should have paid closer attention to the logs and put two and two together. Old cards do work fine if you disable virt (as per your post in the defect/bug forum). Links to parts in question: Motherboard: http://www.newegg.com/Product/Product.aspx?Item=N82E16813128722&cm_re=ga-z97x-ud5h-bk-_-13-128-722-_-Product CPU: http://www.newegg.com/Product/Product.aspx?Item=N82E16819117369&cm_re=BX80646I74790K_i7-4790K-_-19-117-369-_-Product Old Sata add-on cards not working with virt: http://www.newegg.com/Product/Product.aspx?Item=N82E16815121009 New Sata add-on cards working with virt: http://www.newegg.com/Product/Product.aspx?Item=N82E16816101792

Yeah, the plan is to rebuild parity after I am done with all of this.

I think I figured it out..... For some reason, the journal parameter on the reiserfs drives became toast on the unmountable drives. To fix this, I run the following: # reiserfsck --check /dev/sdh1 //sdh1 is an example. Use the right one scxx for your drive that you see in the menu. reiserfs_open_journal: journal parameters from the superblock does not match to the journal headers ones. It looks like that you created your fs with old reiserfsprogs. Journal header is fixed. I hope my two days of frustration helps people in the future.... not sure how this happened to so many drive.