Problem
Ich habe kürzlich einen Ubuntu 20.04-Server in ein neues Haus verlegt und versucht, ihn mit dem Netzwerk zu verbinden. In meinem vorherigen Haus funktionierte die Verbindung über ein Ethernet-Kabel problemlos, aber mit meinem neuen Modem funktioniert dies nicht. Nachdem ich bestätigt hatte, dass das Ethernet-Kabel mit meinem Laptop funktioniert, begann ich mit dem Debuggen und kam zu dem Schluss, dass ich mit Netplan etwas falsch konfiguriert hatte.
Lösungsversuch
Beim Ausführen $ ip awurde zunächst folgende Ausgabe erzeugt:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether f8:b1:56:dc:47:25 brd ff:ff:ff:ff:ff:ff
3: br-cd5031a2a690: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:88:f5:00:c2 brd ff:ff:ff:ff:ff:ff
inet 172.29.0.1/16 brd 172.29.255.255 scope global br-cd5031a2a690
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:63:c5:ed:bf brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: br-6e210ada6a5d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:cc:35:23:8d brd ff:ff:ff:ff:ff:ff
inet 172.30.0.1/16 brd 172.30.255.255 scope global br-6e210ada6a5d
valid_lft forever preferred_lft forever
inet6 fe80::42:ccff:fe35:238d/64 scope link
valid_lft forever preferred_lft forever
6: br-75e07944c75a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:cb:38:ca:3c brd ff:ff:ff:ff:ff:ff
inet 172.27.0.1/16 brd 172.27.255.255 scope global br-75e07944c75a
valid_lft forever preferred_lft forever
inet6 fe80::42:cbff:fe38:ca3c/64 scope link
valid_lft forever preferred_lft forever
8: veth5501abf@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-6e210ada6a5d state UP group default
link/ether 3e:9d:7d:bc:07:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::3c9d:7dff:febc:75f/64 scope link
valid_lft forever preferred_lft forever
10: veth5f8842d@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-75e07944c75a state UP group default
link/ether f2:f4:e9:50:51:ac brd ff:ff:ff:ff:ff:ff link-netnsid 3
inet6 fe80::f0f4:e9ff:fe50:51ac/64 scope link
valid_lft forever preferred_lft forever
12: veth6164405@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-6e210ada6a5d state UP group default
link/ether 5e:f2:e1:fd:1f:4d brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::5cf2:e1ff:fefd:1f4d/64 scope link
valid_lft forever preferred_lft forever
14: veth8f9aa5b@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-6e210ada6a5d state UP group default
link/ether 46:c8:0b:f7:c5:ac brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::44c8:bff:fef7:c5ac/64 scope link
valid_lft forever preferred_lft forever
16: vethc256b04@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-75e07944c75a state UP group default
link/ether b6:7c:3e:1e:ec:7e brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::b47c:3eff:fe1e:ec7e/64 scope link
valid_lft forever preferred_lft forever
Dies zeigte mir, dass dies eno1die Schnittstelle ist, die ich reparieren muss; alle Bridges und Veth-Schnittstellen stammen wahrscheinlich aus den Docker-Containern, die ich ausführe.
Ich habe dann meine 01-netcfg.yamlDatei auf die folgende empfohlene Konfiguration eingestellt, um eine Verbindung mit einer dynamischen, per DHCP zugewiesenen IP einzurichten:
network:
version: 2
renderer: networkd
ethernets:
eno1:
dhcp4: true
und führte Folgendes aus:
$ sudo netplan --debug generate
$ sudo netplan apply
$ sudo reboot
Die Debug-Ausgabe des Befehls „generate“ gibt Folgendes aus:
** (generate:4699): DEBUG: 04:02:19.020: Processing input file /etc/netplan/01-netcfg.yaml..
** (generate:4699): DEBUG: 04:02:19.021: starting new processing pass
** (generate:4699): DEBUG: 04:02:19.021: We have some netdefs, pass them through a final round of validation
** (generate:4699): DEBUG: 04:02:19.021: eno1: setting default backend to 1
** (generate:4699): DEBUG: 04:02:19.021: Configuration is valid
** (generate:4699): DEBUG: 04:02:19.021: Generating output files..
** (generate:4699): DEBUG: 04:02:19.021: NetworkManager: definition eno1 is not for us (backend 1)
(generate:4699): GLib-DEBUG: 04:02:19.021: posix_spawn avoided (fd close requested)
Das NetworkManager: definition eno1 is not for usscheint ein Problem zu sein, und nach dem Neustart kann ich immer noch nichts pingen:
$ ping 8.8.8.8
ping: connect: Network is unreachable
Ich habe die obigen Schritte stattdessen mit dieser empfohlenen 01-netcfg.yamlKonfiguration wiederholt und bestätigt, dass ich Leerzeichen anstelle von Tabulatoren verwende und dass meine Abstände korrekt sind:
network:
version: 2
renderer: networkd
Das Ausführen derselben Setup-Befehle mit dem Debug-Flag führt zu dieser Ausgabe:
** (generate:5041): DEBUG: 04:09:33.721: Processing input file /etc/netplan/01-netcfg.yaml..
** (generate:5041): DEBUG: 04:09:33.721: starting new processing pass
** (generate:5041): DEBUG: 04:09:33.721: We have some netdefs, pass them through a final round of validation
** (generate:5041): DEBUG: 04:09:33.721: Generating output files..
(generate:5041): GLib-DEBUG: 04:09:33.721: posix_spawn avoided (fd close requested)
NetworkManager: definition eno1 is not for uswelches die betreffende Meldung nicht mehr hat (da eno1sie nicht angegeben wurde), aber nach dem Anwenden dieser generierten Änderungen und einem Neustart bekomme ich immer noch keine Verbindung.
Ich habe eine Reihe von Beiträgen und Anleitungen verfolgt, die Variationen dieser beiden Konfigurationen zu empfehlen scheinen, aber eine, von der ich fest überzeugt bin, dass sie das gleiche Problem hat wie ich, istdieser Beitrag.
Hier weist der Verfasser darauf hin, dass ein Teil des Problems auf einen Fehler im Kernel 5.4.0-42-generic zurückzuführen sei, der durch die Installation des r8168-dkmsTreibers behoben wurde. Ich verwende ebenfalls Kernel 5.4.0-42-generic und habe diesen Treiber manuell installiert bzw. initramfs aktualisiert, hatte aber nach dem Neustart und erneuten Ausprobieren beider oben genannten Netplan-Konfigurationen immer noch kein Glück.
$ sudo lshw -class networkFalls das hilft , ist hier zusätzlich meine Ausgabe vom Ausführen :
*-network
description: Ethernet interface
product: 82579LM Gigabit Network Connection (Lewisville)
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eno1
version: 04
serial: f8:b1:56:dc:47:25
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k firmware=0.13-4 latency=0 link=no multicast=yes port=twisted pair
resources: irq:25 memory:f7c00000-f7c1ffff memory:f7c39000-f7c39fff ioport:f080(size=32)
*-network:0
description: Ethernet interface
physical id: 1
logical name: br-75e07944c75a
serial: 02:42:cb:38:ca:3c
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=172.27.0.1 link=yes multicast=yes
*-network:1
description: Ethernet interface
physical id: 2
logical name: veth5f8842d
serial: f2:f4:e9:50:51:ac
size: 10Gbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
*-network:2
description: Ethernet interface
physical id: 3
logical name: vethc256b04
serial: b6:7c:3e:1e:ec:7e
size: 10Gbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
*-network:3
description: Ethernet interface
physical id: 4
logical name: br-6e210ada6a5d
serial: 02:42:cc:35:23:8d
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=172.30.0.1 link=yes multicast=yes
*-network:4
description: Ethernet interface
physical id: 5
logical name: veth5501abf
serial: 3e:9d:7d:bc:07:5f
size: 10Gbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
*-network:5
description: Ethernet interface
physical id: 6
logical name: br-cd5031a2a690
serial: 02:42:88:f5:00:c2
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=172.29.0.1 link=no multicast=yes
*-network:6
description: Ethernet interface
physical id: 7
logical name: docker0
serial: 02:42:63:c5:ed:bf
capabilities: ethernet physical
configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=172.17.0.1 link=no multicast=yes
*-network:7
description: Ethernet interface
physical id: 8
logical name: veth6164405
serial: 5e:f2:e1:fd:1f:4d
size: 10Gbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
*-network:8
description: Ethernet interface
physical id: 9
logical name: veth8f9aa5b
serial: 46:c8:0b:f7:c5:ac
size: 10Gbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
Anfrage
Könnte mir jemand helfen, dieses Problem mit Netplan zu beheben und Ethernet auf meinem Server wieder zum Laufen zu bringen? Ich bin für Ihre Hilfe wirklich dankbar. Wenn Sie weitere Informationen von mir benötigen, fragen Sie einfach :)
Antwort1
Die angezeigte Ausgabe NetworkManager: definition eno1 is not for uswar korrekt; sie sagt Ihnen lediglich, dass diese Schnittstelle vom networkdBackend und nicht von dem NetworkManagereinen verwaltet wird. Als Sie die Verweise auf eno1aus Ihrem YAML entfernt haben, haben Sie Netplan angewiesen, keine Schnittstellen zu konfigurieren, was Sie nicht möchten.
Und Ihre ip aAusgabe zeigt, dass die eno1Schnittstelle als aufgeführt ist NO-CARRIER. Dies zeigt im Allgemeinen an, dass Ihre Hardware eine Verbindungserkennung unterstützt und in diesem Fall erkannt hat, dass keine Verbindung besteht. Sie müssen also möglicherweise ein anderes Ethernet-Kabel ausprobieren, überprüfen, ob Ihr Kabel richtig sitzt, und versuchen, eine Verbindung zu einem anderen Gerät als Ihrem Modem herzustellen, um zu überprüfen, dass es sich nicht um ein Modemproblem handelt.