mgutt

Findest du hier vielleicht noch eine Lösung? https://forums.unraid.net/bug-reports/prereleases/code43-on-primary-gpu-passthrough-in-610rc2-r1625/

Sometimes an update kills a docker container. A good example is the InfluxDB container. The InfluxDB team changed the location of the database from /var/lib/influxdb to /var/lib/influxdb2 and the unraid template maintainer missed this part, so updating this container removes the files from appdata. But there are other examples like the MariaDB 10.6 update which broke several Nextcloud installations. Of course everyone should create backups, but most of them work only on daily basis on not exactly at the time when the user hits the update button My feature request: - a user hits the update button - unraid reminds the container version - container is removed - appdata folder files of this container are copied on the same disk/pool through "cp --reflink=always /mnt/diskX/appdata/containername/ /mnt/diskX/appdata/containername-<containerversion>-YYYYMMDDTHHIISS/" (reflink guarantees, that it won't consume (much) additional storage space) - recent container images are installed Now the user gets a note that he is able to rollback for the next three days. The rollback can be started through the usual container menu. If a rollback is done, the container repository name is automatically set to containername:<containerversion>.

Bisher wurden nur diese zwei Netzteile als besonders effizient im Niedriglastbereich ermittelt. Damit ist ein Verbrauch unter ca 20W gemeint. Andere Netzteile verschwenden in dem Bereich 3 bis 4W. Egal ob Platinum oder Gold. Ich habe zb ein Corsair SF450 Platinum, das 4W mehr als das Corsair RM550X zieht. Ob sich das allerdings finanziell lohnt, steht auf einem anderen Blatt. Muss man durchrechnen.

Das liegt vermutlich daran, weil powertop alle SATA Ports auf DIPM stellt und dadurch schmiert der Controller ab. Besser ist es, wenn du die Kommandos einzeln absetzt und das DIPM Kommando ausschließlich für die Onboard Ports verwendest. Zb so nur ein Port: echo 'med_power_with_dipm' > /sys/class/scsi_host/host3/link_power_management_policy Lass dir einfach mal alle auflisten. Die ersten X sollten die Onboard Ports sein: ls /sys/class/scsi_host/ Mehr Infos: https://forums.unraid.net/topic/104367-solved-lots-of-ata-errors-in-logs/?tab=comments#comment-963845

Nur JMB585 (5x SATA) oder ASM1166 (6x SATA) sind empfehlenswert. Alles andere ist ultralahm. Wenn es mehr Ports sein müssen, dann ginge nur eine HBA Karte.

Du musst vermutlich das letzte BIOS noch mal installieren, damit deine CPU auch ein Update erhält.

Warum hast du SMB Audit aktiv? Man kann es natürlich vergrößert, aber das ist bewusst so klein gehalten, weil die log ja im RAM liegt.

Hier posten: https://forums.unraid.net/forum/53-feature-requests/

Sehen tue ich jetzt auch nichts. Weil ich hätte dann erwartet, dass "ntpdate" einen Fehler zurückgibt. Dass dein Datum anders aussieht als bei uns, dürfte übrigens an der Einstellung liegen: Ich denke du hast da explizit DD-MM-YYYY ausgewählt und dadurch fliegt bei dir das "CEST" bei der Darstellung raus. Trotzdem sollte natürlich das Datum richtig angezeigt werden, egal was man da gewählt hat.

Genau, das ist ja mein Testserver und das Feedback dient ja mehr für Limetech und damit der Verbesserung von Unraid als für mich selbst. Daher habe ich auch gleich mal einen Bug-Report aufgemacht. Es nutzen ja massig Leute "powertop --auto-tune" oder meine Kommando-Liste in der Go-Datei und die wissen dann einfach gar nicht warum ihr Server crasht. Jetzt weiß ich zumindest warum mir mein produktiver Server so oft abgeschmiert ist, als ich die 10G Karte verbaut hatte und die Reihenfolge der Karten usw über die GUI ändern wollte. 🤪

Es ist ein halber Crash. Der Server läuft quasi noch, aber man kann nicht mehr neustarten, herunterfahren und diverse andere Dinge gehen auch nicht mehr. Das Terminal stirbt zB. Voraussetzung dafür ist, dass ich bei dieser nicht genutzten Ethernet-Buchse (eth0): 07:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-LM [8086:15f2] (rev 03) den Stromsparmodus auf "auto" stelle: echo auto | tee /sys/bus/pci/devices/0000:07:00.0/power/control Und dann danach das Kommando ausführe: ethtool eth0 Alternativ zu "ethtool" kann ich auch einfach nur in den Netzwerk-Einstellung von Unraid was ändern. Auch das führt dann zum Crash. PS der Standardwert bei diesem Device ist "on": Ich teste das jetzt auch mal mit Ubuntu. EDIT1: In Ubuntu hat man das Problem nicht. In dem Fall gibt ethtool einfach zurück, dass das Device nicht existiert, wenn man auf "auto" gestellt hat. Man kann es sogar problemlos wieder mit "on" aktivieren: ubuntu@ubuntu:~$ ethtool enp7s0 Settings for enp7s0: ... Speed: Unknown! Duplex: Unknown! (255) root@ubuntu:/home/ubuntu# echo "auto" > /sys/bus/pci/devices/0000:07:00.0/power/control root@ubuntu:/home/ubuntu# ethtool enp7s0 Settings for enp7s0: Cannot get device settings: No such device root@ubuntu:/home/ubuntu# ethtool -i enp7s0 Cannot get driver information: No such device root@ubuntu:/home/ubuntu# echo "on" > /sys/bus/pci/devices/0000:07:00.0/power/control root@ubuntu:/home/ubuntu# ethtool -i enp7s0 driver: igc version: 0.0.1-k firmware-version: expansion-rom-version: bus-info: 0000:07:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes

Ok, also ich bin mir ziemlich sicher, wann ich den quasi Server-Crash auslösen kann: - Server hat zwei LAN-Buchsen - nur in einer steckt ein Kabel - Netzwerk-Einstellungen stehen auf active-backup (Unraid Standard-Einstellung = keine network.cfg vorhanden) - "ethtool eth0" oder "ethtool eth1" lassen den Server abschmieren, je nachdem wo kein Kabel drin steckt - jetzt teste ich mal ob das auch passiert, wenn die Go File keine Stromsparkommandos enthält EDIT: Nein, kein Absturz. Also ist es eine Kombination aus Stromsparkommando und kein Kabel steckt drin. Jetzt mal herausfinden welches Kommando die Ursache ist. EDIT2: Also das passiert nur, wenn man bei allen PCIe Geräten den Stromsparmodus auf Auto stellt: echo auto | tee /sys/bus/pci/devices/????:??:??.?/power/control Ich vermute mal, dass wenn dann kein Kabel in der Buchse steckt, dass Linux die Buchse dann quasi abschaltet und wenn man dann ethtool ausführt, dass der Server dann crasht. Ich versuche nun das genaue Device zu ermitteln, welches den Bug auslöst. @ich777 Schon mal was ähnliches gehört?

Das darf nicht sein. Guckst du: Versuch mal manuell die Zeit anzupassen: ntpdate -s time1.google.com Alternativ im Debug Modus: ntpdate -d -s time1.google.com

Ok, ich konnte das problematische Kommando isolieren: for i in /sys/class/net/eth?; do dev=$(basename $i); [[ $(echo $(ethtool --show-eee $dev 2> /dev/null) | grep -c "Supported EEE link modes: 1") -eq 1 ]] && ethtool --set-eee $dev eee on; done Danach rastet "/usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3" aus und das Terminal ist komplett tot, sobald ich das gerade offene Terminal schließe: Witzigerweise wird das Kommando beim Booten über die Go-Datei ja auch gestartet. Ich starte jetzt mal neu und versuche genau zu isolieren, welcher Teil des Kommandos das Problem verursacht. EDIT1: Interessant. Jetzt startet der Server nicht mehr bzw crasht nach ca 1 Minute (sehe ich am Monitor, dann blinkt der Cursor nicht mehr bei der Eingabe des Usernames). EDIT2: So, die problematische Zeile aus der Go-Datei habe ich auskommentiert. Nun fährt der Server wieder hoch. Insgesamt hatte ich 3 Abstürze. Keinerlei Kernel-Fehler in den Logs zu finden. Auch nicht live auf dem Monitor. Allerdings habe ich massig diesen Fehler, was darauf hindeutet, dass der uralte Bug mit dem "Fenster ist noch offen und Unraid schmiert dann ab", nach wie vor präsent zu sein scheint (sollte ja eigentlich in 6.10 gelöst sein): Jun 26 12:24:31 Tower nginx: 2022/06/26 12:24:31 [error] 4268#4268: *26 limiting requests, excess: 20.202 by zone "authlimit", client: 192.168.178.21, server: , request: "GET /login HTTP/1.1", host: "tower", referrer: "http://tower/Dashboard" EDIT3: Ok, damit hätte ich wohl den Übeltäter ausgemacht. ethtool lässt den SSH Dienst crashen (man kann ab dann auch kein Array mehr stoppen und auch nicht herunterfahren, die WebGUI geht aber noch): ethtool eth0 Eine erneute Verbindung lässt sich dann auch nicht mehr aufbauen: Mag das jemand testen? Bitte aber vorher das Array stoppen, damit beim Reboot nicht direkt wieder ein Parity Check gemacht wird 😉 Ich mache jetzt noch mal einen Test, wo ich parallel "top" laufen lasse, damit ich sehe, was da eigentlich ausrastet, weil ich diesmal von extern eine SSH Verbindung aufgebaut hatte und ich kann mir eigentlich nur schwer vorstellen, dass dadurch ein PHP-Skript ausrasten kann. EDIT4: Interessant. Jetzt hat der Server einfach seine Zeit vergessen 🤔 EDIT5: Unraid hat einfach drei Dateien auf dem USB-Stick überschrieben In meinem Backup hatte die Datei noch den Zeitstempe vom 23.05.: Die NTP-Server sind auch alle weg. Standardmäßig trägt Unraid da "time1.google.com" usw ein: SSH usw war jetzt auch deaktiviert. Wie kann das bitte sein, dass Unraid einfach die Dateien überschreibt?! EDIT6: Ok, es passiert nur bei ethtool eth0 und nicht bei ethtool eth1: Ich denke das Problem ist irgendwo bei den Netzwerk-Einstellungen zu finden. Und zwar habe ich bewusst keine Einstellungen verändert. Alles Standard. Das Netzwerkkabel steckt in eth1 (MAC endet auf "DA"). In eth0 steckt kein Kabel. EDIT7: Ein Kabel in eth0 gesteckt. ethtool eth0 aufgerufen und Crash... Das hätte ich jetzt nicht erwartet. Mal sehen ob das auch nach einem Reboot so ist. EDIT8: Ok, nach einem Neustart und mit eth0 verbunden, geht nun auch ethtool eth0: Ich ändere jetzt mal die Netzwerk-Config so ab, dass eth0 das zweite Device wird und umgekehrt. EDIT9: Jetzt ist es genau umgekehrt. Nun schmiert der Server mit ethtool eth1 ab, wenn da kein Kabel drin steckt.

Du hast den Stern vergessen. So: ls -l /etc/localtime* Da der MD5 Hash aber genauso lautet wie bei mir, können wir davon ausgehen, dass auch bei dir Berlin gesetzt wurde. War denn der Wert von "date" deine aktuelle Zeit?

Was führst du alles in der Go File aus?

Eine iGPU durchschleifen hat glaube ich noch keiner geschafft. Also unwahrscheinlich, dass das klappt. Wie transcodiert der denn aktuell? Werden die beschleunigt? Alturismo hat mit zwei GPUs und einem 10th Intel und ein paar Tweaks ca 60W im Idle: Dass man das mit Alder Lake schafft, bezweifle ich. Zumindest sind die hier genannten Messwerte nicht wirklich überzeugend:

Irgendwas ist bei unRAID 6.10 komisch. Mein Testserver (W480M) verbraucht mit Stromsparkommandos wie gesagt 13W. Irgendwann steigt das aber einfach auf 19W. Wenn ich dann manuell die Stromsparkommandos wiederhole, schmiert ein Prozess ab. Irgendwas mit php/WebGUI/update_3 oder so. Danach ist das Terminal tot. Bei 6.9 kann ich die Kommandos so oft ausführen wie ich will. Der verbraucht dann auch nicht einfach mehr mit der Zeit.

Ändere mal bitte in den Datumseinstellungen die Zeitzone auf eine andere Zone und dann zurück auf Berlin.

Immer eine komplett neue VM erstellt? Bliebe noch die Option die vdisk manuell zu mounten um zu schauen ob das Dateisystem überhaupt noch in Ordnung ist.

Das sehe ich tatsächlich als Nachteil an dem Gehäuse. Bei dem Gehäuse wäre ein dauerhaft laufendes Netzteil vermutlich besser (dann nicht wie im Foto, sondern Netzteil gedreht). Aber irgendeinen Tod muss man bei kompakten Gehäusen immer sterben. Ist auch Kabelmanagement aus der Hölle 🧐

Ich baue immer effiziente semi-passive PCs, daher verstehe ich eure Sprache nicht.. nur 1 bis 2 Watt mehr ... Egal ob noch ein Lüfter dreht ... What he says? 😅

Der Lüfter vom Netzteil hat nicht die Aufgabe das PC Gehäuse zu kühlen, geschweige denn könnte er das überhaupt. Schließlich ist der Netzteillüfter entweder am Boden oder am Deckel des PC Gehäuses und die heiße Luft entweicht nach hinten. Die Platten wiederrum werden ja durch Gehäuselüfter gekühlt.

I would: - remove all changes from your go file - update the bios - load default bios settings - avoid using an USB3 port - test wiith only one RAM module - disable PCIe 4.0 (if NVMe is using it) - repair all partitions of all Array Disks and Pools.