jpe101
Anmeldungsdatum: 29. April 2012
Beiträge: Zähle...
|
Hallo, ich habe genau das gleiche Problem mit einem "Ubuntu 18.04.2 LTS". Das System kommt beim Start mit IP's hoch, verliert diese aber nach wenigen Minuten wieder.
Es handelt sich hier um eine ältere VM, aufgesetzt im April 2018, die immer wieder mit aktuellen Patches versorgt wurde und bisher gab es auch keine Probleme.
Letzte Woche wurde der Virtualisierer auf dem Hostsystem gepatcht (Virtualbox 6.0.6 auf 6.0.8), sonst aber keine Änderungen an der VM vorgenommen.
Die Fehlermeldungen mit dem avahi-daemon erhalte ich auch, allerdings stimmt auf der Maschine die Zeit, so dass hier eine andere Ursache vorliegen muss. Grüße jpe101 Moderiert von kB: Abgetrennt von pc-verliert-ip-adresse-nach-start. Bitte entführe keine Threads, sondern erstelle für eigene Fragen/Probleme zur Verbesserung der Übersichtlichkeit stets ein eigenes Thema! Danke.
Bearbeitet von kB: Titel ergänzt.
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
OK, dann hier noch mal eine Beschreibung meines Problems: Seit gestern verliert meine VirtualBox-VM einige Minuten nach dem Start alle ihre IP-Adressen. Beide IP's sind über DHCP von VirtualBox zugewiesen worden.
Beim Starten sieht alles schick aus, aber später sind sie plötzlich weg.
Im Logfile ist dann folgendes zu sehen:
Jun 19 08:11:51 node1 avahi-daemon[521]: Withdrawing address record for 192.168.56.101 on enp0s8.
Jun 19 08:11:51 node1 NetworkManager[555]: <info> [1560924711.3376] manager: NetworkManager state is now CONNECTED_SITE
Jun 19 08:11:51 node1 avahi-daemon[521]: Leaving mDNS multicast group on interface enp0s8.IPv4 with address 192.168.56.101.
Jun 19 08:11:51 node1 avahi-daemon[521]: Interface enp0s8.IPv4 no longer relevant for mDNS.
Jun 19 08:11:51 node1 avahi-daemon[521]: Withdrawing address record for 10.0.2.15 on enp0s3.
Jun 19 08:11:51 node1 avahi-daemon[521]: Leaving mDNS multicast group on interface enp0s3.IPv4 with address 10.0.2.15.
Jun 19 08:11:51 node1 avahi-daemon[521]: Interface enp0s3.IPv4 no longer relevant for mDNS.
Jun 19 08:11:51 node1 dbus-daemon[541]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.12' (uid=0 pid=555 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Jun 19 08:11:51 node1 systemd[1]: Starting Network Manager Script Dispatcher Service...
Jun 19 08:11:51 node1 dbus-daemon[541]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun 19 08:11:51 node1 systemd[1]: Started Network Manager Script Dispatcher Service.
Jun 19 08:11:51 node1 nm-dispatcher: req:1 'connectivity-change': new request (1 scripts)
Jun 19 08:11:51 node1 nm-dispatcher: req:1 'connectivity-change': start running ordered scripts...
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Zeige bitte die Netzwerk-Konfiguration in der virtuellen Maschine jeweils vor und nach dem Verschwinden der IP-Adressen. Verwende dafür diese Befehle: ip -br link ; ip -4 route ; ip -4 addr ; nmcli general ; nmcli device ; nmcli connection
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
So, jetzt hab ich es nachgestellt. Vorher, mit IP's: <user>@<hostname>:~ ip -br link ; ip -4 route ; ip -4 addr ; nmcli general ; nmcli device ; nmcli connection
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3 UP 08:00:27:c8:b3:7e <BROADCAST,MULTICAST,UP,LOWER_UP>
enp0s8 UP 08:00:27:41:37:c6 <BROADCAST,MULTICAST,UP,LOWER_UP>
default via 10.0.2.1 dev enp0s3 proto dhcp metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
169.254.0.0/16 dev enp0s8 scope link metric 1000
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.101 metric 101
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp0s3
valid_lft 1100sec preferred_lft 1100sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.56.101/24 brd 192.168.56.255 scope global dynamic noprefixroute enp0s8
valid_lft 1100sec preferred_lft 1100sec
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
verbunden vollständig aktiviert aktiviert aktiviert aktiviert
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet verbunden Kabelgebundene Verbindung 1
enp0s8 ethernet verbunden Kabelgebundene Verbindung 2
lo loopback nicht verwaltet --
NAME UUID TYPE DEVICE
Kabelgebundene Verbindung 1 aa13396c-600f-359a-b6c3-b01552aa3d4c ethernet enp0s3
Kabelgebundene Verbindung 2 15e6090e-17a9-397f-9689-1d71f1ee0ff6 ethernet enp0s8
<user>@<hostname>:~ date
Do 20. Jun 12:31:43 CEST 2019 Nachher, IP's sind weg <user>@<hostname>:~ ip -br link ; ip -4 route ; ip -4 addr ; nmcli general ; nmcli device ; nmcli connection
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3 UP 08:00:27:c8:b3:7e <BROADCAST,MULTICAST,UP,LOWER_UP>
enp0s8 UP 08:00:27:41:37:c6 <BROADCAST,MULTICAST,UP,LOWER_UP>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
verbunden (nur Gelände) kein aktiviert aktiviert aktiviert aktiviert
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet verbunden Kabelgebundene Verbindung 1
enp0s8 ethernet verbunden Kabelgebundene Verbindung 2
lo loopback nicht verwaltet --
NAME UUID TYPE DEVICE
Kabelgebundene Verbindung 1 aa13396c-600f-359a-b6c3-b01552aa3d4c ethernet enp0s3
Kabelgebundene Verbindung 2 15e6090e-17a9-397f-9689-1d71f1ee0ff6 ethernet enp0s8
<user>@<hostname>:~ date
Do 20. Jun 13:01:23 CEST 2019 Im syslog und im Kernel-Log tut sich währenddessen gar nichts. Grüße jpe101
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
jpe101 schrieb: […] Beide IP's sind über DHCP von VirtualBox zugewiesen worden.
OK, ich verstehe jetzt, was Du damit meinst.
Warum soll der Gast zwei virtuelle Schnittellen haben? Wie ist das in Virtualbox konfiguriert? Wie sind die virtuellen Schnittstellen des Gastes an die Schnittstellen des Wirtes gekoppelt? Und wie sieht die Netzwerkkonfiguration des Wirtes aus? Wie hast Du sichergestellt, dass keine Loops auf Netzwerk Layer 2 entstehen?
Lege mal eine der beiden virtuellen Schnittstellen im Gast still. Bleibt die andere dann stabil?
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
Das erste Interface (enp0s3) ist das NAT-Interface für die Verbindung nach draußen. Das zweite Interface ist ein Host-Only Interface für die Kommmunikation vom Wirt zum Gast, da VirtualBox leider keine Schnittstelle im Nat-Netzwerk hat und ich sonst den gast nich vom Wirt aus erreichen kann.
Netzwerk-Konfiguration Gast in Virtualbox:
Adapter 1: Intel PRO/1000 MT Desktop (NAT-Netzwerk,"NatNetwork")
Adapter 2: Intel PRO/1000 MT Desktop (Host-only Adapter, "Virtualbox Host-Only Ethernet Adapter") Netzwerk Wirtssystem: $ ipconfig
Windows-IP-Konfiguration
Ethernet-Adapter Ethernet 3:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix: XXXXXXX
IPv4-Adresse . . . . . . . . . . : XXX.XXX.XXX.XXX
Subnetzmaske . . . . . . . . . . : XXX.XXX.XXX.XXX
Standardgateway . . . . . . . . . : XXX.XXX.XXX.XXX
Ethernet-Adapter VirtualBox Host-Only Network:
Verbindungsspezifisches DNS-Suffix:
IPv4-Adresse . . . . . . . . . . : 192.168.56.1
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
Drahtlos-LAN-Adapter Local Area Connection* 2:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Ethernet-Adapter Ethernet 2:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Ethernet-Adapter Bluetooth Network Connection:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Drahtlos-LAN-Adapter WiFi:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
Auch mit nur einem Interface (Adapter 1, NAT) das gleiche Verhalten, nach einer Weile ist die IP wieder weg
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:c8:b3:7e brd ff:ff:ff:ff:ff:ff
inet6 fe80::8e4e:7969:8480:5a86/64 scope link noprefixroute
valid_lft forever preferred_lft forever
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
jpe101 schrieb: Auch mit nur einem Interface (Adapter 1, NAT) das gleiche Verhalten, nach einer Weile ist die IP wieder weg
Habe jetzt keinen Ansatz mehr. Lasse doch mal nach dem Start der VM in einem Terminalfenster den Monitor von NetworkManager laufen bis die IPs gelöscht werden. Vielleicht ergibt das ja neue Erkenntnisse: nmcli monitor
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
Wenigstens kriegt der Monitor vom NetworkManager was mit, auch wenn es mir noch nicht weiterhilft:
Es gibt keine primäre Verbindung
Verbindungszustand ist jetzt »kein«
NetworkManager ist jetzt im Zustand »verbunden (nur Gelände)« Noch etwas ist mir aufgefallen: Wenn die IP's weg sind, dauern plötzlich sudo-Aufrufe wesentlich länger, als ob sudo irgendwo übers Netz eine Namensauflösung versucht und dort auf einen Timeout läuft.
Ich habe eine Standard /etc/sudoers, also ohne Anpassungen und ohne Host(gruppen), die er auflösen müsste.
Solange die IP's noch da sind, gehen auch die sudo-Aufrufe schnell.
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
Wie im Thread von 2016 (https://forum.ubuntuusers.de/topic/pc-verliert-ip-adresse-nach-start/) beschrieben bleiben die die IP's übrigens stabil, nachdem einmal der network-manager.service durchgestartet wurde. Dann tritt der Fehler erst wieder nach dem nächsten Reboot der VM auf.
|
kizu
Anmeldungsdatum: 31. Juli 2009
Beiträge: 669
Wohnort: Buchholz
|
Hallo jpe101, ich habe gerade nur deinen letzten Eintrag hier im Thread gelesen und würde dir vorschlagen über den Autostart einen Workaround zu basteln. Also einfach mal kurz nachdem das System hochgefaren wurde, den network-manager.service einmal automatisch neu starten lassen 😉 Entweder über systemd/Service Units oder im Userkontext mit sudo. MfG, Daniel
|
jpe101
(Themenstarter)
Anmeldungsdatum: 29. April 2012
Beiträge: 18
|
Das Problem hat sich jetzt von selbst gelöst.
Seit einen Update am 11.07.2019 tritt das Problem nicht mehr auf.
Jetzt bleiben die IP's erhalten.
Was die genaue Ursache war konnte ich aber noicht herausfinden. Gruß jpe101
|