i-B4se

Das geht auch nicht. Dann rufst du ja wieder diene interne IP auf und darüber gibt es kein Zertifikat bzw. https Wenn du Valtwarden nutzen/verwalten möchtest, dann geht das nur über die Domain.

Du meinst wenn du das WebGUI aufrufst und in der Übersicht bist, dann starten ein paar Platten? Das ist definitiv nicht normal und sollte auch nicht sein. Ich habe auch die Version 6.11.5

Mahlzeit, ich habe gerade meine drei Switches geupdatet und dann wurden mir in Unraid folgende Fehlermeldungen im Protokoll hinterlegt: Nov 26 16:15:54 NAS kernel: igb 0000:27:00.0 eth1: igb: eth1 NIC Link is Down Nov 26 16:15:54 NAS kernel: igb 0000:26:00.0 eth0: igb: eth0 NIC Link is Down Nov 26 16:15:54 NAS kernel: bond0: (slave eth1): speed changed to 0 on port 2 Nov 26 16:15:54 NAS kernel: bond0: (slave eth0): speed changed to 0 on port 1 Nov 26 16:15:54 NAS kernel: bond0: (slave eth0): link status definitely down, disabling slave Nov 26 16:15:54 NAS kernel: bond0: now running without any active interface! Nov 26 16:15:54 NAS kernel: bond0: (slave eth1): link status definitely down, disabling slave Nov 26 16:15:54 NAS kernel: br0: port 1(bond0) entered disabled state Nov 26 16:17:13 NAS emhttpd: spinning down /dev/sdd Nov 26 16:17:19 NAS emhttpd: spinning down /dev/sdg Nov 26 16:17:19 NAS emhttpd: spinning down /dev/sdi Nov 26 16:17:26 NAS kernel: pcieport 0000:00:01.2: PME: Spurious native interrupt! Nov 26 16:17:26 NAS kernel: ------------[ cut here ]------------ Nov 26 16:17:26 NAS kernel: RTNL: assertion failed at net/core/dev.c (2891) Nov 26 16:17:26 NAS kernel: WARNING: CPU: 0 PID: 20150 at net/core/dev.c:2891 netif_set_real_num_tx_queues+0x73/0x1ab Nov 26 16:17:26 NAS kernel: Modules linked in: af_packet bluetooth ecdh_generic ecc xt_CHECKSUM ipt_REJECT nf_reject_ipv4 xt_nat xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle vhost_net tun vhost vhost_iotlb tap ipvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs md_mod ipmi_devintf nct6775 nct6775_core hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc bonding tls igb ast drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm ipmi_ssif amd64_edac edac_mce_amd edac_core kvm_amd wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel backlight crypto_simd nvme agpgart cryptd i2c_piix4 i2c_algo_bit input_leds ahci syscopyarea sysfillrect rapl sysimgblt joydev led_class cdc_acm nvme_core libahci i2c_core k10temp ccp fb_sys_fops acpi_ipmi wmi ipmi_si button unix [last unloaded: igb] Nov 26 16:17:26 NAS kernel: CPU: 0 PID: 20150 Comm: kworker/0:2 Not tainted 5.19.17-Unraid #2 Nov 26 16:17:26 NAS kernel: Hardware name: To Be Filled By O.E.M. X570D4U-2L2T/X570D4U-2L2T, BIOS L1.57 05/16/2022 Nov 26 16:17:26 NAS kernel: Workqueue: pm pm_runtime_work Nov 26 16:17:26 NAS kernel: RIP: 0010:netif_set_real_num_tx_queues+0x73/0x1ab Nov 26 16:17:26 NAS kernel: Code: 75 2a 80 3d c7 59 cb 00 00 75 21 ba 4b 0b 00 00 48 c7 c6 dd 2f 15 82 48 c7 c7 86 a5 0d 82 c6 05 ab 59 cb 00 01 e8 ed 11 15 00 <0f> 0b 8b b3 8c 03 00 00 89 ea 48 89 df e8 32 10 03 00 85 c0 0f 85 Nov 26 16:17:26 NAS kernel: RSP: 0018:ffffc9000469fd08 EFLAGS: 00010286 Nov 26 16:17:26 NAS kernel: RAX: 0000000000000000 RBX: ffff888131f28000 RCX: 0000000000000027 Nov 26 16:17:26 NAS kernel: RDX: 0000000000000001 RSI: ffffffff820d7be1 RDI: 00000000ffffffff Nov 26 16:17:26 NAS kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: ffffffff828653f0 Nov 26 16:17:26 NAS kernel: R10: 00003fffffffffff R11: ffff88903f33c06e R12: 0000000000000004 Nov 26 16:17:26 NAS kernel: R13: 0000000000000004 R14: ffff88810127b000 R15: ffff8884b38de800 Nov 26 16:17:26 NAS kernel: FS: 0000000000000000(0000) GS:ffff888ffe800000(0000) knlGS:0000000000000000 Nov 26 16:17:26 NAS kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 26 16:17:26 NAS kernel: CR2: 000000c000531000 CR3: 000000011eada000 CR4: 0000000000750ef0 Nov 26 16:17:26 NAS kernel: PKRU: 55555554 Nov 26 16:17:26 NAS kernel: Call Trace: Nov 26 16:17:26 NAS kernel: <TASK> Nov 26 16:17:26 NAS kernel: __igb_open+0x326/0x467 [igb] Nov 26 16:17:26 NAS kernel: __igb_resume+0x1ce/0x213 [igb] Nov 26 16:17:26 NAS kernel: ? pci_pm_default_resume_early+0x29/0x29 Nov 26 16:17:26 NAS kernel: __rpm_callback+0xce/0x13a Nov 26 16:17:26 NAS kernel: ? pci_pm_default_resume_early+0x29/0x29 Nov 26 16:17:26 NAS kernel: rpm_callback+0x35/0x64 Nov 26 16:17:26 NAS kernel: rpm_resume+0x402/0x546 Nov 26 16:17:26 NAS kernel: ? process_one_work+0x1ab/0x295 Nov 26 16:17:26 NAS kernel: pm_runtime_work+0x5d/0x7f Nov 26 16:17:26 NAS kernel: process_one_work+0x1ab/0x295 Nov 26 16:17:26 NAS kernel: worker_thread+0x18b/0x244 Nov 26 16:17:26 NAS kernel: ? rescuer_thread+0x281/0x281 Nov 26 16:17:26 NAS kernel: kthread+0xe7/0xef Nov 26 16:17:26 NAS kernel: ? kthread_complete_and_exit+0x1b/0x1b Nov 26 16:17:26 NAS kernel: ret_from_fork+0x22/0x30 Nov 26 16:17:26 NAS kernel: </TASK> Nov 26 16:17:26 NAS kernel: ---[ end trace 0000000000000000 ]--- Nov 26 16:17:26 NAS kernel: ------------[ cut here ]------------ Nov 26 16:17:26 NAS kernel: RTNL: assertion failed at net/core/dev.c (2939) Nov 26 16:17:26 NAS kernel: WARNING: CPU: 0 PID: 20150 at net/core/dev.c:2939 netif_set_real_num_rx_queues+0x61/0x83 Nov 26 16:17:26 NAS kernel: Modules linked in: af_packet bluetooth ecdh_generic ecc xt_CHECKSUM ipt_REJECT nf_reject_ipv4 xt_nat xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle vhost_net tun vhost vhost_iotlb tap ipvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs md_mod ipmi_devintf nct6775 nct6775_core hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc bonding tls igb ast drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm ipmi_ssif amd64_edac edac_mce_amd edac_core kvm_amd wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel backlight crypto_simd nvme agpgart cryptd i2c_piix4 i2c_algo_bit input_leds ahci syscopyarea sysfillrect rapl sysimgblt joydev led_class cdc_acm nvme_core libahci i2c_core k10temp ccp fb_sys_fops acpi_ipmi wmi ipmi_si button unix [last unloaded: igb] Nov 26 16:17:26 NAS kernel: CPU: 0 PID: 20150 Comm: kworker/0:2 Tainted: G W 5.19.17-Unraid #2 Nov 26 16:17:26 NAS kernel: Hardware name: To Be Filled By O.E.M. X570D4U-2L2T/X570D4U-2L2T, BIOS L1.57 05/16/2022 Nov 26 16:17:26 NAS kernel: Workqueue: pm pm_runtime_work Nov 26 16:17:26 NAS kernel: RIP: 0010:netif_set_real_num_rx_queues+0x61/0x83 Nov 26 16:17:26 NAS kernel: Code: 75 2a 80 3d ef 7a cb 00 00 75 21 ba 7b 0b 00 00 48 c7 c6 dd 2f 15 82 48 c7 c7 86 a5 0d 82 c6 05 d3 7a cb 00 01 e8 16 33 15 00 <0f> 0b 8b b3 04 03 00 00 89 ea 48 89 df e8 30 30 03 00 85 c0 74 af Nov 26 16:17:26 NAS kernel: RSP: 0018:ffffc9000469fd20 EFLAGS: 00010282 Nov 26 16:17:26 NAS kernel: RAX: 0000000000000000 RBX: ffff888131f28000 RCX: 0000000000000027 Nov 26 16:17:26 NAS kernel: RDX: 0000000000000001 RSI: ffffffff820d7be1 RDI: 00000000ffffffff Nov 26 16:17:26 NAS kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: ffffffff828653f0 Nov 26 16:17:26 NAS kernel: R10: 00003fffffffffff R11: ffff88903f33ccd6 R12: 0000000000000000 Nov 26 16:17:26 NAS kernel: R13: 0000000000000001 R14: ffff88810127b000 R15: ffff8884b38de800 Nov 26 16:17:26 NAS kernel: FS: 0000000000000000(0000) GS:ffff888ffe800000(0000) knlGS:0000000000000000 Nov 26 16:17:26 NAS kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 26 16:17:26 NAS kernel: CR2: 000000c000531000 CR3: 000000011eada000 CR4: 0000000000750ef0 Nov 26 16:17:26 NAS kernel: PKRU: 55555554 Nov 26 16:17:26 NAS kernel: Call Trace: Nov 26 16:17:26 NAS kernel: <TASK> Nov 26 16:17:26 NAS kernel: __igb_open+0x343/0x467 [igb] Nov 26 16:17:26 NAS kernel: __igb_resume+0x1ce/0x213 [igb] Nov 26 16:17:26 NAS kernel: ? pci_pm_default_resume_early+0x29/0x29 Nov 26 16:17:26 NAS kernel: __rpm_callback+0xce/0x13a Nov 26 16:17:26 NAS kernel: ? pci_pm_default_resume_early+0x29/0x29 Nov 26 16:17:26 NAS kernel: rpm_callback+0x35/0x64 Nov 26 16:17:26 NAS kernel: rpm_resume+0x402/0x546 Nov 26 16:17:26 NAS kernel: ? process_one_work+0x1ab/0x295 Nov 26 16:17:26 NAS kernel: pm_runtime_work+0x5d/0x7f Nov 26 16:17:26 NAS kernel: process_one_work+0x1ab/0x295 Nov 26 16:17:26 NAS kernel: worker_thread+0x18b/0x244 Nov 26 16:17:26 NAS kernel: ? rescuer_thread+0x281/0x281 Nov 26 16:17:26 NAS kernel: kthread+0xe7/0xef Nov 26 16:17:26 NAS kernel: ? kthread_complete_and_exit+0x1b/0x1b Nov 26 16:17:26 NAS kernel: ret_from_fork+0x22/0x30 Nov 26 16:17:26 NAS kernel: </TASK> Nov 26 16:17:26 NAS kernel: ---[ end trace 0000000000000000 ]--- Nov 26 16:17:29 NAS kernel: igb 0000:27:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Nov 26 16:17:29 NAS kernel: bond0: (slave eth1): link status definitely up, 1000 Mbps full duplex Nov 26 16:17:29 NAS kernel: bond0: active interface up! Nov 26 16:17:29 NAS kernel: br0: port 1(bond0) entered blocking state Nov 26 16:17:29 NAS kernel: br0: port 1(bond0) entered forwarding state Nov 26 16:17:30 NAS kernel: igb 0000:26:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Nov 26 16:17:30 NAS kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Ich meine, ja man sieht das der Link down ist etc., aber ist es normal das da CPU Warnungen rausgegeben werden? Danke vorab!

Irgendwann muss ich den Beitrag mal aktualisieren. Wurde ja einiges geändert :D

Ich hab CFTools, als es noch komplett Kostenlos war, getestet und ja es funktioniert. Aber es verbraucht viele Ressourcen. Vor allem wenn man große Mods (Expansion etc.) nutzt, dann kann man davon nie genug haben.

Wird für CFTools benötigt. Ist ein DayZ Verwaltungstool. Ich würde auf die altmodische Art den Server modden. Die Mods ziehen schon so oder so gut an der Server-FPS und OMEGA/CFTools packt nochmal einen drauf. Das ganze zieht ordentlich an den Ressourcen.

Was wurde denn geändert? Ich hab das Update installiert inkl. RocketChat und alles lief wie vorher?

Bei mir gibt es keinerlei Fehlermeldungen

Ich bin auf Nextcloud Hub 3 (25.0.0) und alles läuft bestens.

Sind die Pro Modelle (4750g oder 5750g) eigentlich stromsparender? Bzw. erlaubend diese bessere Stromsparsettings?

Nutzt du HA als VM oder Docker? Wenn als VM -> einfach das MariaDB Addon installieren. Wie man die alten Daten hinzufügt kann ich leider gerade nicht sagen, da ich von Anfang an MariaDB genutzt habe.

Ist da die neuste Firmware drauf? Ich habe leider keine Gen2, aber ich hatte einen 1Pm in der Wohnung an einer kleinen LED Lampe und da hat er auch Werte von 0,5W registriert. Kann aber sein das dort etwas geändert wurde.

Kannst du den denn allgemein steuern?

Nein, habe eine pfsense. Und die nutze ich schon knapp ein Jahr und hatte nie solche Probleme.

Jap, das nutze ich. Ich habe das mal aus der go-file rausgenommen und haben eben den Server neu gestartet Jap, ist auf ipvlan eingestellt.

Bei mir sind alle Shellys im ECO-Mode. Ich merke keinen unterschied zum normalen Modus. Die Schaltung reagiert ohne Verzögerung. Die Stromwerte vom 3EM werden trotzdem im Sekundentakt an HA gesendet. Der Eco-Modus hat darauf keine Auswirkung. Ich habe 3x 3EM im Einsatz (auf jeder Etage einen) Ja, den nutzte ich und bisher hat mir nichts gefehlt

Das gleiche Problem ist wieder da: Aber im Terminal ist nichts zu finden: Ich denke, wenn ich jetzt wieder auf "Prüfe auf Aktualisierungen" klicken und den Reiter wechsle, dann wird das GUI wieder abstürzen. Aktuell kann ich alles wie gewohnt bedienen und erreichen. Edit: Wenn ich auf "Prüfe auf Aktualisierungen" klicken, dann kommt nur ganz kurz "Überprüfung läuft" und springt dann direkt wieder zurück auf "nicht verfügbar" Kann das mit Powertop oder sowas zusammenhängen?

Nicht weniger. Diese Infos mit 0,7 oder mehr, sind meistens vor den Updates gewesen. Shelly hat da schon nachgebessert.

War etwas falsch ausgedrückt. Die CPU wird gedrosselt Meine Meinung Mir ist es egal ob das Teil 0,5W, 0,7W oder 1W verbraucht. Diesen Mehrverbrauch habe ich durch 2 Geräte wieder reingeholt die im Standby ausgeschaltet werden durch die Shellys. Dann kommt die simple Konfiguration hinzu die mich keine Nerven kostet. Updates können ganz einfach installiert werden und da bedarf es kein Deconz/ZHA wo die File erstmal hochgeladen werden muss. Sollte der Strom ausfallen und die Geräte starten wieder, dann ist in deren Speicher die "Startposition" hinterlegt. Meine Güte hat mich das an den Zigbee-Teilen aufgeregt. Und zu den Verbindungsabbrüchen muss ich ja nichts mehr sagen. Dafür dürften die Teile sogar noch mehr verbrauchen. Ja, es ist löblich wenig zu verbrauchen und ich finde das auch gut, aber irgendwann ist ein Punkt erreicht wo es mir mehr um Komfort geht. Aber wie gesagt, dass ist meine Meinung.

Der Shelly Plug S verbrauch ca. 0,5W im Standby wie auch die Unterputzaktoren (das war 2018). Die neue Firmware legt die CPU im Standby schlafen - sprich ECO-Modus. Ich bin aktuell bei knapp 60 Shelly, alles Unterputz in verschiedenen Versionen, und hab mit keiner einzigen jemals Probleme gehabt. Es werden in Zukunft noch einige mehr sein, da wir mit einigen Räumen noch nicht fertig sind. Hinzu kommt das einpflegen in HA. Die Shelly geht online und wird direkt in HA angezeigt. Kein Deconz, ZHA oder ähnliches mit komplizierter Einbindung notwendig. Sollte HA ausfallen kann ich die Aktoren noch immer per IP erreichen und steuern.

Sowohl Memtest als auch die volle Auslastung der CPU liefen ohne Probleme durch. Memtest lief zwei mal durch 1x ohne SMP und 1x mit allen Cores. Der CPU-Stresstest lief ca. 45 Min und das GUI war die ganze Zeit ohne Probleme zu bedienen. Die Temps gingen nicht über 49°C und das ist für eine CPU eher wenig. Ich versuche morgen den Fehler nochmals zu "provozieren". Ich glaube nicht das es an meiner Hardware liegt.

Es ist die aktuellste (L1.57) installiert und das im Mai. Werde ich heute Abend mal machen und berichten. Was meintest du dann mit "hier pro CPU Kern 1x ausführen" Wie ändere ich die Kerne in dem Befehl? Besten Dank.

Der Server hatte eine 40Tage+ Uptime und lief ohne Probleme. Es waren auch alle Docker und VMs die ganze Zeit erreichbar. Keine Ahnung warum ich keine Updates durchführen konnte. Die Fehler die ich oben gepostet habe, sind nicht im Syslog vermerkt. Aber das Terminal war zu jederzeit erreichbar und bedienbar. Ich hab die Docker gestoppt und "top" etc. ausführen können. Der "powerdown" Befehlt taucht wieder im Syslog auf und der Server hat das Array sauber beendet und ist runtergefahren. Der Absturz kam erst nachdem alles (Firewall, Switches) neu gestartet wurde und ich dann wieder auf "Prüfe auf Aktualisierungen" geklickt habe. Es kam dieses "Überprüfung läuft" und das lief dann ca. 5 Min. Ich hab dann einfach mal in ein anderen Reiter geklickt und das GUI abgeschmiert. Nach dem Reboot funktioniert wieder alles wie gewohnt. Ja, alles voll kompatibel und es wurde ewig nichts geändert. Ich vermute es ist einfach das GUI abgeschmiert, aber ich verstehe nicht warum das nirgends auftaucht und warum ich die Docker nicht updaten konnte.

Moinsen Leute, ich habe gerade ein kurioses Problem. Aus irgendeinen Grund konnte ich meine Docker nicht updaten bzw. nicht auf Updates überprüfen. In der Spalte "Docker" stand, nachdem man auf "Alle auf Aktualisierungen prüfen", nicht verfügbar. Ich habe denn alle Docker gestoppt und und den Dienst beendet und wieder gestartet. Anschließend habe ich nochmals versucht die Docker auf Updates zu überprüfen, aber es ging noch immer nicht. Dann habe ich einfach mal meine Firewall und alle Switches neu gestartet. Danach hab ich wieder auf Updates geklickt und zumindest wurde dann geprüft, aber das dauerte ewig. Als ich dann auf einen anderen Reiter geklickt habe war das GUI nicht mehr erreichbar. Ich hab mich dann aufs IPMI eingeloggt und mal geschaut und dann standen dort diese Fehler: Das Terminal selbst geht. Aber ins GUI komme ich nicht. Kann man den Server jetzt per powerdown sauber runterfahren?

Wenn auch Wlan geht, dann ganz klar Shelly PM.