Neuer Proxmox Kernel verfügbar
-
vor ca. 3 Wochen habe Proxmox auf 8.4.1 gesetzt. Seitdem war der NUC mittlerweile 6x nicht erreichbar.
Kernel ist6.8.12-9-pve. Nach Neustart des NUC läuft dieser erst einmal wieder.Da ich nicht gerade über tiefgreifende Linuxkentnisse verfüge habe ich von weiteren Upgrades erst mal die Finger gelassen. Ich sehe aber jetzt das du 6.8.12-10-pve verwendest. Vielleicht sollte ich doch noch einmal upgraden.
May 02 11:15:18 pve systemd[1]: pve-ha-crm.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped pve-ha-crm.service - PVE Cluster HA Resource Manager Daemon. May 02 11:15:18 pve systemd[1]: pve-ha-crm.service: Consumed 1min 17.903s CPU time. May 02 11:15:18 pve systemd[1]: Stopping watchdog-mux.service - Proxmox VE watchdog multiplexer... May 02 11:15:18 pve watchdog-mux[594]: got terminate request May 02 11:15:18 pve watchdog-mux[594]: clean exit May 02 11:15:18 pve systemd[1]: watchdog-mux.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped watchdog-mux.service - Proxmox VE watchdog multiplexer. May 02 11:15:18 pve systemd[1]: watchdog-mux.service: Consumed 23.028s CPU time. May 02 11:15:18 pve systemd[1]: pveproxy.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped pveproxy.service - PVE API Proxy Server. May 02 11:15:18 pve systemd[1]: pveproxy.service: Consumed 54min 15.066s CPU time. May 02 11:15:18 pve systemd[1]: Stopped target pve-storage.target - PVE Storage Target. May 02 11:15:18 pve systemd[1]: Stopped target ceph.target - ceph target allowing to start/stop all ceph*@.service instances at once. May 02 11:15:18 pve systemd[1]: Stopped target ceph-fuse.target - ceph target allowing to start/stop all ceph-fuse@.service instances at once. May 02 11:15:18 pve systemd[1]: Stopping pvedaemon.service - PVE API Daemon... May 02 11:15:18 pve systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server... May 02 11:15:18 pve sshd[712]: Received signal 15; terminating. May 02 11:15:18 pve systemd[1]: ssh.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server. May 02 11:15:19 pve pvedaemon[933]: received signal TERM May 02 11:15:19 pve pvedaemon[933]: server closing May 02 11:15:19 pve pvedaemon[1879148]: worker exit May 02 11:15:19 pve pvedaemon[1904628]: worker exit May 02 11:15:19 pve pvedaemon[1883231]: worker exit May 02 11:15:19 pve pvedaemon[933]: worker 1904628 finished May 02 11:15:19 pve pvedaemon[933]: worker 1879148 finished May 02 11:15:19 pve pvedaemon[933]: worker 1883231 finished May 02 11:15:19 pve pvedaemon[933]: server stopped May 02 11:15:19 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang: TDH <92> TDT <c9> next_to_use <c9> next_to_clean <91> buffer_info[next_to_clean]: time_stamp <13c7893cf> next_to_watch <92> jiffies <13dc1b400> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <7c00> PHY Extended Status <3000> PCI Status <10>@agrippinenser zurück in die steinzeit?
8.4.1 flutscht ohne probleme... -
vor ca. 3 Wochen habe Proxmox auf 8.4.1 gesetzt. Seitdem war der NUC mittlerweile 6x nicht erreichbar.
Kernel ist6.8.12-9-pve. Nach Neustart des NUC läuft dieser erst einmal wieder.Da ich nicht gerade über tiefgreifende Linuxkentnisse verfüge habe ich von weiteren Upgrades erst mal die Finger gelassen. Ich sehe aber jetzt das du 6.8.12-10-pve verwendest. Vielleicht sollte ich doch noch einmal upgraden.
May 02 11:15:18 pve systemd[1]: pve-ha-crm.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped pve-ha-crm.service - PVE Cluster HA Resource Manager Daemon. May 02 11:15:18 pve systemd[1]: pve-ha-crm.service: Consumed 1min 17.903s CPU time. May 02 11:15:18 pve systemd[1]: Stopping watchdog-mux.service - Proxmox VE watchdog multiplexer... May 02 11:15:18 pve watchdog-mux[594]: got terminate request May 02 11:15:18 pve watchdog-mux[594]: clean exit May 02 11:15:18 pve systemd[1]: watchdog-mux.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped watchdog-mux.service - Proxmox VE watchdog multiplexer. May 02 11:15:18 pve systemd[1]: watchdog-mux.service: Consumed 23.028s CPU time. May 02 11:15:18 pve systemd[1]: pveproxy.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped pveproxy.service - PVE API Proxy Server. May 02 11:15:18 pve systemd[1]: pveproxy.service: Consumed 54min 15.066s CPU time. May 02 11:15:18 pve systemd[1]: Stopped target pve-storage.target - PVE Storage Target. May 02 11:15:18 pve systemd[1]: Stopped target ceph.target - ceph target allowing to start/stop all ceph*@.service instances at once. May 02 11:15:18 pve systemd[1]: Stopped target ceph-fuse.target - ceph target allowing to start/stop all ceph-fuse@.service instances at once. May 02 11:15:18 pve systemd[1]: Stopping pvedaemon.service - PVE API Daemon... May 02 11:15:18 pve systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server... May 02 11:15:18 pve sshd[712]: Received signal 15; terminating. May 02 11:15:18 pve systemd[1]: ssh.service: Deactivated successfully. May 02 11:15:18 pve systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server. May 02 11:15:19 pve pvedaemon[933]: received signal TERM May 02 11:15:19 pve pvedaemon[933]: server closing May 02 11:15:19 pve pvedaemon[1879148]: worker exit May 02 11:15:19 pve pvedaemon[1904628]: worker exit May 02 11:15:19 pve pvedaemon[1883231]: worker exit May 02 11:15:19 pve pvedaemon[933]: worker 1904628 finished May 02 11:15:19 pve pvedaemon[933]: worker 1879148 finished May 02 11:15:19 pve pvedaemon[933]: worker 1883231 finished May 02 11:15:19 pve pvedaemon[933]: server stopped May 02 11:15:19 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang: TDH <92> TDT <c9> next_to_use <c9> next_to_clean <91> buffer_info[next_to_clean]: time_stamp <13c7893cf> next_to_watch <92> jiffies <13dc1b400> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <7c00> PHY Extended Status <3000> PCI Status <10>Ist ein bekannter Bug.
Findet man sehr viel zu.Zb
https://forum.proxmox.com/threads/e1000e-network-issue-on-proxmox.139141/Einfach in er Console
ethtool -K enp0s31f6 tso off gso off gro off(Name von Netzwerkkarte anpassen)
Überlebt ao aber kein reboot. Aber das bekommt man bei Bedarf ja auch hin.
-
Ist ein bekannter Bug.
Findet man sehr viel zu.Zb
https://forum.proxmox.com/threads/e1000e-network-issue-on-proxmox.139141/Einfach in er Console
ethtool -K enp0s31f6 tso off gso off gro off(Name von Netzwerkkarte anpassen)
Überlebt ao aber kein reboot. Aber das bekommt man bei Bedarf ja auch hin.
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Damit hatte ich es beim vorigen Kernel auch hinbekommen.
Mit dem neuen Kernel
Linux HA-PVE-01 6.8.12-10-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-10 (2025-04-18T07:39Z) x86_64 GNU/Linuxhatte ich bisher noch keine Probleme. -
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
Da ich nicht gerade über tiefgreifende Linuxkentnisse verfüge habe ich von weiteren Upgrades erst mal die Finger gelassen.
Gerade DANN spielt man die aktuelsten Updates/Upgrades ein.
@thomas-braun sagte in Neuer Proxmox Kernel verfügbar:
Gerade DANN spielt man die aktuelsten Updates/Upgrades ein.
das mag jetzt total unlogisch erscheinen aber ich habe da im dunklen gestanden. Ich war froh das der NUC nach Neustart wieder erreichbar war. Hätte ich nicht den Eingangspost gelesen wäre als nächstes Neuinstallation dran gewesen.
-
Ist ein bekannter Bug.
Findet man sehr viel zu.Zb
https://forum.proxmox.com/threads/e1000e-network-issue-on-proxmox.139141/Einfach in er Console
ethtool -K enp0s31f6 tso off gso off gro off(Name von Netzwerkkarte anpassen)
Überlebt ao aber kein reboot. Aber das bekommt man bei Bedarf ja auch hin.
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Vielen Dank, ich habe es mit Netzwerkname "vmbr0" ausgeführt. Keine Ahnung was "eno1" hier macht
auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.0.130/24 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/*Grüße vom Rhein @Colonia Claudia Ara Agrippinensium
-
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Vielen Dank, ich habe es mit Netzwerkname "vmbr0" ausgeführt. Keine Ahnung was "eno1" hier macht
auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.0.130/24 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/* -
@agrippinenser eno1 ist vermutlich das physikalische Netzwerkinterface.
vmbr0 eine Bridge damit die VMs mit dem physikalischen Interface verbunden werden können.Tschau
UweWenn die Nomenklatur der Interfaces interessiert:
https://www.thomas-krenn.com/en/wiki/Predictable_Network_Interface_Names
-
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Vielen Dank, ich habe es mit Netzwerkname "vmbr0" ausgeführt. Keine Ahnung was "eno1" hier macht
auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.0.130/24 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/*@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Vielen Dank, ich habe es mit Netzwerkname "vmbr0" ausgeführt. Keine Ahnung was "eno1" hier macht
auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.0.130/24 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/*eno1 wäre in deinem Fall richtig.
Proxmox und HA - dank KI/AI endlich "blocklyfrei"
-
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
@david-g sagte in Neuer Proxmox Kernel verfügbar:
ethtool -K enp0s31f6 tso off gso off gro off
Vielen Dank, ich habe es mit Netzwerkname "vmbr0" ausgeführt. Keine Ahnung was "eno1" hier macht
auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.0.130/24 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/*eno1 wäre in deinem Fall richtig.
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
eno1 wäre in deinem Fall richtig.
ach was stell ich mich blöd an. Danke !
Grüße vom Rhein @Colonia Claudia Ara Agrippinensium
-
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
eno1 wäre in deinem Fall richtig.
ach was stell ich mich blöd an. Danke !
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
eno1 wäre in deinem Fall richtig.
ach was stell ich mich blöd an. Danke !
Egal, et hätt noch emmer joot jejange. :grinning:
Edit Ergänzung:
Was bewirkt der Befehl?
Die Deaktivierung von Offloading-Funktionen kann die CPU-Auslastung erhöhen, da das Betriebssystem die Aufgaben der Netzwerkarte (NIC) übernehmen muss (das solltest du beobachten, ich denke aber nicht, dass es problematisch sein wird).Es kann die Netzwerkstabilität erhöhen wenn Problemen mit dem Netzwerkkartentreiber auftreten.
Soweit meine Recherchen zum Problem.
Proxmox und HA - dank KI/AI endlich "blocklyfrei"
-
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
eno1 wäre in deinem Fall richtig.
ach was stell ich mich blöd an. Danke !
Egal, et hätt noch emmer joot jejange. :grinning:
Edit Ergänzung:
Was bewirkt der Befehl?
Die Deaktivierung von Offloading-Funktionen kann die CPU-Auslastung erhöhen, da das Betriebssystem die Aufgaben der Netzwerkarte (NIC) übernehmen muss (das solltest du beobachten, ich denke aber nicht, dass es problematisch sein wird).Es kann die Netzwerkstabilität erhöhen wenn Problemen mit dem Netzwerkkartentreiber auftreten.
Soweit meine Recherchen zum Problem.
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
Was bewirkt der Befehl?
Mit deinen Informationen habe ich auch noch mal recherchiert. Dieses Offloading macht sich insbesondere bei schnellen Netzwerk-Verbindungen bemerkbar .. logisch. Ich bemerke hier keine nennenswerte CPU-Laständerung.
EDIT: wahrscheinlich macht es sich dann auch bei Übertragung größerer Datenmengen bemerkbar .. backup oder ähnliches
Grüße vom Rhein @Colonia Claudia Ara Agrippinensium
-
@meister-mopper sagte in Neuer Proxmox Kernel verfügbar:
Was bewirkt der Befehl?
Mit deinen Informationen habe ich auch noch mal recherchiert. Dieses Offloading macht sich insbesondere bei schnellen Netzwerk-Verbindungen bemerkbar .. logisch. Ich bemerke hier keine nennenswerte CPU-Laständerung.
EDIT: wahrscheinlich macht es sich dann auch bei Übertragung größerer Datenmengen bemerkbar .. backup oder ähnliches
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
wahrscheinlich macht es sich dann auch bei Übertragung größerer Datenmengen bemerkbar
Keine Erkenntnis. Ich sichere Daten inkrementell mit dem Proxmox Backup Server. Das funktioniert mit dem aktellen Kernel sehr gut.
-
@agrippinenser sagte in Neuer Proxmox Kernel verfügbar:
wahrscheinlich macht es sich dann auch bei Übertragung größerer Datenmengen bemerkbar
Keine Erkenntnis. Ich sichere Daten inkrementell mit dem Proxmox Backup Server. Das funktioniert mit dem aktellen Kernel sehr gut.
@meister-mopper Bei den Intel NUCs mit bestimmten Intel-Netzwerkadaptern war die Verbindung nach einiger Zeit problematisch. Abhilfe hatten da die Befehle gebracht, welche die (eigentlich) per Hardware durchgeführten Vorgänge (Handshaking und Co) CPU belastender in Software erledigen lassen. Für Windows hatte Intel neue Treiber (inkl. Firmware) herausgebracht.
Bei mir trat das Problem allerdings hauptsächlich auf dem NUC6CAYH auf.
Support us
724
Online32.7k
Users82.6k
Topics1.3m
Posts