Neuer Proxmox Kernel verfügbar

[Meister Mopper]

@martinp sagte in Neuer Proxmox Kernel verfügbar:

Keine Probleme beim Update

Woher willst du das wissen.

Beim vorletzten Kernel-Update bekam ich erst nach Tagen Probleme mit der Netzwerkkarte und alle Maschinen eines node migrierten auf andere nodes.

[Dr. Bakterius]

Läuft bei mir seit drei Tagen ohne Probleme. Hatte aber auch bisher nie welche.

[Agrippinenser]

@martinp

vor ca. 3 Wochen habe Proxmox auf 8.4.1 gesetzt. Seitdem war der NUC mittlerweile 6x nicht erreichbar.
Kernel ist 6.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>

[Thomas Braun]

@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.

[da_Woody]

@agrippinenser zurück in die steinzeit?
8.4.1 flutscht ohne probleme...

[David G.]

@agrippinenser

Ist ein bekannter Bug.
Findet man sehr viel zu.

Zb
https://forum.proxmox.com/threads/e1000e-network-issue-on-proxmox.139141/

https://forum.proxmox.com/threads/nach-update-auf-8-3-5-regelmäßige-abstürze-edit-cause-intel-e1000e-networkcard.164577/

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.

[Meister Mopper]

@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/Linux hatte ich bisher noch keine Probleme.

[Agrippinenser]

@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.

[Agrippinenser]

@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/*

[uweklatt]

@agrippinenser eno1 ist vermutlich das physikalische Netzwerkinterface.
vmbr0 eine Bridge damit die VMs mit dem physikalischen Interface verbunden werden können.

Tschau
Uwe

[Thomas Braun]

@uweklatt

Wenn die Nomenklatur der Interfaces interessiert:

https://www.thomas-krenn.com/en/wiki/Predictable_Network_Interface_Names

[Meister Mopper]

@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.

[Agrippinenser]

@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 !

[Meister Mopper]

@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.

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.

[Agrippinenser]

@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

[Meister Mopper]

@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.

[peterfido]

@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.