Proxmox e1000e: Detected Hardware Unit Hang beheben
Wenn dein Proxmox e1000e Fehler plötzlich den Host aus dem Netzwerk wirft, fühlt sich das im ersten Moment nach einem kompletten Absturz an. Bei mir war es letztens auf meinem PVE Node genau so: kein Ping, kein SSH, keine Weboberfläche. Die Maschine lief aber weiter, die SSD zeigte Aktivität und im Journal stand nach dem Neustart der eigentliche Hinweis: Detected Hardware Unit Hang.
In diesem Beitrag zeige ich dir, was da passiert ist, was die Meldung bei einer Intel e1000e-Netzwerkkarte bedeutet und wie du den Workaround sauber einrichtest. Es geht um NIC-Offloading, einen zickigen Treiberzustand und einen kleinen systemd-Service, der nach dem Boot die richtigen Schalter setzt. Also Serverpflege mit leicht erhöhtem Puls, wie man sie liebt.
🧯 Was auf meinem PVE Node passiert ist
Der betroffene Host war meinem PVE Node, ein Dell OptiPlex 7000 mit Intel I219-LM Netzwerkkarte. Darauf lief Proxmox VE 9.2.x mit Kernel 7.0.14-11-pve. Von außen sah das Fehlerbild erstmal ziemlich unschön aus: Der Proxmox-Host war nicht mehr erreichbar, obwohl die Maschine selbst nicht komplett tot war.
Nach dem Neustart habe ich mir den vorherigen Boot im Journal angesehen. Dort kam die gleiche Kernel-Meldung immer wieder:
e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang
Das erklärt auch, warum der Host von außen wie eingefroren wirkte. Wenn die Netzwerkkarte beziehungsweise der Treiber hängt, kommst du per Netzwerk nicht mehr auf die Kiste. Die VMs und Container können dabei theoretisch noch laufen, aber aus Admin-Sicht ist der Host erstmal weg. Und ein Headless-Proxmox-Host ohne Netzwerk ist ungefähr so hilfreich wie ein Passwortmanager ohne Masterpasswort.
🔎 Was bedeutet der Proxmox e1000e Fehler?
e1000e ist der Linux-Treiber für bestimmte Intel-Gigabit-Netzwerkkarten. In meinem Fall hängt dahinter eine Intel I219-LM. Die Meldung Detected Hardware Unit Hang bedeutet vereinfacht: Der Treiber wartet auf eine Antwort oder Abarbeitung durch die Netzwerkkarte, aber dort geht es nicht weiter.
Der Ursprung liegt häufig bei aktivierten Offloading-Funktionen. Offloading bedeutet, dass bestimmte Netzwerkaufgaben nicht komplett von der CPU erledigt werden, sondern an die Netzwerkkarte ausgelagert werden. Dazu gehören zum Beispiel Checksummen, Segmentierung oder das Zusammenfassen von Paketen. Normalerweise ist das gut, weil es CPU spart. In dieser Kombination aus Hardware, Treiber, Kernel und Last kann es aber dazu führen, dass die NIC hängen bleibt.
Im Proxmox-Forum wird genau dieses Fehlerbild für Intel-e1000e-NICs beschrieben. Dort wird als Workaround empfohlen, Offloading für diese Karten zu deaktivieren. Das Community-Script Intel e1000e NIC Offloading Fix macht im Prinzip genau das automatisiert. Ich zeige dir hier zusätzlich den manuellen Weg, damit du verstehst, was passiert.
🧭 Diagnose auf dem Proxmox-Host
Zuerst solltest du prüfen, ob dein System überhaupt eine passende Intel-NIC mit e1000e-Treiber nutzt. Auf dem Proxmox-Host kannst du dafür diese Befehle verwenden:
lspci -nnk | grep -A3 -Ei 'ethernet|network' ethtool -i nic0
Bei mir sah der wichtige Teil so aus:
driver: e1000e bus-info: 0000:00:1f.6
Danach suchst du im Kernel-Log nach der eigentlichen Fehlermeldung. Wenn der Host bereits neu gestartet wurde, ist journalctl -k für den aktuellen Boot nicht immer genug. Dann hilft oft -b -1 für den vorherigen Boot.
journalctl -k --no-pager | grep -Ei 'e1000e|Detected Hardware Unit Hang|NETDEV WATCHDOG' journalctl -k -b -1 --no-pager | grep -Ei 'e1000e|Detected Hardware Unit Hang|NETDEV WATCHDOG'
Wenn du dort die Hang-Meldung findest, prüfst du als Nächstes den Offloading-Status deines Interfaces:
ethtool -k nic0 | egrep 'rx-checksumming|tx-checksumming|scatter-gather|tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|rx-vlan-offload|tx-vlan-offload'
Wenn mehrere Werte auf on stehen und dein Log die e1000e-Hänger zeigt, ist der Workaround ein sinnvoller nächster Schritt.
🛠 Temporärer Fix mit ethtool
Zum Testen kannst du die Offloading-Funktionen direkt per ethtool deaktivieren. Das wirkt sofort, ist aber nach einem Neustart wieder weg.
ethtool -K nic0 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off
Danach prüfst du wieder den Status:
ethtool -k nic0 | egrep 'rx-checksumming|tx-checksumming|scatter-gather|tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|rx-vlan-offload|tx-vlan-offload'
Wenn die Werte auf off stehen und der Host danach stabil bleibt, hast du ziemlich wahrscheinlich die richtige Stelle erwischt. Auf meinem PVE Node war genau das der Fall.
⚙️ Persistenten Fix per systemd einrichten
Damit die Einstellung nach einem Reboot automatisch wieder gesetzt wird, kannst du einen kleinen systemd-Oneshot-Service anlegen. Der Service läuft nach dem Netzwerkstart einmal durch und setzt die Offloading-Werte für nic0 auf off.
Service-Datei erstellen
Lege auf dem Proxmox-Host diese Datei an:
cat > /etc/systemd/system/disable-nic-offload-nic0.service <<'EOF' [Unit] Description=Disable NIC offloading for Intel e1000e interface nic0 After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/sbin/ethtool -K nic0 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off RemainAfterExit=true [Install] WantedBy=multi-user.target EOF
Falls dein Interface nicht nic0 heißt, musst du den Namen natürlich anpassen. Bei älteren oder anderen Installationen kann das zum Beispiel eno1 sein.
Service aktivieren
Danach lädst du systemd neu und aktivierst den Service direkt:
systemctl daemon-reload systemctl enable --now disable-nic-offload-nic0.service
Jetzt sollte der Service aktiv sein und die Offloading-Werte gesetzt haben.
systemctl status disable-nic-offload-nic0.service ethtool -k nic0 | egrep 'rx-checksumming|tx-checksumming|scatter-gather|tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|rx-vlan-offload|tx-vlan-offload'
Auf meinem PVE Node sah die Prüfung danach so aus:
disable-nic-offload-nic0.service: enabled, active (exited) rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off
Damit ist der Fix rebootfest. Am 10.08.2026 habe ich ihn auf meinem PVE Node unter /etc/systemd/system/disable-nic-offload-nic0.service eingerichtet.
🧹 Fix wieder deinstallieren
Wenn du den Workaround später wieder entfernen möchtest, zum Beispiel nach einem Kernel-, Treiber- oder Firmware-Update, geht das sauber über systemd. Erst deaktivierst und entfernst du den Service:
systemctl disable --now disable-nic-offload-nic0.service rm /etc/systemd/system/disable-nic-offload-nic0.service systemctl daemon-reload
Wenn du Offloading direkt wieder aktivieren möchtest, kannst du es anschließend wieder einschalten:
ethtool -K nic0 gso on gro on tso on tx on rx on rxvlan on txvlan on sg on
Ich würde danach aber wieder das Journal beobachten. Wenn der Fehler erneut auftaucht, war der Workaround vermutlich nicht ohne Grund aktiv.
🧩 Was du zusätzlich prüfen solltest
Der Offloading-Fix ist ein Workaround, kein goldener Treiber-Patch aus dem Himmel. Deshalb solltest du ein paar Dinge zusätzlich im Blick behalten:
- BIOS und Firmware aktualisieren, gerade bei Mini-PCs und Office-Desktops.
- Patchkabel und Switch-Port testen, wenn das Problem trotz Fix wiederkommt.
- Nach Kernel-Updates prüfen, ob der Fehler weiterhin auftritt.
- Bei dauerhaftem Ärger eine andere Netzwerkkarte testen.
- Die CPU-Last im Auge behalten, weil Offloading-Arbeit wieder auf der CPU landet.
Auf einem modernen OptiPlex mit 1 Gbit/s ist die zusätzliche CPU-Last normalerweise kein Drama. Trotzdem ist es gut zu wissen, was man da ändert. Performance ist schön, ein erreichbarer Host ist schöner.
📌 Fazit
Der Proxmox e1000e Fehler auf meinem PVE Node sah erst nach einem kompletten Host-Absturz aus. Am Ende war es aber sehr wahrscheinlich ein hängender Intel-e1000e-Netzwerktreiber im Zusammenspiel mit aktivierten Offloading-Funktionen. Der Host war dadurch aus dem Netzwerk verschwunden, obwohl die Maschine selbst weiterlief.
Mit ethtool lässt sich der Workaround schnell testen. Wenn er hilft, sorgt ein kleiner systemd-Service dafür, dass die Einstellungen auch nach jedem Neustart wieder gesetzt werden. Das ist nicht besonders spektakulär, aber genau solche unscheinbaren Fixes retten einem im Homelab gerne den Abend.
Die passende Diskussion im Proxmox-Forum findest du hier: e1000e Detected Hardware Unit Hang.
👥 Techniverse Community
Lust auf Austausch rund um Matrix, Selfhosting und andere smarte IT-Lösungen?
In der Techniverse Community triffst du Gleichgesinnte, kannst Fragen stellen oder einfach nerdigen Talk genießen.
👉 Jetzt der Gruppe auf Matrix beitreten
~ Direkte Raumadresse: #community:techniverse.net
👉 Für lockere Gespräche abseits der Kernthemen komm in den Talkraum
~ Direkte Raumadresse: #talk:techniverse.net
Wir freuen uns, wenn du dabei bist!
