System hat kein Netzzugang mehr seit Upgrade von 10 auf 11

[tempelorg]

Hallo allesamt. Ich habe mich grad hier im Forum angemeldet, weil ich Hilfe brauche: Nach dem upgrade auf bullseye ist mein Debian-System scheintot.

Ein wenig Background:

Ich bin hauptsächlich Mac-User (und Entwickler) - bei Linux stecke ich nicht tief drin. Ich habe seit Jahren bei Hetzner nen Root-Server auf dem ich einige Services laufen habe (inkl. VMware Workstation, auf dem eine Mac-VM läuft).

Ich hatte das System damals direkt von Hetzner installieren lassen, also nix Individuelles. Hatte dann auch erfolgreich von 8 auf 9 und 10 upgraden können. Aber jetzt bei 11 komme ich nur noch über eine Remote-KVM an den Rechner.

Immerhin bootet er noch, und ich kann mich über die KVM-Console einloggen. Allerdings geht der Monitor nur auf 640x480, womit es sehr schwierig ist zu arbeiten. Aber Netzwerk ist tot, d.h. nix geht raus oder rein. "ip addr" zeigt immerhin noch die IP-Adr des PCs auf der "br0"-Schnittstelle, wobei ich nicht sicher bin, ob ich die dort fest eingestellt habe.

Immerhin geht auch das Rescue-System, bei dem ein Notsystem gebootet wird, und ich kann dann darauf per SSH zugreifen und dann das "normale" volume mounten.

Und nun zum eigentlichen Problem

Ein Tipp von einem Hetzner-Mitarbeiter war, daß ich mal prüfen solle, ob ich vom alten init.d-System auf das neue umsteigen müsse.

Über das Rescue-System kann ich sehen, daß es im /etc ein init.d-Dir gibt. Auch ein "/etc/systemd" gibt es. Allerdings weiß ich nicht, was ich nun tun soll.

Ich hatte einen ähnlichen Beitrag gelesen (viewtopic.php?t=181686). Bei mir kommt Ähnliches raus wie dort für `ip addr`. Aber schon ein `lsmod` wird schwierig, weil ich das ja auf dem "kaputten" System ausführen muss, und da komme ich derzeit nur per KVM dran, mit dem 640x480-Bildschirm. Davon kann ich nicht alles abschreiben (ich könnte Bildschirmfotos machen). Auch Schreiben der Ausgaben in ein File bringt nichts, weil ich das File ja nicht übertragen kann, weil kein Netz.

Wie komme ich da nun weiter?

Und: Gibt's hier jmd, der gg. Bezahlung sich die Sache heute (Mit) mal ansehen würde? Bin übrigens in München, falls das relevant wäre.

So, jetzt bin ich körperlich und psychisch am Ende. Gute Nacht erstmal.

[DeletedUserReAsG]

"ip addr" zeigt immerhin noch die IP-Adr des PCs auf der "br0"-Schnittstelle

Außer br0 zeigt es keine andere Schnittstelle, also nicht einmal lo? Dann wäre da einiges mehr kaputt, als nur die Netzwerkkonfiguration. Oder zeigt es die anderen Interfaces, darunter eines, das mit „e“ beginnt? Dann müsste das nur konfiguriert werden – eine der wahrscheinlicheren Ursachen in dem Fall wäre, dass sich schlicht die Interfacebezeichnung geändert hat. Kam wohl bei dem Update auf 11 häufiger vor, zumindest gibt’s hier mehrere Threads mit dem Problem.

Anyway – der erste Schritt im Fehlerfall ist üblicherweise, ins Log/Journal zu schauen. Wenn du ein Rescuesystem starten kannst, wie du schreibst, kannst du bequem von da aus reinschauen, und es ggf. nach pastebin/ o.Ä. schieben, wenn du selbst damit nicht weiterkommst. Es bietet sich an, nicht das gesamte Journal hochzuschieben, sondern lediglich den Teil vom letzten Bootversuch.

[oln]

Moin,
der Inhalt der Datei /etc/network/interfaces wäre hier sicher nicht schlecht.
Im Fall das dort nichts dirn steht, dann die Ausgabe von networkctl und der Inhalt des Ordners /etc/systemd/network/.
Dann schauen wir mal weiter.

[mat6937]

Ein Tipp von einem Hetzner-Mitarbeiter war, daß ich mal prüfen solle, ob ich vom alten init.d-System auf das neue umsteigen müsse.

Schau mal im Internet nach "systemd vs. sysvinit".

[MSfree]

Ein Tipp von einem Hetzner-Mitarbeiter war, daß ich mal prüfen solle, ob ich vom alten init.d-System auf das neue umsteigen müsse.

Schau mal im Internet nach "systemd vs. sysvinit".

Dieser Tip schafft mehr Verwirrung als es hilft. Debian nutzt seit Jessie (Debian 8 ) systemd (zumindest, wenn man sich bei der Installation nicht massiv dagegen gewehrt hat und vom vorgegebenen Installationsweg abgewichen ist). Beim Upgrade von Debian 10 auf 11 ist das also irrelevant.

Zwischen Debian 10 und Debian 11 hat sich vor netzwerkseitig vor allem geändert, daß die sogenannten "predictable Network Names" für die Netzwerkschnittstellen als Voreinstellung eingeführt wurden. Die Netzwerkschnittstelle heißt nun nicht mehr wie früher eth0 sondern bekommt einen völlig unvorhersehbaren Namen (soviel zur Ironie der predictable Network Names). Den Namen bekommt man nun nur noch mit dem Befehl

Code: Alles auswählen

ip a

oder

Code: Alles auswählen

dmesg | grep "renamed from"

heraus. Mit dem neuen Netzwerknamen muß die Datei /etc/network/interfaces angepaßt werden. Debian 10 hat bei der Installation noch mit /etc/network/interfaces gearbeitet, so daß dies beim Upgrae erhalten bleibt. Eine Debian 11 Neuisntallation kommt inzwischen aber ohne etc/network/interfaces aus.

[mat6937]

Dieser Tip schafft mehr Verwirrung als es hilft.

Das Gegenteil ist der Fall. Dieser Tipp sorgt dafür, dass der TE der Aussage des Hetzner-Mitarbeiters, evtl. keine "besondere" Bedeutung und Relevanz zumessen soll.

[tempelorg]

Guten morgen, liebe Helfer!

Ich bin grad aufgestanden und freue mich über die vielen Kommentare.

Also mal alle Antworten hier auf einmal.

1. Ich bin jetzt erstmal im Rescue-System, also nicht im eigenlichen Deb 11, d.h. ich kann nur die Dateien ansehen, aber nicht Befehle ausführen. Wenn ich das kaputte System neu boote, kann ich ja nur über das Remote-KVM dran, was mich jedesmal nun 10€ kostet, daher möchte ich die Anzahl dafür gering halten.

2.

...

Ja, es gibt auch eine "lo". Es sind 4 Schnittstellen gelistet, wenn ich mich recht erinnere.

Das systemd-journal habe ich unter `/var/log/journal/.../ gefunden. Allerdings ist das komprimiert oder kodiert. Wie komme ich an den Text ran?

... Ah! mit `journalctl -D pfad` geht das. Bin grad dabei, das rauszupfriemeln.

So, Bootlog hier, mit nicht-Network-Zeug rausgeworfen:

https://pastebin.com/WTtYcBjH

3.

...

Der Content von `/etc/network/interfaces`, alle Kommentare entfernt für Kürze (habe meine IP-Adr verfälscht):

Code: Alles auswählen

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback
iface lo inet6 loopback

iface enp0s31f6 inet6 static
  address 2a01:4f8:10a:284::2
  netmask 64
  gateway fe80::1

auto  br0
iface br0 inet static
 address 99.88.77.79
 netmask 255.255.255.192
 gateway 99.88.77.65
 bridge_ports enp0s31f6
 bridge_stp off
 bridge_fd 1
 bridge_hello 2
 bridge_maxage 12

4. Es gibt im /etc ein `init.d`- und ein `systemd`-Verzeichnis. `/etc/systemd/network` ist leer.
`/etc/systemd/networkd.conf` und `/etc/systemd/resolved.conf` enthalten nur auskommentierte Zeilen (abgesehen von Section-Headern wie "[DHCP]". Kein Dir namens `/etc/systemd/resolved.conf.d` vorhanden (das fand ich aber auf dem Rescue-System, das auch Deb 11 benutzt). Damit vergleiche ich grad Einiges.

5.

...

Wg. Netzwerknamen: Ich glaube, daß ich, als ich das kaputte System über KVM bediente, `ifconfig` mir weiterhin `eth0` und nicht einen random-Namen zeigte.

Kann ich jetzt den Output von `ip a` auch irgendwie aus den statischen Dateien rausfinden?

Ah! ist es vielleicht "enp0s31f6"? Ach nee – da ich ja glaube, bei `ifconfig` noch "eth0" gesehen zu haben, in `/etc/network/interfaces` aber schon "enp0s31f6" steht, macht das keinen Sinn. Oder?

Ahhhh! Nachdem ich das komplette journal für den Bootvorhang printen konnte, fand ich darin auch dies:

22:47:08 kernel: e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0

Das steht allerdings nicht in dem pastebin, weil ich im Pastebin erst ab der Meldung "Starting Network Manager" begonnen habe. Dass das mit dem eth0 schon früher passiert, damit hatte ich nicht gerechnet.

D.h, das ist der neue Name. Aber der steht ja auch schon so in networkd.conf drin. Hmmm.

Würde es übrigens helfen, die Dateien vom System vor dem Upgrade anzusehen? Die gibt's noch auf einem Backup-Volume.

(Hach, wie schön wäre es doch, wenn man jetzt das problematische System einfach so in einer VM starten könnte, so daß ich das laufende System dann mit Tastatur- und Bildschirm-Simulation bedienen könnte).

Vielen Dank soweit euch allen!

[oln]

Moin,
was MSFree geschreiben hat ist schon wichtig. Ohne den InterfaceNamen wird es nicht klappen. Ob der angegebene(enp0s31f6) richtig ist, siehst du mit dem oben genannten Befehl.

Was mir in deiner interfaces aufgefallen ist, dass ein Eintrag fehlt.
Eingentlich gehört noch folgendes dazu:

Code: Alles auswählen

iface deinInterfaceName inet manual

Deine interfaces sollte dann in etwa so aussehen:

Code: Alles auswählen

auto lo
iface lo inet loopback
iface lo inet6 loopback

#Brauchst du IPv6? ansonsten auskommentieren
#iface enp0s31f6 inet6 static
 # address 2a01:4f8:10a:284::2
 # netmask 64
 # gateway fe80::1
  
iface deinInterfaceName inet manual

auto  br0

iface br0 inet static
 address 99.88.77.79
 netmask 255.255.255.192
 gateway 99.88.77.65
 bridge_ports deinInterfaceName 
 bridge_stp off
 bridge_fd 1
 bridge_hello 2
 bridge_maxage 12

[tempelorg]

was MSFree geschreiben hat ist schon wichtig. Ohne den InterfaceNamen wird es nicht klappen. Ob der angegebene(enp0s31f6) richtig ist, siehst du mit dem oben genannten Befehl.

Wie schon vorhin geschrieben, bin ich im Rescue-System, und da kann ich keine Befehle für das kaputte System ausführen. Aber ich hatte grad, als du geantwortet hast, noch am Ende was hinzugefügt: Ich habe den "renamed from" im journal gefunden. Der stimmt also wohl.

Werde deine Änderung mal probieren und abwarten, ob das System dann ins Netz kommt, und sonst zurück ins Rescue booten. Danach melde ich mich wieder.

... Und es brachte nichts. Ein Vergleich der journals (allerdings nur für Zeilen mit "NetworkManager") zeigt einen Unterschied:

Im alten journal stand noch die, in der neuen fehlt die Zeile. Das hat wohl deine Änderung an den Interfaces erwirkt:

Code: Alles auswählen

NetworkManager[…]: <info>  […] ifupdown: guessed connection type (enp0s31f6) = 802-3-ethernet

Ich hoffe, daß jemand was aus dem Bootlog erkennen kann.

[MSfree]

enp0s31f6: renamed from eth0

enp0s31f6 ist der Name der Netzwerkschnittstelle, die für das neue System gültig ist.

Wie schon vorhin geschrieben, bin ich im Rescue-System, und da kann ich keine Befehle für das kaputte System ausführen.

Kannst du nicht die Festplatte mithilfe des Rettungssystems mounten und mit chroot dort hinein wechseln? Vieles wird dann trotzdem nicht korrekt funktionieren, aber du kannst damit zumindest Dateien editieren und speichern.

[tempelorg]

Kannst du nicht die Festplatte mithilfe des Rettungssystems mounten

Das tue ich doch bereits, sonst würde ich ja nicht die Dateien einsehen können. Das System-Volume habe ich unter `/mnt` gemountet.

und mit chroot dort hinein wechseln? Vieles wird dann trotzdem nicht korrekt funktionieren, aber du kannst damit zumindest Dateien editieren und speichern.

`chroot` habe ich nie benutzt. Heißt das, dass dann mein Root zu dem wird, was in /mnt liegt? Dann würde zumindest absolute symlinks passen, nicht wahr? Hab's probiert - ja, wie erwartet. Aber viele Cmds gehen trotzdem nicht, wie z.B. "update-grub", nachdem ich "nomodeset" aus den defaults entfernt habe, in der Hoffnung, daß das den KVM-Bildschirm wieder größer macht.

Aber viel macht das auch nicht aus - zum Testen des Bootvorgangs muss ich weiter das System blind starten oder jedesmal 10€ für den KVM bezahlen, nur damit ich dann im Terminal des laufenden Systems ein paar Befehle auf einem winzigen Bildschirm eingeben kann. Wenn ihr ne Vorstellung habt, was ich da dann im Terminal testen und ändern sollte, um rauszufinden, was mit dem Netzwerk nicht geht, kann ich das gern probieren. Ganz einfache Netzwerke, wo es lediglich ein eth0 gibt, und das hochzufahren, habe ich früher auch schon selbst hinbekommen. Aber sobald ne Bridge, wie hier, drin liegt, verstehe ich es schon nicht mehr. Ich hatte deswegen schon öfter Probleme, um andere Netzwerk-Services auf dem System zu aktivieren (VPN-Server zB) und bin jedesmal an der Bridge gescheitert.

[oln]

Moin,
du benötigst KVM nicht. Das Rescue-System reicht aus. Hier wird beschreiben wie du es nutzt.
Nach dem editieren solltest du das Netzwerk neu starten:

Code: Alles auswählen

/etc/init.d/networking restart

Dann schau nach mit ip a ob alles da ist. Wenn ja sollte auch ein ping auf einen externen Host möglich sein.

[MSfree]

Ganz einfache Netzwerke, wo es lediglich ein eth0 gibt, und das hochzufahren, habe ich früher auch schon selbst hinbekommen. Aber sobald ne Bridge, wie hier, drin liegt, verstehe ich es schon nicht mehr. Ich hatte deswegen schon öfter Probleme, um andere Netzwerk-Services auf dem System zu aktivieren (VPN-Server zB) und bin jedesmal an der Bridge gescheitert.

Wozu brauchst du überhaupt eine Bridge?

Für OpenVPN braucht man sie jedenfalls nicht. OpenVPN kennt zwei Modi, einmal den bridged Modus und dann den routed Modus. Als routed VPN braucht man die Bridge nicht, was übrigens stabiler und letztlich auch performanter ist. Die Konfiguration ist dann allerdings ein wenig komplizierter, aber man sperrt sich nicht aus, wenn die Bridge mal nicht will.

Ich sehe auch nicht, daß du virtuelle Maschinen auf der Kiste laufen hast, für die eine Bridge hilfreich sein kann.

Es gäbe auch noch die Möglichkeit, eine Bridge (wenn es unbedingt sein muß) mithilfe von systemd einzurichten. Wie das geht, habe ich in diesem Thread skizziert: viewtopic.php?p=1297007&#p1297007

Und dein Auflösungsproblem, damit wirst du leben müssen. Ich weiß zwar nicht, was auf deiner Kiste alles installiert ist und läuft, aber ein graphisches Subsystem gehört eigentlich sowieso nicht auf einen Server. Und im Textmodus ist 640x480 völlig ausreichend. Jedenfalls wirst du mit xrandr nicht ausrichten können, solange das Teil im Textmodus läuft.

[tempelorg]

du benötigst KVM nicht. Das Rescue-System reicht aus. Hier wird beschreiben wie du es nutzt.

Ja, den kannte ich schon - da sah ich auch chroot zum 1. Mal.

Allerdings: Erst jetzt entdeckte ich den Link zur Alternativ mit vkvm. Das ist ja genau, was ich mir gewünscht hatte: Mein System in einer VM ausführen. Das probiere ich jetzt mal aus.

Wozu brauchst du überhaupt eine Bridge?

Weil ich die für meine VM (basiert auf vmware workstation) brauche, die ihre eigene IP-Adr bekommt. Die Bridge hatte ich damals nach Anleitung von Hetzner so angelegt, soweit ich mich erinnern kann.

Ein Freund meinte allerdings, daß ich dennoch das Haupt-Interface direkt auf dem eth-Interface anlegen solle, und die Bridge würde dann immer noch von der VM nutzbar sein. Ob das wirklich geht, muss ich noch ausprobieren.

Ich sehe auch nicht, daß du virtuelle Maschinen auf der Kiste laufen hast, für die eine Bridge hilfreich sein kann.

Das vollständige Journal auf meinem Server erwähnt "vmware".

vmware automatisch zu starten war für mich auch ein Problem. Ich glaube, die starte ich am Ende über eines der startup-scripts. Läuft als Root, weil ich es als normaler user nicht dazu bekam, daß es dann beim booten auch die VM neu startet. Ist natürlich etwas gefährlich, falls mal jemand auf die VM einbricht und rausfindet, wie es dann aus der VM ausbrechen kann. Wenn daher jemand nen Vorschlag hat... aber das ist eher ein Fall für das vmware-Forum, denke ich.

Neue Frage

Das root-Listing meines volumes listet u.A:

Code: Alles auswählen

lrwxrwxrwx   1 root root    31 Nov 15 20:58 initrd.img -> boot/initrd.img-5.10.0-18-amd64
lrwxrwxrwx   1 root root    31 Nov 15 20:58 initrd.img.old -> boot/initrd.img-4.19.0-22-amd64
lrwxrwxrwx   1 root root    28 Nov 15 20:58 vmlinuz -> boot/vmlinuz-5.10.0-18-amd64
lrwxrwxrwx   1 root root    28 Nov 15 20:58 vmlinuz.old -> boot/vmlinuz-4.19.0-22-amd64

Allerdings hat, als ich das kaputte System über KVM gebootet hatte, "uname -r", daß die Version bei 5.10.1xx oder sowas war, also viel höher. Wie passt das zusammen?

Übrigens: Falls jmd. von euch auch nen Mac benutzt, oder echte Freunde hat, die es tun – ich kann euch als Dank ne Lizenz für meine Programme Find Any File (die Beta kann auch komplexes Matching mit lua-scripts machen) und iClip schenken. Einfach ne PM schicken - muss ja nicht jeder wissen

[tempelorg]

So, nachdem ich mein System nun in Qemu booten konnte, kann ich endlich nmcli ausführen. Allerdings stellt sich heraus, daß dann gerade die Netzwerk-Interfaces anders angelegt werden, was mir nicht zum Debuggen hilft. Jetzt lasse ich nochmal ein KVM anbringen (die 10€ werden übrigens nur berechnet, wenn man pro Tag mehr als die freien 3 Std braucht, also grad kein Problem).

[DeletedUserReAsG]

Was ist denn nun der genaue Stand? Hängt’s immer noch an der Netzwerk-Konfiguration? Du brauchst deine IP, dein Gateway und ggf. dein Netz – alles Infos, die im Rescuesystem passend vorliegen. Mit diesen Daten kannst du dein Interface statisch konfigurieren, und im Anschluss wieder direkt drauf zugreifen. Dann kannst du dich um den Rest kümmern, ohne das Gehampel mit KVM und wasnichtalles.

[tempelorg]

Es läuft nun erstmal wieder mit dem Netzwerk. Dazu mußte ich lediglich die IP-Settings für die "br0" zum Ethernet-Interface verschieben.

Allerdings startete die VMware-Workstation nicht mehr. Nach weiteren 2 Stunden habe ich dann die Patches gefunden und nun geht die auch wieder.

WebMin geht auch, VPN (lokal) auch, Jitsi muss ich noch wieder installieren.

Vielen Dank nochmal für all eure Hilfe.