hermy65

After reboot and parity sync started again diagnostics storage-diagnostics-20160502-2033-after.zip

This morning i started doing a parity sync and after about 5 hours it stopped and threw a notification saying that disk13 had errors and to run xfs_repair. So i did the necessary steps and ran xfs_repair -v which came back saying there was no corruption. So i started the parity sync again and now after another 4-5 hours or so it stopped and i have no idea what the issue is now. Im hoping you of you can give me some guidance as to what is happening. I have attached diagnostics from both before and after a reboot when the parity sync stopped. storage-diagnostics-20160502-2033-before.zip

I was doing a large restore yesterday and at some point my server locked up completely so i had to power it off. Today when i went tried to connect back to Crashplan to continue the restore i get this message when i go to the link in the log - http://Storage:4280/vnc.html?host=Storage&port=4280 noVNC ready: native WebSockets, canvas rendering Is that how we are supposed to be accessing Crashplan or are there better ways?

Woke up this morning and happened to notice a red X by my parity drive with the message on hover saying Parity device disabled. I checked SMART and it looks fine so i assume my next step is to do the standard: - Stop Array - Remove Disk - Start Array - Stop Array - Add Same Disk - Rebuild Parity? I have attached a syslog and diagnostics first though to make sure i dont mess something up. storage-syslog-20160501-0811.zip storage-diagnostics-20160501-0811.zip

This afternoon i had a drive start throwing errors so i stopped the rebuild and did an xfs_check -v on the drive with errors and it told me i needed to mount the drive to replay the log then run it again. Unfortunately the array will not mount as it hangs on that drive so that tells me my only option is the xfs_repair -L command but im curious as to what that actually can do since it mentions that it could cause corruption, etc. I couldn't really find any info on the -L on the forums here outside of 1 or 2 people saying they ran it and their system was working afterwards so im hoping someone can give me a bit more info on what im about to do.

I did have the array running in maintenance mode last night for a short while, i feel like when it was in maintenance mode that it maybe started doing a rebuild and i cancelled it, i dont remember clicking format after that but obviously i did. I take it that for the most part ive just lost 4TB worth of data then haven't i?

I don't believe so, i added the drive and then started the array

I had a drive go bad over the weekend so i replaced it yesterday and ran a data rebuild on it. It just finished and it did not rebuild all of the data that was on the original 4TB drive. The original drive had about ~60GB free, the new drive after rebuild is empty. I have attached diagnostics and a syslog. storage-diagnostics-20160426-1606.zip storage-syslog-20160426-1606.zip

Added a syslog EDIT: Now the Parity disk is spun down so it obviously is not doing anything EDIT2: I thought maybe i would try to repair the disk that is unmountable so i ran a reiserfsck --check /dev/md7 as trurl suggested and get: bread: Cannot read the block (2): (Input/output error). if i run reiserfsck --check /dev/sdl1 then it tells me it cannot find the superblock ---- should i do this or try some other method of getting the parity sync to work? storage-syslog-20160407-1530.zip

I stopped the array, removed the parity drive, started in maintenance mode, stopped the array, re-added the parity drive and started it back up. I got a message stating that a parity-sync had started but nowhere on the main page does it say anything about the parity sync or anything like that. I have attached a screenshot.

A majority of my drives are ReiserFS but the newest drives i have added are xfs. Do i need to remove the unmountable drive before i rebuild parity or does it really not matter. Also, if i leave it in should i repair that drive before rebuilding parity?

I used: reiserfsck --check /dev/sdl1

@trurl - would you recommend taking care of parity first then dealing with the unmountable drive or vice versa? Also, i just ran a reiserfsck --check on the unmountable drive and it tells me it cant find the superblock

@itimpi - so what is my next step? I have never rebuilt parity before so im not sure i know how to do that. Also, what do i do with the rebuilt drive that is still unmountable?

I swapped controller cards and my parity is still at a red x. I have attached updated diagnostics as well storage-diagnostics-20160407-1257.zip

When i stopped the array the slot the parity disk is supposed to be in was empty and the parity disk was listed in the unassigned devices section. I rebooted and when it came back online the correct drive was assigned to the parity slot. I started the array back up but the parity drive still has a red x. I ran a smart test and it passes everything. Im not sure diagnostics will help since its still red x but i have attached that and the syslog below. storage-diagnostics-20160407-0951.zip storage-syslog-20160407-0951.zip

Diagnostics added to first post. For reference (not sure if it matters) sdp is the original drive, sdl is the newly rebuilt drive.

I had a drive go unmountable on Monday so last night i went through the normal process of swapping drives (Stop array, unassign drive, start array, stop array, add new drive, start array, rebuild) and this morning after the rebuild was completed it says the new drive is also unmountable, on top of that now i have a red x on parity as well. I still have the old drive in the box just unassigned so i mounted it using the Unassigned Devices plugin and i can view all of the data that was on the drive in the first place. My question is more so how to handle this now. Do i format the the newly rebuilt drive and then correct my parity somehow then transfer data from the apparently ok drive back to the array? Whats my best process here for not losing data and making everything happy again. storage-diagnostics-20160407-0822.zip

Has anybody run into any issues with comictagger? Whenever i try to write tags to a book it tells me Save Failed. I did a little looking and on various forums it mentions that it cant save to cbr's without rar/unrar installed. I cant seem to locate rar/unrar in the container when doing a whereis command and i cant seem to install it either. Not sure if thats the cause but im hoping someone can lend me some input

Has anybody successfully gotten Subsonic to work behind this reverse proxy? If so, how??

Here you go, the diagnostics zip was 236kb so its larger than i can attach so here is a link to it - https://drive.google.com/file/d/0B420zM560KAfVTdLbDNMREtNODg/view?usp=sharing

Today i just started having this pop up in my syslog. When it happens things stop working well. I dont suppose you guys could point me in the right direction to resolve it Jul 23 21:43:41 Storage kernel: CPU: 3 PID: 10778 Comm: shfs Not tainted 4.0.4-unRAID #4 (Errors) Jul 23 21:43:41 Storage kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4-M, BIOS P1.40 08/14/2012 Jul 23 21:43:41 Storage kernel: task: ffff8807e95b10a0 ti: ffff8807d3964000 task.ti: ffff8807d3964000 Jul 23 21:43:41 Storage kernel: RIP: 0010:[<ffffffff8114cf24>] [<ffffffff8114cf24>] __discard_prealloc+0x98/0xb3 Jul 23 21:43:41 Storage kernel: RSP: 0018:ffff8807d3967d08 EFLAGS: 00010246 Jul 23 21:43:41 Storage kernel: RAX: ffff8805693e1e68 RBX: ffff8805693e1e40 RCX: 00000030d167940a Jul 23 21:43:41 Storage kernel: RDX: 00000030d167980a RSI: ffff8805693e1e40 RDI: ffff8807d3967e70 Jul 23 21:43:41 Storage kernel: RBP: ffff8807d3967d38 R08: 0000000000001a3c R09: 0000000000011de9 Jul 23 21:43:41 Storage kernel: R10: 00000000ffffffff R11: ffff8807d15924e0 R12: ffff8807d3967e70 Jul 23 21:43:41 Storage kernel: R13: ffff8805693e1ee0 R14: ffff8807d3967e70 R15: 0000000000000030 Jul 23 21:43:41 Storage kernel: FS: 00002b4b729e2700(0000) GS:ffff88081f2c0000(0000) knlGS:0000000000000000 Jul 23 21:43:41 Storage kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 23 21:43:41 Storage kernel: CR2: 00000030d1679412 CR3: 00000007d39c3000 CR4: 00000000001407e0 Jul 23 21:43:41 Storage kernel: Stack: Jul 23 21:43:41 Storage kernel: ffff8807e9754600 ffff8807d3967e70 ffffc90008bea000 ffffc90008c0a1e8 Jul 23 21:43:41 Storage kernel: ffff8807d3967e70 ffff8807f78d3000 ffff8807d3967d68 ffffffff8114cfa3 Jul 23 21:43:41 Storage kernel: ffff8807d3967e70 ffff8807e95b10a0 ffffc90008bea000 ffffc90008bea000 Jul 23 21:43:41 Storage kernel: Call Trace: (Errors) Jul 23 21:43:41 Storage kernel: [<ffffffff8114cfa3>] reiserfs_discard_all_prealloc+0x44/0x4e Jul 23 21:43:41 Storage kernel: [<ffffffff811697e4>] do_journal_end+0x4e7/0xc78 Jul 23 21:43:41 Storage kernel: [<ffffffff8116a4d4>] journal_end+0xae/0xb6 Jul 23 21:43:41 Storage kernel: [<ffffffff81151507>] reiserfs_mkdir+0x1d7/0x1fc Jul 23 21:43:41 Storage kernel: [<ffffffff8116cfa3>] ? reiserfs_permission+0x12/0x13 Jul 23 21:43:41 Storage kernel: [<ffffffff810ffe8b>] vfs_mkdir+0x6e/0xa8 Jul 23 21:43:41 Storage kernel: [<ffffffff8110446d>] SyS_mkdirat+0x6d/0xab Jul 23 21:43:41 Storage kernel: [<ffffffff811044bf>] SyS_mkdir+0x14/0x16 Jul 23 21:43:41 Storage kernel: [<ffffffff81604e09>] system_call_fastpath+0x12/0x17 Jul 23 21:43:41 Storage kernel: Code: 1c 75 bb 0f 0b 85 c0 74 12 48 8b 93 e8 00 00 00 4c 89 ee 4c 89 e7 e8 bf 6e 00 00 48 8b 4b 28 44 89 7b 1c 48 8d 43 28 48 8b 53 30 <48> 89 51 08 48 89 0a 48 89 43 28 48 89 43 30 58 5b 41 5c 41 5d Jul 23 21:43:41 Storage kernel: RIP [<ffffffff8114cf24>] __discard_prealloc+0x98/0xb3 Jul 23 21:43:41 Storage kernel: RSP <ffff8807d3967d08> Jul 23 21:43:41 Storage kernel: CR2: 00000030d1679412 Jul 23 21:43:41 Storage kernel: ---[ end trace 1250d29c33bb5817 ]--- Syslog is attached syslog-2015-07-23.txt

The main change is just to add a <name>KidsMedia</name> field in the advanced settings which then causes Kodi to create a new database with that name. I notice in the advnaced settings file you mention not to change anything in the sql connection section. Is there a reason outside of people just making mistakes with it?

Question for you Sparklyballs I use multiple databases to keep things separate across all of my Kodi installs. I recently switched over to your Koma container and updated the advancedsettings to reflect the custom naming scheme i use across my instances and i cant seem to get the headless kodi to do anything. The databases are working fine but the kodi install is doing nothing. Here is one of the errors i see in the kodi.log 19:36:58 T:47137496192448 ERROR: Unable to create new database 19:36:58 T:47137496192448 ERROR: Unable to open database: KidsMedia90 [2013](Lost connection to MySQL server at 'reading initial communication packet', system error: 0) The kodi instance connects and plays data from the KidsMedia90 db without issue using the kodi/kodi credentials but the headless kodi install doesnt appear to. How would i go about fixing this issue?

Im currently running Phaze's plex plugin and havent had any issues with it to date but i am curious if there are any benefits to moving plex to a container? Maybe the better question is, why would i want to move it from a plugin to a container.