xd84
-
Posts
16 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by xd84
-
-
23 hours ago, trurl said:
So you have had no parity protection all that time.
Well, that is unfortunate, but I guess I'll have to deal with that. Does that mean that everything from the moment I took out the drive until now is gone?
23 hours ago, trurl said:That is correct when you are going to (Rebuild Parity)
Should I go ahead and start the array again to begin the Parity-Sync process?
23 hours ago, trurl said:Unrelated, but your 3 disk cache pool has different sized disks. What btrfs mode is that?
I know, I had started with one 500GB SSD and I had 2 extra 1TB SSDs that I didn't know what to do with so I threw them in the cache pool. That's how this all started. Originally, I was going to add them to my array and then I realized I could make a cache pool, so I moved the drive over to the cache pool and that's when I started to mess things up. I don't know where to find which BTRFS mode it is.
-
On 6/29/2022 at 2:47 AM, JorgeB said:
Server appears to have started based on that screenshot, errors are likely a corrupt docker image, see if you can get the diagnostics using the console.
Okay, so I got it all started up and I deleted my Docker image. I've started the process of rebuilding it, but then I saw it was throwing the error of a disk missing which is one that I had fiddled around with and took out, but never removed from my array.
I just followed this process: The "Remove Drives Then Rebuild Parity" Method from this https://wiki.unraid.net/index.php?title=Shrink_array
When I got to the end, ready to restart the array, I saw this message next to my parity drive: "All existing data on this device will be OVERWRITTEN when array is Started"
I'm running unRAID v6.9.2
-
I restarted my server earlier because I noticed it had been a while. It won't boot back up now.
Attaching a photo of screen.
-
Just now, kizer said:
I would ask for help in its own Support Forum. You might get more eyes and replies there.
Right on, thank you.
Thanks everyone for your help. I appreciate it!
-
14 minutes ago, Squid said:
It says CPU #1, Channel #0, Dimm 0. Your system event log in the BIOS may have more information
Okay, thank you. I'll check it out. I think I figured out which one it is.
On a separate note, my DelugeVPN container stopped working, is that something you guys could help me out with on here or should I post another topic?
-
Is there a way to find out which stick is bad?
-
Hi everyone, I'm running unRAID v6.9.1. I got the following error when using the Fix Common Problems plugin: "Machine Check Events detected on your server." I installed mcelog via the NerdPack plugin as suggested by Fix Common Problems and I attached a photo of the error. I am also attaching my diagnostics. I looked it up following a few of the threads on here posted under the same "Machine Check Events" topic and it seems to be a memory problem, but I'm having trouble trying to figure out which stick of memory it is. I bought this motherboard from an auction on eBay a while back. It came with the memory and CPU preinstalled and everything.
Here is my server information in case it doesn't show up on the diagnostics:
Motherboard:
Supermicro X8DT6, Version 2.02
American Megatrends Inc., Version 2.0a1
BIOS dated: Wed 05 Jan 2011 12:00:00 AM ESTProcessor:
Intel® Xeon® CPU E5620 @ 2.40GHz (x2)
Memory:
64 GiB DDR3 Multi-bit ECC Utilization: 6%
Maximum size: 384 GiB
Usable size: 62.9 GiB
-
Hi everyone, my Sonarr is giving me some trouble. I have not been able to add any new series and I have the following errors:
- All indexers are unavailable due to failures
- All search-capable indexers are temporarily unavailable due to recent indexer errors
- Failed to test proxy: http://services.sonarr.tv/v1/ping
- Unable to communicate with DelugeVPN. Unable to write data to the transport connection: The socket has been shut down.
- All download clients are unavailable due to failures
- All rss-capable indexers are temporarily unavailable due to recent indexer errors
When I do the "test" on all of my Jackett indexers, they say they're working. Deluge is still kind of downloading. It added some of the episodes, but hasn't really been downloading. Radarr hasn't been working quite right either, but there are no longer errors on it. I'm not sure where to locate any additional logs or what you all need, but I'm more than willing to do whatever I need to do to get it up and running again.
*Edited to add diagnostics
-
0 parity errors! Thank you for all of your help, @trurl!!
-
6 hours ago, trurl said:
This latest parity check (correct) found those same uncorrected parity errors, but it is correcting them.
When if finishes, run a non-correcting parity check and you should get zero parity errors.
Awesome! I'm running a non-correcting parity check now! I'll post the latest diagnostics tomorrow when it finishes. Thank you so much for your help! I truly appreciate it.
-
Okay, so I ran the parity check again. I've had my docker and VMs disabled since Friday evening and it's still saying 3385 errors. I kept the "write corrections to parity" checked. I also checked all of my connections and they were all secure.
-
Quote
We usually recommend not having automatic corrections to parity for the scheduled parity checks or the parity checks you get from an unclean shutdown. Whether or not you correct parity when running it manually depends.
Ultimately, you must correct parity, or in some cases when it seems appropriate, rebuild the specific data disk you suspect has caused parity to be out of sync. Or it may be that you have some other issues such as bad connections that when fixed will show you didn't actually have parity errors after all.
Exactly zero parity errors is the only acceptable result, and you must work on it until you get that result. After running a correcting parity check, we usually recommend following that with a non-correcting parity check to make sure you actually have exactly zero parity errors remaining, or you still have some sort of problems you need to work on.
Okay, that makes sense. How do I find the errors from the parity checks? I'll check my connections right now and I'll run another parity check tonight then I'll post the logs when it's finished.
QuoteYou have set system share to cache-only. Mover ignores cache-only shares. Set it back to cache-prefer and run Mover. It wasn't able to move it to cache before because you had Docker and VM services enabled, and mover can't move open files.
You apparently missed a lot of my posts. You should go to Settings - Docker, disable (already disabled currently) then delete docker image.
Later, after you get your problems resolved and are ready to resume using dockers, change it to the recommended 20G and enable again. It will be recreated, and you can add your dockers back exactly as they were using the Previous Apps feature on the Apps page.
If your docker image is growing, you have something misconfigured. The working data for your dockers should be in the appdata. Docker image is just for the executables.
I just set the system share to cache-prefer and ran the mover. I believe I did miss a lot of them, I have been reading a lot of things and I still don't really know what I'm doing yet, so I really do appreciate you taking the time to help me out. I deleted the docker image and set it back to 20G. I haven't enabled it yet though, I just don't want to overlook that and get stuck with 100G again like an a$$. I don't think my docker image was growing unless there was something in my logs. I think I was just thinking "I'm about to download a LOT of apps onto this thing" but I didn't know that docker only installs the parts that it doesn't have yet (which is so cool).
QuoteBut Fix Common Problems has a number of lines that indicate your server can't reach the internet. Any idea what that is about?
I'm thinking that was from earlier when I was trying to install the extra fans, I needed to plug in the power to figure out which side of the fan was sucking vs. blowing air, but my Ethernet cord wouldn't reach while I had the tower pulled out. I plugged it back in once I was finished.
-
Quote
Not sure where you got this idea. Ultimately, you must have zero parity errors. Unless you have some reason to suspect another reason for the parity errors, you must correct them.
@trurl I have been reading a lot of these forums and from some of the ones I've seen, people said it's not a good idea to have the automatic parity corrections. Maybe that was for their particular case or something.
QuoteOne likely cause of a small number of parity errors is unclean shutdowns. You must shut down from the webUI or Unraid may not be able to finish parity updates.
The number of parity errors you had is not exactly small, but it is small enough to assume you had built parity at some point and didn't do anything that would have invalidated it directly.
I generally always shutdown from the webUI, but my guess is that it's been shutting itself off from overheating and I was thinking it was my UPS or something cutting out when it was storming. Again, I'm new, reading this right now makes me feel like an idiot for not realizing sooner.
QuoteWhy have you allocated 100G to docker image? It is unlikely you would ever need even 20G and if your docker image is growing you have something configured wrong. I see it is already using 20G with only 3 dockers running so it is almost certain that you have one or more of your dockers writing into the docker image instead of to mapped storage.
I allocated 100G to the docker image before I knew what I was doing. I was under the impression that I would use a lot more than 20G, but I did not know what exactly docker was at the time, so I clearly screwed that up. From what I'm reading, I can't change it back, so I guess I'm stuck with it. I have quite a bit of docker containers, but I recently switched my setup to a new case with a new motherboard back in late December after Christmas. These problems started in January, around the 20th or so. I'm not sure if that's related or not?
QuoteYour system share has files on the array instead of all on cache where they belong.
Okay, so I just changed my settings to the cache drive. Do I need to manually move all of my files somehow or just leave it alone?
QuoteDo you have any VMs?
You should start by disabling dockers in Settings - Docker, and disabling VMs in Settings - VM Manager. Leave them disabled until we agree you have resolved your other problems.
Yes, I have a Windows 10 VM that I use a lot for school and 2 more that I don't think I've used yet, but they stay off.
QuoteAs @johnnie.black said, your CPU is overheating. You should fix that immediately.
On 3/5/2020 at 2:43 AM, johnnie.black said:Only thing I can see in the logs for now is an overheating CPU, fix that then post clean diags.
@johnnie.black @trurl Okay, so I took the old thermal paste off and applied a new coat to both CPUs and I added 3 more fans to the inside until I can get a better setup. I'm attaching my new diagnostics that I just downloaded after I turned everything off.
-
Hi everyone,
I'm running unRAID Version: 6.8.2
I am semi-new to this system and I did not realize it was not good to write corrections to parity. I've been trying to figure out the problem and I cannot. Sonarr and Radarr are not communicating with any of my indexers through Jackett, so I tried Cardigann, still no luck. Deluge won't open anymore, when I try to open the webGUI, it says "page not found". I tried different browsers with no luck. I tried to switch to qBittorrent with no luck there either. I'm hoping someone here can help me figure out what's going on with my system or point me in the right direction.
Thank you in advance.
alienblood-diagnostics-20200304-2319.zip
BTRFS: error (device loop3) in cleanup_transaction:1942: errno=-5 IO failure
in General Support
Posted
Okay, I just started the array and the Parity-Sync has begun. Here are my diagnostics from just now:
alienblood-diagnostics-20220702-1012.zip