[Debian Server 20.04] NIC verweigert plötzlich arbeit - was tun?

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.

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.

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;-)

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?

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

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.