Zack3000

I haven't had time to look into it yet, but I'm really looking forward to your revised version of the plugin.

Aktuell ist ruhe eingekehrt. Letzter Stand war ein neu aufsetzen des Sticks und eine Anpassung in den "Syslinux configuration". Drückt mir die Daumen. Danke trotzdem für die Hilfe. Gruß Zack

Leider ist das webinterface heute wieder gecrashed - ssh funktionierte noch. hardreset war unausweichlich. Diesmal mit dem zfs dateisystem (2x nvme im raid1) # dmsg: [1999799.331490] BUG: unable to handle page fault for address: ffffffffffffffff [1999799.331502] #PF: supervisor instruction fetch in kernel mode [1999799.331507] #PF: error_code(0x0010) - not-present page [1999799.331518] Oops: Oops: 0010 [#1] PREEMPT SMP NOPTI ... [1999799.331525] CPU: 13 UID: 0 PID: 2639392 Comm: smartctl_type Tainted: P O 6.12.24-Unraid #1 ... [1999799.331588] Call Trace: <TASK> ? mast_split_data+0x3c/0x140 ? mas_push_data+0x1c6/0x210 ... ? entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ... [1999799.449552] pstore: backend (efi_pstore) writing error (-28) # freeze bei: /etc/rc.d/rc.nginx stop killall -9 nginx ps -aux | grep nginx sync # funktioniert: touch /mnt/disk*/test && /boot/test && touch /mnt/user/cache_share/test rm /mnt/disk*/test && /boot/test && /mnt/user/cache_share/test zpool status (ohne fehler) Tut mir sehr leid, euch damit wieder zu konsultieren. Ich bin mit meiner Weisheit am Ende.

Seit der Umstellung auf zfs ist kein Fehler mehr aufgetreten. Ich werde das System demnächst nochmal ausgiebig quälen, sobald ich etwas mehr Zeit habe. An der Stelle aber schon mal ein Dankeschön für euren Support.

Guter Punkt. Dank dir @DataCollector da ich kein ECC-Ram habe, ging meine Entscheidung Richtung btrfs. Aber da btrfs mit schon zwei nvme-Marken (WD, Samsung) so instabil bei mir läuft und du mir auch davon abrätst, bin ich wohl alternativ-los (Pool soll encryoted) und muss auf zfs umschwenken, auch ohne ECC. Fühlt sich aber bei einem System, dem man gerade bzgl. Stabilität nicht vertraut, nicht gut an.

Verlauf: prime95 mehrere Stunden ohne Befund memtest86+ 18h ohne Befund Update: Nun wollte ich den Cache-Pool auflösen, um Ihn mit einer SSD zu ersetzen. Beim kopieren von Cache-Pool -> Array ist folgendes passiert (das ganze log ist voll davon): Jun 13 17:04:49 BlackBox kernel: nvme nvme1: I/O tag 904 (c388) opcode 0x2 (I/O Cmd) QID 3 timeout, aborting req_op:READ(0) size:1310720 ... Jun 13 17:04:49 BlackBox kernel: nvme1n1: I/O Cmd(0x2) @ LBA 1109359768, 24 blocks, I/O Error (sct 0x0 / sc 0x7) Jun 13 17:04:49 BlackBox kernel: I/O error, dev nvme1n1, sector 1109359768 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 Jun 13 17:04:49 BlackBox kernel: nvme nvme1: Abort status: 0x0 ... Jun 13 17:05:19 BlackBox kernel: nvme nvme1: I/O tag 770 (1302) opcode 0x1 (I/O Cmd) QID 1 timeout, aborting req_op:WRITE(1) size:4096 Jun 13 17:05:19 BlackBox kernel: nvme nvme1: I/O tag 904 (c388) opcode 0x2 (I/O Cmd) QID 3 timeout, reset controller Jun 13 17:06:39 BlackBox kernel: nvme nvme1: Device not ready; aborting reset, CSTS=0x1 Jun 13 17:06:39 BlackBox kernel: nvme1n1: I/O Cmd(0x2) @ LBA 1788431416, 2560 blocks, I/O Error (sct 0x3 / sc 0x71) Jun 13 17:06:39 BlackBox kernel: I/O error, dev nvme1n1, sector 1788431416 op 0x0:(READ) flags 0x84700 phys_seg 13 prio class 0 ... Jun 13 17:06:59 BlackBox kernel: nvme nvme1: Device not ready; aborting reset, CSTS=0x1 Jun 13 17:06:59 BlackBox kernel: nvme nvme1: Disabling device after reset failure: -19 Jun 13 17:06:59 BlackBox kernel: BTRFS error (device dm-5): bdev /dev/dm-5 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 ... Jun 13 17:06:59 BlackBox kernel: BTRFS error (device dm-5): bdev /dev/dm-5 errs: wr 11, rd 0, flush 0, corrupt 0, gen 0 Jun 13 17:07:00 BlackBox kernel: BTRFS info (device dm-5): read error corrected: ino 257 off 3454656512 (dev /dev/dm-5 sector 1853626624) Jun 13 17:07:00 BlackBox kernel: BTRFS info (device dm-5): read error corrected: ino 257 off 3713122304 (dev /dev/dm-5 sector 1513048368) Jun 13 17:07:03 BlackBox kernel: BTRFS info (device dm-5): read error corrected: ino 257 off 4085223424 (dev /dev/dm-5 sector 4496672) Jun 13 17:07:04 BlackBox kernel: btrfs_dev_stat_inc_and_print: 213600 callbacks suppressed ... Beim stoppen des Arrays war auch der #1 Cache-Pool mit einem x deselected. Das Problem ließ sich nur mit einem Neustart lösen. Ich hoffe, die Fehler stehen im Zusammenhang mit meinen bisherigen, stellt mich aber vor eine neue Frage: Was ist mit meinem Cache-Pool los!? Ich hatte schon mal einen Cache-Pool aus WD Black SN850, weil die aber so instabil liefen (ähnliches Problem) wurden Sie mit den neuen Samsung 990 Pro ersetzt. Meine naive Vermutung: Mainboard ( Kontron K3842-Q2 ) ist nicht in Ordnung Unraid in Verbindung mit dem Board hat Probleme Ich hab 2x bei dem kauf von nvme's ins Klo gegriffen doch der RAM Hat einer von den Profis da eine Meinung oder ein Ratschlag für mich? Ich seh den Wald vor lauter Bäumen nicht mehr. Komplettes Setup: https://geizhals.de/wishlists/3390591 Unraid-Port zum Setup: https://forums.unraid.net/topic/147156-nas-setup-10x-sata-energiesparsame-eierlegende-wollmilchsau blackbox-diagnostics-20250613-2117.zip

18 Watt war es. Aber ich habe auch etwas das Ziel aus den Augen verloren, da ich aktuell viel mit dem System gemacht hab. Könnte vlt noch weiter optimiert werden.

Unraid gebootet. Beim starten von Docker: Jun 11 16:13:08 meinserver rc.docker: container_add_route Plex-Media-Server Jun 11 16:13:08 meinserver rc.docker: Plex-Media-Server: started successfully! Jun 11 16:13:08 meinserver rc.docker: Plex-Media-Server: wait 20 seconds Jun 11 16:13:27 meinserver kernel: Plex Tuner Serv[67512]: segfault at 58 ip 000014ebecdefd0f sp 000014ebeaf476d8 error 4 in ld-musl-x86_64.so.1[91d0f,14ebecda8000+53000] likely on CPU 6 (core 12, socket 0) Jun 11 16:13:27 meinserver kernel: Code: 00 00 00 48 8b 44 24 f8 48 89 47 20 0f 28 44 24 e8 0f 11 47 10 0f 28 44 24 d8 0f 11 07 48 85 f6 74 05 8b 06 89 47 10 31 c0 c3 <f6> 47 10 0f 75 10 b9 10 00 00 00 31 c0 f0 0f b1 0f 9b 85 c0 74 07 Jun 11 16:13:28 meinserver kernel: docker0: port 2(vethd55ab8f) entered blocking state Jun 11 16:13:28 meinserver kernel: docker0: port 2(vethd55ab8f) entered disabled state Jun 11 16:13:28 meinserver kernel: vethd55ab8f: entered allmulticast mode Jun 11 16:13:28 meinserver kernel: vethd55ab8f: entered promiscuous mode Jun 11 16:13:29 meinserver kernel: eth0: renamed from vethbfcab09 Ich fahre jetzt nochmal runter und führe auf dem verbliebenen RAM-Riegel für ein paar Stunden Memtest86+ aus. Ich hoffe wirklich, es ist nur ein kaputter RAM-Riegel...

Danke für euren Input! @alturismo einige veraltete Plugins benutze ich zwar gern, aber du hast vollkommen recht, alles runter, was das verursachen kann. Skripte laufen für backups (rsync, docker), aber würden von den crash-zeiten nicht passen. nvme_core: Meine nvme's erzeugten folgenden Fehler haufenweise: kernet: BTRFS warning (device dm-4): csum failed root 5 ino 37998 off 77824 csum Ox895S49f5 expected csum Oxa6578747 mirror 2 kernel: BTRFS error (device dm-4): bdev /dev/mapper/nvme@n1p1 errs: wr 145282695, rd 36770972, flush 1162305, corrupt239075, gen @ kernet: BTRFS info (device dm-4): read error corrected: ino 37998 off 69632 (dev /dev/mapper/nvme@n1p1 sector 186189112) kernel: pcieport AER: Corrected error message received from 0000:00:06.0 kernel: pcieport PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) kernel: pcieport device [8086:464d] error status/mask=00000001/000020000 Abhilfe schuf seit Juni.2024: nvme_core.default_ps_max_latency_us=16000 und ich meine auch pcie_acs_override war ein workaround dafür. @JorgeB : also nice Tip, i'll try, thanks! Re: Intel CPU issue. I came across it in the Unraid post and your answer. Similar Oops error related to my crash_log.txt. In idle mode, without the array and pool running, the server has now been up for almost 24 hours for the first time again - no workload Deinstalliert: ✔ folder.view.plg ✔ file.activity.plg ✔ fdupes ✔ powertop ✔ removed one RAM-bar Vielen dank schon mal an euch. Ich halte euch auf dem laufenden (I'll keep you uptodate)

Hallo liebe Unraid-Community, seit kurzem klagt mein Unraid-System über sporadische Abstürze und ich bin mit meiner Analyse an einem Punkt bin, wo ich eure Expertise gebrauchen könnte. Hardware: Mainboard: Kontron K3842-Q2 (mit aktuellstem BIOS) CPU: Intel Core i5-13600 RAM: 32GB G.Skill Ripjaws S5 (2x16GB, DDR5-5600) 2x Samsung SSD 990 PRO 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 (MZ-V9P2T0BW) Seagate Exos X - X18 18TB, 24/7, 512e/4Kn / 3.5" / SATA 6Gb/s (ST18000NM000J) SilverStone ECS06, PCIe 3.0 x4 be quiet! Pure Power 12 M 650W ATX 3.1 Eaton Ellipse ECO 650, 650VA, DIN, USB Problembeschreibung: Es kam zu mehreren Abstürzen. Einmal war die Web-UI nicht mehr erreichbar, ich konnte per ssh ein Crash-Log sichern. Ein anderes Mal half nur noch ein Hard-Reset ohne die Möglichkeit, ein Log zu speichern (während Parity-Check). Analyse der Log-Dateien: Das gesicherte Crash-Log (siehe Anhang crash_log.txt) zeigt eine "Oops: segment-related general protection fault". Der Kernel war zum Zeitpunkt des Absturzes als "Tainted" markiert (ZFS-Kernelmodule & i915-sriov Plugin). Aktueller Zustand: Das System läuft auf Unraid 7.1.2 Das System lief das letzte Jahr bisher sehr stabil. Für Fehlersuche alle SATA-HDDs (xfs-Array) abgeklemmt. Das System ist derzeit hochgefahren und einsatzbereit. Bisherige Lösungsversuche & Erkenntnisse: Memtest86+: Ein vollständiger Durchlauf wurde ohne Fehler abgeschlossen. Prime95 (mprime -t): Der Blend-Test lief über 3h stabil ohne Fehler. Cores < 46° Nächste Ideen: Idee war Cache (btrfs) mounten und das HDD-Array (xfs) abgeklemmt & abgeschaltet lassen, bis der Fehler gefunden ist. Meine Fragen an die Community: Hat jemand von euch ähnliche "General Protection Faults" im Zusammenhang mit Unraid beobachtet? Intel-CPUs der 13. und 14. Core-Generation unter Last neigten zu Instabilität durch Überhitzung - Könnte das ein Thema sein? Docker-Container können nicht dafür verantwortlich sein oder? (zuletzt paperless-ngx aufgesetzt) Habt ihr weitere Ideen oder Vorschläge, was ich prüfen könnte? Beste Grüße Zack

ok, unfortunately I have to revise my paperless-ngx suspicion. Despite the container being permanently stopped, the system crashed again. I guess I might have a similar problem. I am using the i5-13600. My checklist is as follows: memtest put the cpu under load, preferably individual cores run each RAM stick individually new Unraid USB stick How did you find out it was your Core10? On my Unraid system, in the Docker UI tab, there's a delay set in seconds when I enable autostart for a container. I believe that's the default setting. PS: it's quite a coincidence that it also falls into the period in which I'm also experimenting with paperless-ngx. Well, that's how it is sometimes with coincidences.

redis always starts before paperless-ngx. It could be, however, that Redis was restarted in between. I changed the password once, and an update might have also occurred in the meantime.

I have the exact same problem with my Unraid system since I started using Paperless-ngx. It might be a coincidence, but the issue appeared right after I set up Paperless-ngx. Since I stopped the Paperless-ngx container, the problem has not occurred again. Maybe I'm jumping to conclusions about the culprit, but I wasn't aware that a single container could cause such problems. Docker-Engine: 27.5.1 Unraid: 7.1.2 paperless-ngx:latest oops_ui_crash.txt

Genau, der Überspannungsschutz auf den RJ45 Steckverbindern war das Problem. Ich wäre dem auch schneller auf die Schliche gekommen, wenn nicht andere Endpoints wieder mit max Speed versorgt worden wären.

Mit sehr viel Überraschung konnte ich das Problem identifizieren. Nachdem ich Connections getunnelt habe, verschiedene Protokolle ausprobiert habe sogar neue IPs vergeben, fing ich an die Hardware Stück für Stück zu reseten und abzuklemmen. Übeltäter war der RJ45-Port der Ellipse ECO USV. Ich bin mehr als verwundert, dass die USV so spezifische Effekte bei bestimmten Verbindungen verursacht.