paulmorabi

Crashes stopped after this and I replaced the RAM so seems like it was a faulty RAM stick.

Last Sunday, I removed a stick of RAM and reseated the CPU heatsink and cleaned a few other areas. I don't want to jinx myself but its been 7 days and no system freezes as yet. Looks like it is probably RAM gone bad and/or cleaning/reseating a few things has fixed it? Either way, I'll give it a couple more days and purchase replacement RAM. On RAM, is there anything I should look out for when it comes to purchasing? Given this will run 24/7, apart from ECC, anything I need to consider?

OK, had another crash with all of those BIOS changes so reverted the settings and took a stick of memory out. Will alternate if it happens again. I'm guessing its unlikely both suddenly became faulty so if its happening with both sticks then its somewhere else?

I've updated the BIOS and edited the BIOS settings to: * Disable C states * Set power supply idle control to typical current * disabled all over clocking and XMP profile. * disabled CPPC preferred cores and CPPC I noticed these were mentioned elsewhere as affecting stability especially on older Ryzen's. However, they've never caused issues before here. I also removed a USB card I no longer use and given it a general dusting inside. High temperature doesn't seem to be an issue though. The Plex error and the kernel code error occurred again overnight and it only froze an hour or so ago so probably not that either. If it crashes again, I'll revert the BIOS settings and disable all dockers, including Plex, and probably also the VM I have running. If it stays up more than 48 hours then the problem is somewhere there and I need to gradually enable things until it freezes again? I can also restore from a backup I took about ~2 months ago. If it's hardware, where do you recommend I start?

Yes, it started out of the blue last Sunday. The only thing I did prior to that was update Plex. And one week before that, edit some of the CPU pinning and isolation settings for my docker and VM.

Why that version? 6.12.3 and all other previous versions were also super stable until this started a few days back (and it was on 6.12.3 when this first happened).

Downgraded to the previous version of Plex and thought it was ok but has just happened again. Nothing in the logs beforehand that would indicate anything. syslog attached, any ideas? syslog-192.168.1.66.log

I downgraded to the previous version and will try this and then if it crashes again, disable.

Here you go. There is not much additional there. I thought it was linked to the plex issue as the following kernel message is logged at the same second. syslog-192.168.1.66.log

My Unraid server has been freezing randomly over the last few days. I've enabled syslog and the last lines recorded before the system freezing are: I'm running Plex via docker on the server with GPU pass through via an NVidia card. I've updated Plex recently also upgraded to 6.12.4. However, on the latter, the first crash happened prior to that. I've attached diagnostics and prior to this happening over the last few days had months of stability without any issues with the same setup. Any help would be appreciated. fatboy-diagnostics-20231004-0817.zip

Yes, its an LSI card in IT mode.

Perfect, thank you!

Hi, I need some advice on array expansion. I've got a SATA Card with 8 ports and currently have 8 drives connected to it in an array. One of the drives is smaller (4TB) than the others (ranging between 12TB to 16TB). I have a share configured to only be on the smaller drive for downloads. I've got a large case and would like to expand my array further. Physical space is not an immediate issue but I've seen that drives in an array should all be on the same SATA card and not mixed between different SATA cards or a SATA cards and onboard SATA. I was thinking to move the 4TB drive out of the array and swap it with a 16TB drive. Then connect the 4TB drive to my mainboard's SATA. The intention would be to keep the 4TB drive for downloads and as its a scratch disk am not too fussed if it's not protected somewhat with the parity drive. Is there a way to do this in Unraid? Would I still need to add the drive to the array? And am I effectively stuck expanding my array beyond the 8 drives due to the limited ports on the SATA card? Thanks in advance

I've got a strange issue with stale file handles and docker containers that seems better when monting via SMB rather than NFS. However, one of the docker containers I am using (gphotos-sync) uses symlinks and the unraid SMB share doesn't allow symlink creation. Is there a way to enable this?

Thanks . I just installed and didn't change any settings. It's working fine. I don't often reboot but will definitely let you know if something goes awry. Thanks for putting together the plugin

I'm looking to get this running for communicating Unraid status via SNMP with CheckMK (as the agent seems to not run well on Unraid and the plugin for it has been abandoned). From reading the previous posts, it seems there is an issue with this plugin persisting. If I proceed with setting this up, what do I need to do to make sure the rocommunity string remains public? (am very new to SNMP so excuse me if its a silly question).

Hi, After a few days of testing, I've tried the following: * The disk is connected to an LSI card. I have 2x 4-way data cables for connecting to disks. I swapped the data cable for a spare on the other cable. Still got the same error. * I have a power cable splitter that has 4x cables for connecting to disks. I swapped the power cable for an unused cable. Same error. * Replaced the power splitter cable entirely. Same error. * Plugged the disk into a free SATA power cable plug coming from the PSU. Same error. The error is: When it first occurred on Thursday, the next failure was nearly 24 hours later. It's now occurring at increasingly smaller intervals, down to only 3-4 hours. SMART extended self test reports no issues. Nothing else has changed in terms of hardware since the end of last year and between then and last week, this was never an issue. Could it be the disk or should I investigate further?

Hi, I've had a perfectly running Unraid system for a long time now and for the first time yesterday, one of the drivers in my array was disabled. The errors in syslog were: I rebooted, took the disk out of the array, added it back in and did a data re-build. Less than 24 hours and it has happened again to the same disk. SMART reports no issues. I've attached diagnostics. Any idea what this could be? Any help would be very appreciated. fatboy-diagnostics-20220812-1900.zip

Hi, has anyone been able to make a config with this plugin and the latest Unraid? The Apply button only greys out when i leave number of backups to keep and days retention to 0. Any other value and it has a red line underneath the input field and apply button does nothing. I've tried to uninstall and reinstall but now on reinstall its not showing in settings either

Thanks. I'll give it a try.

Unplugged everything and reconnected the cables, cleaned connection. It seems to be working fine. Taking a backup of everything now just in case.

Attached. fatboy-diagnostics-20220628-0547.zip

Hi, I noticed my VM's were all down and this in the logs: Jun 27 22:19:42 FatBoy kernel: nvme nvme0: I/O 44 QID 1 timeout, aborting Jun 27 22:19:42 FatBoy kernel: nvme nvme0: I/O 45 QID 1 timeout, aborting Jun 27 22:19:42 FatBoy kernel: nvme nvme0: I/O 224 QID 7 timeout, aborting Jun 27 22:19:42 FatBoy kernel: nvme nvme0: I/O 225 QID 7 timeout, aborting Jun 27 22:20:11 FatBoy kernel: nvme nvme0: I/O 29 QID 0 timeout, reset controller Jun 27 22:20:12 FatBoy kernel: nvme nvme0: I/O 44 QID 1 timeout, reset controller Jun 27 22:22:12 FatBoy kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Jun 27 22:22:12 FatBoy kernel: blk_update_request: I/O error, dev nvme0n1, sector 1230365384 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Jun 27 22:22:12 FatBoy kernel: blk_update_request: I/O error, dev nvme0n1, sector 1230238336 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Jun 27 22:22:12 FatBoy kernel: nvme nvme0: Abort status: 0x371 Jun 27 22:22:12 FatBoy kernel: nvme nvme0: Abort status: 0x371 Jun 27 22:22:12 FatBoy kernel: nvme nvme0: Abort status: 0x371 Jun 27 22:22:12 FatBoy kernel: nvme nvme0: Abort status: 0x371 Jun 27 22:23:12 FatBoy kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Jun 27 22:23:12 FatBoy kernel: nvme nvme0: Removing after probe failure status: -19 Jun 27 22:24:13 FatBoy kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Jun 27 22:24:13 FatBoy kernel: BTRFS error (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 Jun 27 22:24:13 FatBoy kernel: nvme0n1: detected capacity change from 2000409264 to 0 Jun 27 22:24:13 FatBoy kernel: BTRFS error (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 1, rd 1, flush 0, corrupt 0, gen 0 Jun 27 22:24:13 FatBoy kernel: BTRFS error (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 1, rd 2, flush 0, corrupt 0, gen 0 Jun 27 22:24:13 FatBoy kernel: blk_update_request: I/O error, dev nvme0n1, sector 1195311008 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 On reboot, my cache disk is not detected. I'm guessing it is completely dead? Is there any chance it could be recovered? Anything I can do? Thanks,

OK, thanks. I’ll wait for the next release of the kext with Monterey support and add it to my OC. Is any special configuration required? Are there any compatibility issues with the latest betas of Monterey? I was considering moving my OSX to a separate SSD and passing through a dedicated SSD rather than using an image file. When Monterey arrives, I’ll do a clean reinstall and then restore from Time Machine. If so, I’ll use the same OC EFI and get a 12.0 install image.

Is this going to be needed for upgrading to Monterey?