BrokenHalo

Sorry if I miss something here but I literally linked to this thread in OP and attached log/diagnostics from after the last crash?

Thanks for taking the time! I've re-installed most plugins after the upgrade. But since I have the same instability when running Unraid in Safe Mode, with all plugins being deactivated, I doubt it is plugin-related. Yesterday I removed Mover Tuning altogether since it caused some problems when booting.

Let's say it wasn't that bad. Ryzen 1st and 2nd Gen really don't go well with Unraid for me but at least it was usable. I'm doing nothing special, Emby and selfhosted cloud stuff. Everything else is put on hiatus until I get things stable again.

Yes I did, I came from 6.11.5. I'm afraid rolling back will not be easy due to the ZFS cache pool that has not existed before...

I've upgraded to Unraid 6.12.2 a few days ago and since then I'm having severe stability issues, bordering on the system being almost unusuable. Since I'm not sure if this is only related to the update or another issue I hope for some help. The only thing I have been changing along with the upgrade was creating a new ZFS cache pool insted of the old btrfs one. Unraid locks up multiple times a day with different behaviors, sometimes its a kernel panic, sometimes the web UI is not reachable anymore (in general the UI is very slow) but every time a hard reset is needed. Other stuff I've noticed: Docker service fails to start every other time I start the array (docker image is located on the ZFS-cache pool) I've removed the docker image and created everything from scratch multipe times now, I even switched from XFS to Directory for the docker image while the web UI is sometimes completely unreachable, some dockers can still be reached through the Cludflaredd-Tunnel even when idle, sooner or later the system will lock up, even in safe mode, even with everything stopped and only the array running What I've tried so far: running system in safe mode / de-activating every plugin/docker checking every cable connection on the disk and making sure all cache-SSDs are connected to the HBA card and not the internal SATA-ports reducing RAM speeds to 1886 MT/s and only using two sticks of RAM instead of four making sure C-states are de-activated (as per this topic) I've attached the most recent syslog and diagnostics. Hope someone can point me in the right direction. Thanks a lot in advance! nrc-syslog-20230709-1504.zip nrc-diagnostics-20230709-1700.zip

Over the last week the lock-ups occured more rapidly, so in addition to the things mentioned above I did a lot of testing, even swapping the CPU. After a lot of digging I found that either of two things seem to coincide with the lock-ups. So for anyone reading this, maybe this helps you too: SSH-Connections using the SSH-Plugin For a while I have been using this SSH-Plugin to have a more granular control. In the logs I found messages regarding SSH-connections occuring shortly before a crash/lock-up. So I deactivated and eventually removed the plugin and moved to this docker-solution, which has been working flawlessly and is even a bit better for what I need. PCIe-Confusions I'm using a GTX 1050 Ti and an LSI Host Bus Adapter as PCI-Devices with the lanes split as 2x8. After the lock-ups the display sometimes showed some cryptic error messages containing PCI-specific values. So I swapped the cards around some and allocated a full 16 PCIe-Lanes to the Graphics Card with the HBA using the remaining 4 Lanes. This seems to have done the trick. I have since gotten a few days without any hickups so I hope this has solved the problem for good.

I've been struggeling with concurring kernel panics on unRAID a few times already, mostly seeming to be connected to defective hardware. The last time I was able to point it to the RAM and since that haven't had issues for about two months. Recently now unRAID again seems to randomly lock up after a few hours of uptime (I never seem to get a full 24 hours before it happens). The one thing I noticed was, that it started happening after a update of the Nvidia-Drivers plugin. At first, every time I utilized the GPU either directly or via a docker, lock-ups would occur after a few hours of use. I rolled back to different driver-versions with no effect. Even when intentionally not utilizing the GPU at all the lock-ups happened. So I'm not sure anymore, if they are tied to the GPU or if there is a different problem. I'd much appreciate a nod in the right direction. Thanks in advance! nrc-diagnostics-20230304-1054.zip

That seems do have done the trick! That was not what I expected it to be Thanks a lot!

Thanks for helping me this far! See the diagnostics output attached. One interesting thing I found while flying over it is that the date seems to be off, also Unraid shows a 3-year plus system uptime which is nowhere near possible. CA-Logging-20220814-1547.zip

Yes, seems to work fine: root@X:~# ping raw.githubusercontent.com PING raw.githubusercontent.com (185.199.108.133) 56(84) bytes of data. 64 bytes from cdn-185-199-108-133.github.com (185.199.108.133): icmp_seq=1 ttl=59 time=13.2 ms 64 bytes from cdn-185-199-108-133.github.com (185.199.108.133): icmp_seq=2 ttl=59 time=14.2 ms 64 bytes from cdn-185-199-108-133.github.com (185.199.108.133): icmp_seq=3 ttl=59 time=14.0 ms ^C --- raw.githubusercontent.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 13.232/13.826/14.231/0.429 ms root@X:~# ping s3.amazonaws.com PING s3.amazonaws.com (52.216.109.229) 56(84) bytes of data. 64 bytes from s3-1.amazonaws.com (52.216.109.229): icmp_seq=1 ttl=235 time=102 ms 64 bytes from s3-1.amazonaws.com (52.216.109.229): icmp_seq=2 ttl=235 time=96.7 ms 64 bytes from s3-1.amazonaws.com (52.216.109.229): icmp_seq=3 ttl=235 time=97.0 ms ^C --- s3.amazonaws.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 96.693/98.615/102.192/2.531 ms

Hello! I've been trying to solve a weird networking issue and hope to find some help with it. The other day I changed the motherboard in my server due to a PCIE-issue and after the usual tinkering everything seems to work fine now except I'm not able to view the apps list and my docker containers also don't seem to be able to connect to the internet. From the Apps tab I get the following error: Download of appfeed failed. Community Applications requires your server to have internet access. The most common cause of this failure is a failure to resolve DNS addresses. You can try and reset your modem and router to fix this issue, or set static DNS addresses (Settings - Network Settings) of 208.67.222.222 and 208.67.220.220 and try again. Alternatively, there is also a chance that the server handling the application feed is temporarily down. See also this post for more information Last JSON error Recorded: Syntax error I tested different DNS-servers (OpenDNS, Cloudflare, Google, etc.) but nothing seems to change. Ping and manual resovling seems to work fine: root@X:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=20.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=19.5 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 19.503/20.083/20.663/0.580 ms root@X:~# ping google.com PING google.com (142.251.36.238) 56(84) bytes of data. 64 bytes from muc11s22-in-f14.1e100.net (142.251.36.238): icmp_seq=1 ttl=118 time=21.4 ms 64 bytes from muc11s22-in-f14.1e100.net (142.251.36.238): icmp_seq=2 ttl=118 time=18.5 ms 64 bytes from muc11s22-in-f14.1e100.net (142.251.36.238): icmp_seq=3 ttl=118 time=18.0 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 17.979/19.300/21.418/1.512 ms So I did a "reset" on my networking config, meaning I deleted the old network.cfg from /flash/config, rebooted and tried again, nothing changed. I assigned a fixed IP chained to the MAC-adress of the new motherboard, didn't help. So I'm stuck, I hope someone can point me in the right direction, I've attached the diagnostics zip below. Thanks in advance! ncr-diagnostics-20220814-1427.zip