Forum: PC Hard- und Software [Debian Server 20.04] NIC verweigert plötzlich arbeit - was tun?


von Draco (Gast)


Lesenswert?

Ich habe einen Debian Server 20.04 LTS laufen. Mit einer Quad Nic von 
Sun. Die Ports laufen im Bond (RR) und alles lief bis gestern tadellos.

Nach der Server die aktuellen Updates gezogen hat, das System sich neu 
bootete, weigert nun die Netzwerkkarte jegliche Arbeit.

Ausgabe über "ip a" ergibt folgendes:
1
draconix@server-home:~$ ip a
2
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
3
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4
    inet 127.0.0.1/8 scope host lo
5
       valid_lft forever preferred_lft forever
6
    inet6 ::1/128 scope host
7
       valid_lft forever preferred_lft forever
8
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
9
    link/ether 00:19:99:8f:ca:a1 brd ff:ff:ff:ff:ff:ff
10
    inet 192.168.178.44/24 brd 192.168.178.255 scope global dynamic noprefixroute enp0s25
11
       valid_lft 85678sec preferred_lft 85678sec
12
    inet6 fe80::219:99ff:fe8f:caa1/64 scope link
13
       valid_lft forever preferred_lft forever
14
3: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
15
    link/ether ce:cb:3b:1e:8a:22 brd ff:ff:ff:ff:ff:ff
16
    inet 192.168.178.5/24 brd 192.168.178.255 scope global noprefixroute bond0
17
       valid_lft forever preferred_lft forever

die Netzwerkconfig sieht wie folgt aus:
1
network:
2
#  renderer: NetworkManager
3
  renderer: networkd
4
  ethernets:
5
    enp0s25:
6
      dhcp4: true
7
    ens3f0:
8
      optional: true
9
    ens3f1:
10
      optional: true
11
    ens3f2:
12
      optional: true
13
    ens3f3:
14
      optional: true
15
  bonds:
16
    bond0:
17
      dhcp4: false
18
      interfaces:
19
        - ens3f0
20
        - ens3f1
21
        - ens3f2
22
        - ens3f3
23
      addresses: [192.168.178.5/24]
24
      gateway4: 192.168.178.1
25
      nameservers:
26
        addresses: [192.168.178.1]
27
      parameters:
28
#        mode: 802.3ad
29
#        lacp-rate: fast
30
#        mii-monitor-interval: 100
31
        mode: balance-rr

Und wie gesagt, das lief ja auch bis zum update völlig fehlerfrei und 
wunderbar.

lspci zeigt mir folgendes:
1
draconix@server-home:/etc/netplan$ lspci -nnk | grep -iA3 sun
2
02:00.0 Ethernet controller [0200]: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:abcd] (rev 01)
3
        Subsystem: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:0000]
4
        Kernel modules: niu
5
02:00.1 Ethernet controller [0200]: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:abcd] (rev 01)
6
        Subsystem: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:0000]
7
        Kernel modules: niu
8
02:00.2 Ethernet controller [0200]: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:abcd] (rev 01)
9
        Subsystem: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:0000]
10
        Kernel modules: niu
11
02:00.3 Ethernet controller [0200]: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:abcd] (rev 01)
12
        Subsystem: Oracle/SUN Multithreaded 10-Gigabit Ethernet Network Controller [108e:0000]
13
        Kernel modules: niu
14
11:07.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] ES1000 [1002:515e] (rev 02)
15
        Subsystem: Fujitsu Technology Solutions ES1000 [1734:1122]


Wie kann ich die Treiber dazu finden, bzw... wo kann ich finden wo der 
Fehler eventuell liegen könnte? Gibt es da ein Log?

Ein Testweises rausnehmen der einzelnen Nics aus dem Bond funktioniert 
auch nicht, auch die einzelnen nics (ens3fx) werden nicht angezeigt.

von Jack V. (jackv)


Lesenswert?

Draco schrieb:
> Ich habe einen Debian Server 20.04 LTS laufen.

Hast du nicht. Die Versionsnummer deutet auf Ubuntu hin, kann aber auch 
Mint oder sowas sein.

Ansonsten wär’s sinnvoll, den Networkmanager mal als Fehlerquelle 
auszuschließen, indem die Interfaces auf altmodische Art konfiguriert 
werden. Da sieht man dann auch, an welcher Stelle ein Fehler auftritt – 
und welcher genau.

Draco schrieb:
> Gibt es da ein Log?

Das Journal, mit den passenden Filtern.

: Bearbeitet durch User
von DPA (Gast)


Lesenswert?

Draco schrieb:
> auch die einzelnen nics (ens3fx)

Da wird der Hund begraben sein. Hast du schon in dmesg nachgesehen, ob 
eventuell irgendwelche firmware oder so fehlt?

von Dentaa (Gast)


Lesenswert?

Draco schrieb:
> Wie kann ich die Treiber dazu finden, bzw... wo kann ich finden wo der
> Fehler eventuell liegen könnte? Gibt es da ein Log?

Die Ausgabe von dmesg nach dem booten nach Meldungen bzgl. Ethernet 
prüfen.
mii-tool oder ethtool liefert Infos zum Linkstate der Karten.
lspci als root bzw. mit ordentlich -v liefert den Treiber zum 
pci-device.
modinfo liefert Infos zu Parameter zu Kernelmodulen.
Unter /sys findet sich auch einiges.
/proc/net/bonding/bondx liefert Infos zum Status vom Bond Interface.

von Tobias P. (hubertus)


Lesenswert?

Hoi,
wenn es wirklich Debian ist, und auf die neuste Version (bullseye?) 
updated wurde, dann muss die Network Config angepasst werden.
Ich habe das schon durch, war aber zum Glück vorgewarnt ;-)
an der Configdatei für die Bridges wurde etwas geändert. Du musst die 
MAC in der Bridge eintragen.

Beschreibung:
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Linux_Bridge_MAC-Address_Change

Lösung:
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Check_Linux_Network_Bridge_MAC

jajaja ich weiss, du hast nicht Proxmox. Aber die Änderung kommt ja auch 
von systemd.

von Draco (Gast)


Lesenswert?

Jack V. schrieb:
> Hast du nicht. Die Versionsnummer deutet auf Ubuntu hin, kann aber auch
> Mint oder sowas sein.

Richtig, es ist Ubuntu Server 😊

Ich bin am verzweifeln. lspci zeigt mir niu als Treiber an. Mit modprobe 
und modinfo bekomme ich den kernel Treiber auch angezeigt.

Über dmesg | grep SUN (oder ens etc) zeigt er mir überhaupt nicht an, 
garnichts.

Einen kleinen Fortschritt habe ich allerdings:

Der Kernel wurde auf 5.4.0-80 aktualisiert - ab da trat das Problem auf. 
Ich habe nunmal in den Kernel 5.4.0-77 gebootet und siehe da: dort läuft 
alles wie gewohnt. Der Bond ist up und die Nics stehen auch alle in der 
Liste (IP a).

Kann ich, das Kernel Update wieder rückgängig machen, so daß ich auf 
Kernel 5.4.0-77 bleibe? Oder kann ich den niu Treiber daraus auf 
5.4.0-80 ziehen?! Gibt es da Wege?

von Marcello E. (leto)


Lesenswert?

Du kannst einfach den neuen Kernel löschen dan bootet das System wieder 
standartmäßig in den alten. Aber natürlich dabei mit den alten booten;-)

von Εrnst B. (ernst)


Lesenswert?

https://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_5.4.0-80.90/changelog

>    - Revert "niu: fix missing checks of niu_pci_eeprom_read"
>    - ethernet: sun: niu: fix missing checks of niu_pci_eeprom_read()

Liest sich so, als hätten die da einen Patch reingenommen und gleich 
wieder entfernt, und dabei wohl irgendwas kaputtgemacht?

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Alten kernel in hold nehmen und neuen entfernen.
1
dpkg-query -l 'linux-image-*'
2
apt-mark hold linux-image-alt-bla-bla
3
apt-get remove linux-image-neu-bla-bla

von Draco (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Alten kernel in hold nehmen und neuen entfernen.
> dpkg-query -l 'linux-image-*'
> apt-mark hold linux-image-alt-bla-bla
> apt-get remove linux-image-neu-bla-bla

Wunderbar, danke dir.

Hat funktioniert. Nun bootet er in den alten Kernel. 😊 Was mich jetzt 
aber wundert.

Ich habe ja den alten Kernel als zurück gehalten. Ist das dafür das er 
nicht gelöscht werden kann?

Ich habe den neuen Kernel gelöscht, ich ging davon aus das ich nun über 
apt update/upgrade den Kernel angeboten bekomme zum erneuten 
herunterladen. Dies ist aber nicht so. (Was ja aktuell gut ist) Wundert 
mich allerdings ein bisschen.

Oder ist das apt-mark hold dafür zuständig das nicht über diese Version 
hinaus geupdatet wird?

Vielen Dank für Infos. 😊

von Marcello E. (leto)


Lesenswert?

Draco schrieb:

> Oder ist das apt-mark hold dafür zuständig das nicht über diese Version
> hinaus geupdatet wird?


Ja genau der apt-mark hold sorgt dafür

von Daniel A. (daniel-a)


Lesenswert?

Draco schrieb:
> Ich habe ja den alten Kernel als zurück gehalten. Ist das dafür das er
> nicht gelöscht werden kann?
...
> Oder ist das apt-mark hold dafür zuständig das nicht über diese Version
> hinaus geupdatet wird?

Auf das konkrete Paket und apt-get install / autoremove bezogen, ja, 
beides. Auf den Kernel bezogen, ist das etwas komplexer, siehe unten.

> Ich habe den neuen Kernel gelöscht, ich ging davon aus das ich nun über
> apt update/upgrade den Kernel angeboten bekomme zum erneuten
> herunterladen. Dies ist aber nicht so. (Was ja aktuell gut ist) Wundert
> mich allerdings ein bisschen.

Anders als bei anderen Paketen, beinhaltet das Kernel Paket die 
Kernelversion. Es gibt dann ein Metapaket, das vom neusten Kernel 
abhängt. Unter Debian ist das "linux-image-amd64", ubuntu hat vermutlich 
auch sowas, scheint dort aber anders zu heissen.

Der Installationsmodus des Kernelpakets ist "auto", der vom Metapaket 
normalerweise "manual", glaube ich. Das Metapaket wird von autoremove 
deshalb also normalerweise nicht deinstalliert, während neue 
Kernelpakete installiert (bei apt-get upgrade) und alte Kernelpakete 
deinstalliert werden können.

Man kann parallel mehrere Kernel installieren, da diese ja andere Namen 
haben, weil die Version im Paketnamen ist, unabhängig vom Metapaket. Das 
Paket ist dann "manual" statt "auto", wird also auch nicht automatisch 
deinstalliert bei autoremove. (man kann das mit apt-mark ändern, 
apt-mark auto/manual paket und apt-mark hold/unhold paket).

Das "apt-get remove" vom neuesten Kernelpaket (sowohl lokal als auch im 
Repo), führt dazu, dass auch das Metapaket deinstalliert werden muss, 
weil das ja davon abhängt. Damit wird dieses natürlich später auch nicht 
mehr geupdatet, womit auch keine neuen Kernel mehr automatisch 
installiert werden. Um das wieder zu aktivieren, muss man also nur das 
Metapaket wieder installieren.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.