spall

That was the assumption I was under. Hmm. Ok. Maybe someone will chime in with the definitive on that. Otherwise, I have no idea what went south. Thanks again for commenting!

@JorgeB Unfortunately I am on the latest BIOS. Thanks again for the suggestions. I'll just blissfully ignore this in the log for now.

@itimpi I mapped to a folder inside: /tmp/intermediate. Your second point is what was confusing me, because the dashboard was reporting in the 60% range, and that was jiving with the amount of RAM use at the start of the download + the size of the file in /tmp. The server should have, at that point, had >40GB of RAM left to muck with. Am I correct in my understanding that /tmp will use whatever RAM is available? /tmp isn't the one that's only 1/2 RAM? If the latter, it would have filled it up and maybe that caused the muck up.

@itimpi Sorry! I meant /tmp on the Unraid side. I was trying to use RAM as the intermediate directory.

So I had this idea (maybe bad) to try and use /tmp for an intermediate directory in nzbget. I thought it could be faster than just hitting a cache pool with all the unpacking and moving etc. So I set it up and everything was cruising fine until it hit roughly 60% RAM usage, and my Unraid GUI started freaking out. It was constantly reloading itself, all the drives in the array would be missing, and then suddenly around a third would be present. The flash drive and everything in unassigned devices disappeared and had the loading icon constantly. Then the log went crazy with this on a loop: Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Warning: syntax error, unexpected end of file, expecting TC_DOLLAR_CURLY or TC_QUOTED_STRING or '"' in /var/local/emhttp/disks.ini on line 258 Feb 25 20:20:16 spock rc.diskinfo[27686]: in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 294 Feb 25 20:20:16 spock rc.diskinfo[27686]: PHP Exception: array_map(): Argument #2 ($array) must be of type array, bool given in /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/rc.diskinfo on line 295 I was able to shut the array down and reboot. I removed the /tmp from the container and everything is normal. But.. what happened here? And while I'm asking the question: Why was this a bad idea? Thanks!

@JorgeB Thanks for the response. That's good to know, but what are the ramifications of it? Is it telling me if there's an error in RAM it won't be able to tell me which stick had the issue? If so, is there a way to change that, or it is what it is?

Hi all, I just did a server reboot and got this in the log: mcelog: Kernel in lockdown. Cannot enable DIMM error location reporting Can someone explain this and if it is a concern? I can't say that it hasn't always been there as I just noticed it now after installing new DIMMs. Thanks for your time!

Ya know I never realized you could do that. Added to the exclusion list. Thanks!

Hallo, First, thanks for the continued work on this plugin! I had an error throw today: [12.02.2024 07:01:28][ℹ️][FoundryVTT] No stopping needed for FoundryVTT: Not started! [12.02.2024 07:01:28][❌][FoundryVTT] '/tmp/fvtt' does NOT exist! Please check your mappings! Skipping it for now. [12.02.2024 07:01:30][ℹ️][FoundryVTT] Should NOT backup external volumes, sanitizing them... [12.02.2024 07:01:30][ℹ️][FoundryVTT] Calculated volumes to back up: /mnt/user/appdata/FoundryVTT [12.02.2024 07:01:30][ℹ️][FoundryVTT] Backing up FoundryVTT... [12.02.2024 07:01:54][ℹ️][FoundryVTT] Backup created without issues [12.02.2024 07:01:54][ℹ️][FoundryVTT] Verifying backup... [12.02.2024 07:02:18][ℹ️][FoundryVTT] Starting FoundryVTT is being ignored, because it was not started before (or should not be started). The rest of the data backed up fine. Just wanted to double check that this isn't cause for greater concern. I'm ok with the bit about '/tmp/fvtt' Thanks for reading!

@JorgeB Thanks!

Finished without error. You think just treat it as an anomaly?

@JorgeB Thanks, as usual, for the feedback. Doing that thing now. Will report back when it finishes sometime in 2027.

Sure thing. Attached.

I created a new cache pool and am migrating data from the old pool->array and then plan on migrating to the new pool. Moments after I started the Mover I got this: Dec 19 20:40:42 spock kernel: critical medium error, dev sdab, sector 3907733680 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 2 Dec 19 20:40:42 spock kernel: md: disk8 read error, sector=3907733616 Dec 19 20:40:42 spock kernel: md: disk8 read error, sector=3907733624 /dev/sdab is a drive inside the array. SMART shows nothing out of the ordinary, and those are the only log entries (so far) for that drive. I do have a few larger capacity drives on hand that I've been meaning to swap in, so I don't mind replacing that one. Should I go ahead and do that? I've just never seen (to my recollection) a critical "medium" error before. No idea what that could mean. Thanks for reading!

Funny story: I have a script. It apparently helps if you set a schedule for it to actually run. The curse of setting things up at 4am and thinking you've done it correctly. Maybe I'll just set a new pool up as ZFS and diagnose the other drives in the pool at my leisure. Thanks again.

@JorgeB Thanks again for the response. I think what I'm going to do is replace both drives in that pool to get it squared on work on the situation with the MX500 (and check all my other MX500) in my test system. Let me ask: Is the correct procedure to replace the problematic SSD with a new one, let the pool rebuild, then replace the other SSD, and let it rebuild again? Is it fine that I'll be using higher capacity and will it just grow the pool after the second rebuild to the new size? EDIT: Or would it make more sense to make the new pool ZFS? Thanks!

@JorgeB Thanks for the response! I rebooted the server (which unfortunately started a parity check). It was hung forever on trying to unmount the MX500 and then must have shutdown unclean(?) So that's unfortunate. However, when it came back up it can't even see that drive anymore. So I'll try replacing the SATA cable and see, but I think given the age of that drive it might have given up the ghost. Regarding the firmware in that thread, do we consider the downloadable one safe? Or am I better putting that drive (if alive) and other MX500 I have in service into a Windows box and updating that way? I actually have a couple 500GB MX500 that I could put in to replace the pool should that drive indeed be gone, but I should update the firmware first either way it seems. Thank you.

Hi all, Log has filled up with BTRFS errors. I ran a correcting scrub and got: UUID: 22930f84-d034-4339-bdca-5b002a3e45e3 Scrub started: Sat Aug 12 19:47:45 2023 Status: finished Duration: 0:19:45 Total to scrub: 354.29GiB Rate: 306.17MiB/s Error summary: read=46387735 super=2 Corrected: 0 Uncorrectable: 46387735 Unverified: 0 Attaching diagnostics. Any help appreciated. Thanks!

@JonathanM Yeah, the settings aren't ideal. I had actually forgot about this issue (the server shutting down immediately). I had been dialing those settings lower and lower to try and test the issue and I must have left them at that when I got sidetracked some months ago. The battery could be EOL, but the unit (and battery) are less than a year old. My other servers each on their own same model UPS don't have this behavior. I should probably swap UPS and see if the problem moves with the unit itself. I'm guessing I could get a new battery under warranty. I could definitely test the method you described. It had never occurred to me to leave the data cable inline and have a dummy load on the UPS. Thank you, but yes, I don't normally have it set like this. My other two servers are on 10 minute timers. We tend to have a few ~5m outages every winter. I normally beat the servers to shutting down as I'm good about shutting off every computer in the house in an outage manually. This is actually how I discovered the instant shutdown issue on this box because I ran into an issue trying to shut the server down and it automated doing it simultaneously.

@itimpi Yeah. 100% nobody can get to the power button. However, after looking at stuff all day I discovered buried in spam (unusual, because the email is whitelisted) I had an UPS event that triggered the shutdown. We did not lose power, and none of my other servers freaked out. So that's weird. I have noticed that one a couple power outages in the past this server seems to jumps the gun on starting a shutdown on power loss. With all drives spun up the server pulls about 140W. I have it set to shutdown on 15% battery or 10 minutes of runtime. Currently it's pulling that 140W and has an estimated 56 minutes of runtime and 100% charge. Something is weird there. So I guess the mystery has changed. Also, I can't explain why the movie file stopped being readable the second time when the server was still up. As I have multiple servers, I really should look into setting up syslog server as you suggested. Thanks.

Hey all, I was watching a movie from my media server (unraid 6.11.5) via Kodi when the file suddenly stopped. I was getting an error from Kodi about an error reading file. Turns out my server had powered off. I have no idea why/how this happened, but what surprised me was that when I brought it back online it didn't start a parity check. Did it shut down cleanly for a mystery reason? Any tips on how to figure out what happened? Bonus: after resuming the film it stopped playing again and could not read the file. I expected that it had repeated itself, but the server did not shut off this time. It is possible the answer is gremlins. Thanks for any help,

all good! Thanks

I'm having issues, too. Mine is showing: plugin: updating: community.applications.plg Cleaning Up Old Versions Fixing pinned apps Setting up cron for background notifications plugin: downloading: https://raw.githubusercontent.com/Squidly271/community.applications/master/archive/community.applications-2023.02.25-x86_64-1.txz ... done plugin: bad file MD5: /boot/config/plugins/community.applications/community.applications-2023.02.25-x86_64-1.txz But the Apps tab is behaving as if I don't have CA installed at all.

So, uh.. it's been a long couple days of power outages. I completely missed the part about a _correcting_ scrub. All is well. I will mark as solved. Thanks again!

@JorgeBAwesome, thanks for the quick response! So, I followed the link, did the things, and even made the script to head this off in the future. However, stuff still seems not happy. btrfs dev stats before: [/dev/sdb1].write_io_errs 2591402 [/dev/sdb1].read_io_errs 62573 [/dev/sdb1].flush_io_errs 111764 [/dev/sdb1].corruption_errs 18 [/dev/sdb1].generation_errs 0 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs 0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 btrfs dev stats after clear: [/dev/sdb1].write_io_errs 0 [/dev/sdb1].read_io_errs 0 [/dev/sdb1].flush_io_errs 0 [/dev/sdb1].corruption_errs 0 [/dev/sdb1].generation_errs 0 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs 0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 btrfs dev stats after scrub: [/dev/sdb1].write_io_errs 0 [/dev/sdb1].read_io_errs 0 [/dev/sdb1].flush_io_errs 0 [/dev/sdb1].corruption_errs 35802 [/dev/sdb1].generation_errs 700 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs 0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 and the log file is still angry when I try to add containers back in. Thanks!