Anym001

Kann ein BIOS Update bei dem Board eigentlich auch ohne eine eingesetzte CPU über die IPMI Schnittstelle gemacht werden?

Ich denk mir halt dabei, wenn die Dinger gleich viel Kosten dann möchte ich auch die Leistung haben für die ich bezahle. Es wäre das Gleiche wenn ich mir einen Porsche mit 500PS kaufe und den auf 150PS limitiere, weil ich weiß das ich die Leistung auf der Bundesstraße eh nie brauche. Und in 2 Jahren komme ich dann drauf, dass es eigentlich cool wäre eine Runde am Nürnberg-Ring zu drehen. Wo ich dann mit 150PS bei weitem nicht den Spaß habe. Ja die Leistung ist echt gigantisch. Zum schwach werden. 😅

Was spricht gegen einen 13700K, wenn der im BIOS auch begrenzt werden könnte? Zumal du hier dann noch Headroom für später übrig hättest.

Warum limitieren? Bleibt der Verbrauch nicht gleich, wenn die Aufgabe durch eine höhere Leistung schneller erledigt ist?

Ja, aber nur bei den PCIe Slots. Der Chipsatz ist 4.0: Gleiches Spiel beim Z790 Chipsatz. Dieser ist auch nur per 4.0 an die CPU angebunden. Der einzige Unterschied ist, dass vom Chipsatz mehr Lanes bereitgestellt werden. (Daher 4x vollwertige M.2 möglich - beim Z690 ist ja der 4te geshared) Sollte daher vom Vebrauch nicht viel schlechter sein. Und @T-Birth hat hier bewiesen, dass selbst mit einem Z690 ATX Board 13 Watt im Idle möglich sind.

Hast du im normalen Docker Betrieb ohne VMs auch dieses Problem mit der iGPU?

Gibt es eigentlich, außer das von Gigabyte, auch ein W680 Board mit DDR4?

Hat schon mal jemand beim MW34-SP0 den Verbrauch mit aktiviertem powertop und sämtlichen anderen Stromspareinstellungen gemessen?

Nach dem gleichen Prinzip verfahre ich auch und bin sehr zufrieden damit. Hatte auch schon meine Probleme mit btrfs. Konkret eine Frage zu deiner Backup Strategie. Machst du das Backup direkt aufs Array oder einen eigenen Datenträger außerhalb des Arrays, der beim Ausfall des Caches relativ schnell ausgetauscht werden könnte?

Ich habe die Cyberpower CP900EPFCLCD und musste das NUT Plugin installieren. Damit funktioniert nicht nur ein sauberes herunterfahren des Servers, sondern auch wieder hochfahren sobald wieder Strom verfügbar ist.

Habe die gleiche Meldung auch. Bereits bekannt und gemeldet. Sind wohl einige davon betroffen. https://github.com/nextcloud/related_resources/issues/106 Zur Info. Für die App Related Resources gibt es jetzt eine neue Version (1.0.2) Nach der Installlation in der Übersichtsseite von den Admin Einstellung auf "Erneut scannen". Danach ist der Fehler behoben.

Hatte bei diesem Update auch enorme Probleme. Mir hat er angezeigt, dass die Tabelle oc_filecache in der Datenbank defekt ist. Habe es schlussendlich mit einem truncate der Tabelle und Neubefüllung mittels folgenden Befehlen hinbekommen. docker exec -u 99 Nextcloud php occ files:scan-app-data docker exec -u 99 Nextcloud php occ files:scan --all docker exec -u 99 Nextcloud php occ maintenance:repair https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/occ_command.html

Habe die gleiche Meldung auch. Bereits bekannt und gemeldet. Sind wohl einige davon betroffen. https://github.com/nextcloud/related_resources/issues/106

@igorekDE warum verwendest du nicht einfach das "CA Appdata Backup / Restore v2" Plugin?

Siehe, wie schon von @ich777 beschrieben den Thunderbird Container. Nutze den selbst auch und bin sehr zufrieden damit. Tipp: Habe hier zusätzlich Paperless angebunden, sprich ich speichere in Thunderbird Dokumente in einen Share und die holt sich Paperless dann ab und legt sie entsprechend ab.