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.

With great surprise, I was able to identify the problem. After tunneling connections, trying different protocols, and even assigning new IPs, I began resetting and disconnecting the hardware piece by piece. The culprit turned out to be the Ellipse ECO UPS. I’m more than amazed that it caused such specific effects with certain connections.

Hello everyone, I have the problem that the download speed from my Debian server (internet) to my Unraid system (local) doesn't go above 1 MB/s (it used to be 12mb/s). This issue only affects this specific connection. If I use another server (internet) or another computer (local), there’s no such limitation. So, I’m asking you pros if you have any ideas where I could take another look. It must be something related to Unraid or the router. I’ve ruled out my provider & data center since the PC doesn’t experience this limitation. I’ve ruled out the Debian server since the nginx server on wget doesn’t differentiate between Unraid and the PC. (PC <- Debian wget max speed, Unraid <- Debian wget 1 MB/s) My first thought was that there’s some kind of limit set for an endpoint, but I don’t know where to look for it. Setup: Local: PC & Unraid (same network) - FritzBox 7490 (rebooted) Internet: Debian server & ubuntu.com Tested speeds: < Tested-from ; Direction ; Source ; App ; Speed > Unraid -> Debian server rsync max speed Unraid <- Debian server rsync 1 MB/s Unraid <- Debian server iperf3 1 MB/s Unraid <- Debian server curl in docker 1 MB/s Unraid <- Debian server wget 1 MB/s Unraid <- ubuntu.com wget max speed PC <- Debian server ssh max speed PC <- Debian server wget max speed MTU is 1500 on both sides Traceroute from PC & Unraid to Debian is identical I hope someone here has a bright idea. Regars Zack

Hallo zusammen, ich habe das Problem, dass der Download-Speed von meinem Debian-Server(internet) zu meinem unraid-system(lokal) nicht über 1mb/s kommt. (war mal anders) Es betrifft aber wirklich nur diese spezifische Verbindung. Verwende ich einen anderen Server(Internet) oder einen anderen Rechner(lokal), gibt es diese Beschränkung nicht. Deshalb die Frage an euch Profis, habt Ihr eine Idee, an welcher Ecke ich nochmal schauen kann? Es muss ja was mit dem Unraid oder dem Router sein. - Mein Provider & Rechenzentrum schließe ich aus, da der PC die Beschränkung nicht hat. - Debian-Server schließe ich aus, da der nginx-Server beim wget nicht zwischen Unraid & PC unterscheiden kann. (PC<-debian wget max, Unraid<-debian wget 1mb/s) Mein erster Gedanke war, dass irgendwo ein Limit für ein Endpoint aktiviert ist, wüsste aber nicht, wo ich da suchen sollte. Aufbau: Lokal: PC & Unraid (gleiches Netz) - FritzBox 7490 Internet: Debian-Server & ubuntu.com Getestete Geschwindigkeiten: < Getestet-von ; Richtung ; Quelle ; App ; Speed > Unraid -> Debian-Server rsync max speed Unraid <- Debian-Server rsync 1mb/s Unraid <- Debian-Server ipref3 1mb/s Unraid <- Debian-Server curl im docker 1mb/s Unraid <- Debian-Server wget 1mb/s Unraid <- ubuntu.com wget max speed PC <- Debian-server ssh max speed PC <- Debian-server wget max speed mtu auf beiden 1500 traceroute PC & Unraid zu Debian gleich Ich hoffe einer von euch hat noch eine zündende Idee. VG Zack

In my case, the command also didn't solve the issue. A look into the known_hosts file revealed that the IP (not the port) was written in square brackets. After I removed those, it worked.

danke @mgutt & @DataCollector für euren Input. Ich geb mal für die Nachwelt ein Update zu der Thematik. Ein Freund und ich haben uns damals das gleiche Setup geholt. Haben beide nach längerem Hin & Her-Probieren (je verschiedene Lösungsansätze getestet) leider keine stabile Lösung gefunden. Ich bin nicht sonderlich stolz drauf, aber der Fix bestand letztendlich darin, die 2x WD Black SN850 1TB mit 2x Samsung SSD 990 PRO 2TB zu ersetzen. Seit dem läuft das System sehr stabil. Es trat nie mehr einer der Effekte auf. Off-topic: Die WD's sind dann in den Desktop gewandert. Laufen da bisher auch ohne Beanstandungen.

@DataCollector nvme's sind 2x WD Black SN850 1TB im Raid0 im btrfs (Unraid 6.12.8). Guter Hinweis. Ich teste da nochmal rum.

Ich hab jetzt mal ein paar Erfahrungen gesammelt. Komme auf ein Verbrauch im Idle von 16-17 Watt. Verbaut sind gerade 5x HDDs (Seagate Exos x18) und 2x nvme. @jj1987 Die nvme's machen auch ganz gut Probleme - siehe Bild. Da werde ich jetzt Zeitnahe etwas neues Ordern. Kurze Empfehlung? Ich schau selber auch nochmal. Aber vielen Dank für die Info. Das ersparte mir viel Recherche. @mgutt Netzteil war das "be quiet! Pure Power 12 M 650W ATX 3.0" Kontron K3842-Q2: Zum Thema Mainboard. Ich find das nach wie vor sehr Spannend. Es sei aber gesagt, dass Treiber ein kleines Problem sein können. Beispiel die Mainboard-Temperatur habe bisher ich nicht ins unraid bekommen. Auch die Management-Schnittstelle hat sich bisher vehement meiner Zugriffs-Versuche verweigert. Fractal Design Node 804: Das Gehäuse ist leiser als ich angenommen habe. Das ganze Unraid Setup ist viel Ruhiger als meine alte Synology-NAS. Das war bisher mein Zwischen-Fazit. Bild:

Hi @P0t, hi community! Unfortunately, I am experiencing the same issue. I haven't found a way to control the fans dynamically on my end either. I would be very grateful for any tips on this matter. Greetings Zack

Mal ein kleines Update, wie es mir bisher damit ergangen ist. - Das Kontron Board macht schon irgendwie Spaß, aber man muss viel nach recherchieren, da man außer das Board und eine Blende nichts mit bekommt. - Firmware-Update vom Kontron war unkompliziert. - CState bin ich leider noch noch nicht zu gekommen. Die Prio lag erst mal in herum Probieren, bevor das System Produktiv wird. - Verbrauch ist ohne Optimierung laut Shell Plug S bei 29 Watt (4 HDDs im Sleep, 2x nvme cache, 2x ssd unmounted) - Intel vPro / AMT - Management-Port habe ich bisher nicht zum laufen bekommen (Fehlt noch recherche - bsp. welche Software, etc) - eine nvme (WD Black SN850) macht gelegentlich Probleme. Die fliegt manchmal aus dem Cache-Raid1 . Bisher beim Start/Stop vom Array passiert. nur mit Neustart wieder da (jetzt mal Intel VMD im Bios aktiviert (zwecks Hot-Plug) - Idee, sie zumindest zur lauf-zeit wieder zu bekommen, bis ich evtl Austausche) - Ich hab leider ein unangenehmes Fiepen, das glaube ich vom Netzteil kommt. Da müsste ggf nochmal was am Setup geändert werden. - VM mit iGPU laufen lassen - hab ich mir leichter vorgestellt. Ich glaube, wenn ich das Produktiv nutzen möchte, müsste ich eine GPU nachrüsten. Alles andere wirkt sehr bastelig. - Cache ist schon sehr cool. Da hoffe ich noch etwas tiefer eintauchen zu können, um diesen spezifischer kalibrieren zu können. Würde mir wünschen, dass ich bestimmte Ordner-Tiefer angeben kann, die dann vorgehalten wird (bsp bei Serie = ganze Staffel) & (Film nicht die ganzen 2h von HDD). Muss ich noch recherchieren, ob das überhaupt machbar ist. - Gehäuse: Da werde ich an den Lüftern noch etwas ändern. Standard sind 2x raus, 1x rein. Ich möchte aber lieber ein Überdruck - da ich sehr staubige Umgebung & dann lieber nur durch Filter Luft gezogen werden soll. Ansonsten sehr Geräumiges Gehäuse. Da könnte man bestimmt 20x HDDs unter bekommen, wenn mans auf die Spitze treibt. Ich hab also noch eine Menge Arbeit vor mir. Ich halt euch auf jeden Fall auf dem laufenden, wie es weiter geht 🙂 VG Zack

Ich war etwas in Sorge, dass nachher das Firmware-Update bei anderen Karten Probleme machen könnte, aber ich probier dann die MZHOU PCIe SATA X4 Karte 6 Port Erweiterungskarte, ASM1166 für ~35€ RAM Ja, ECC ist erstmal vom Tisch - ist nicht so wichtig bei den geplanten Anwendungsfällen. Aber danke, dass du nochmal nach hakst.