Heffe

My server has been running without error for almost a month now. The issue was a bad PCIe to NVMe adapter. (Link to the adapter) I might have just gotten unlucky with my adapter or maybe they don't work with Unraid, either way, using a proper Dell adapter solved my issue. Thanks for the kind support. =)

Update - I removed my cache drive from the system and it has been stable for about 36h now. I'm still trying to narrow down the issue precisely. I use a NVMe to PCIe adapter for my NVMe drive since my motherboard doesn't have a m.2 slot. So either it's the m.2 adapter, or my NVMe drive. My money is on the adapter. I will keep those interested updated. :-)

So does it reset the flash drive or just reset the settings on the drive?

Boo. Can you give any insight to my question?

@bonienl I have a question about the reset plugin. Does the plugin essentially "reset" the USB drive as well? Would manually resetting the USB drive be more thorough then the plugin? Thanks.

Any update on this issue? Did you find a fix?

I'm having similar symptoms and I have not found any solutions yet. Does it still error when you put it in safe mode?

Where are you seeing the call traces and segfaults? Since I've updated to 6.12.6 I have not seen any errors or segfaults. I updated around 12:30 on December 18th.

Since 6.12.6 was released, I've decided to update. I also noticed that there were some reports that macvlans were causing issues so I've changed my docker network over to ipvlans. After the update, I've had no errors in the syslog. None. Zip. Zilch. That being said, this morning when I woke up, the server was unreachable via the GUI and ssh, with no trace of an error in the log. I'm so confused as to what is causing this. I see there are some other posts descibing a similar issue. @JorgeB - Any ideas? jarvis-diagnostics-20231219-1014.zip syslog-192.168.0.10_191223.log

I'm having a similar issue with my system. You're not alone. I looked through you logs, it looks like there is a misbehaving docker container. In the "syslog-previous" it looks like something is "flip-flopping" which might be causing some issues. Have you tried booting in "safe-mode"?

Quick update: I updated my nextcloud verison to the latest version and it no longer gives the "php error" when the container is started. I sure hope that this is the cure!

So I gave it a rest and returned to the problem after a few days. I had couple of "loop2" BTRFS errors that, from what I've read on the forum, are related to a corrupt docker image. I've since deleted my docker image and recreated it. Secondly, after recreating my docker image, I pinned each docker to a specific CPU so I could find if there was an offending docker container. I think I found one. If I restart my nextcloud container while my mariadb container is running, I get: kernel: php[8525]: segfault at ffffffffffffffff ip 000055871823b0b2 sp 00007ffd6737dd40 error 7 in php82[558718200000+2b4000] likely on CPU 5 (core 1, socket 0) I get this error reliably when starting my nextcloud container. Is there anything I can do to fix this? Is my nextcloud appdata corrupt? Thanks! syslog-192.168.0.10_171223.log

I ran memtest86 for the last 24h and it didn't find any issues. There are some BTRFS errors in my logs so there might be an issue with my cache drive which is causing the whole system to stall out. I'm going to try and fix that this evening. Thank you for your reply.

Did you ever figure it out?

Well, here are the cahnges that I've tried since, 1. I changed the boot mode to UEFI instead of Legacy. 2. I downgraded the BIOS to v2.0.2 since there was a post on here suggesting that this verison was working for them. 3. I found some corrupted docker files and repaired them. The server ran for about 10 hours and then crashed again. I'm going to run Memtest86 for an extended period of time and see if that finds anything. Lol, I'm so frustrated. syslog-192.168.0.10_111223.log