3
System für 2ten Rechner 1:1 kopiert, nun langsamer Start im Netzwerkbereich
Moin,
ich hab ein Hauptsystem was ich weitesgehend 1:1 auch auf einen 2ten System benötige.
Also: eine 1:1 kopie gemacht undohne Netzwerk hochgefahren.
Dann:
Hier habe ich alles angepasst.
Da das System auf DHCP ist, hab ich die IP-Adressse in der Fritte fest eingestellt.
Danach dann Reboot mit Netzwerk.
Beim Booten sehe ich schon dass er im Netzwerkbereich mehrere Minuten lang hängt.
Anbei ein Logauszug wo große Wartezeiten sind. Vorne die Zeiten beachten:
Der Auszug ist bis auf die letzte Zeile zusammenhängend. Die Absätze sind die entsprechenden Bereiche die von Interesse sein sollten
Netzwerk besteht und IP binnen 1-2 Sekunden bezogen.
Und dann macht ein Dienst (systemd-networkd-wait-online) irgendwas was mehr als 2min dauert.
Lt Googel macht dieser:
Soweit ok. Netzwerk hat er ja hergestellt. Fraglich ist nun, auf was er wartet.
Woher enp111s0 entzieht sich gänzlich meines Wissens.
Das MB hat 2 Netzwerkkarten. aber nur in der 2,5GB Buchse steckt ein Kabel.
Das MB hat aber auch 4 Thunderbold-Anschlüsse. Die sind ja auch Netzwerkfähig. Aber da steckt nichts drin.
Weiß einer Rat was er da macht und was enp111s0 für eine Schnittstelle ist ?
ich hab ein Hauptsystem was ich weitesgehend 1:1 auch auf einen 2ten System benötige.
Also: eine 1:1 kopie gemacht undohne Netzwerk hochgefahren.
Dann:
sudo nano /etc/hostname
sudo nano /etc/hosts
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-serverDa das System auf DHCP ist, hab ich die IP-Adressse in der Fritte fest eingestellt.
Danach dann Reboot mit Netzwerk.
Beim Booten sehe ich schon dass er im Netzwerkbereich mehrere Minuten lang hängt.
Anbei ein Logauszug wo große Wartezeiten sind. Vorne die Zeiten beachten:
Der Auszug ist bis auf die letzte Zeile zusammenhängend. Die Absätze sind die entsprechenden Bereiche die von Interesse sein sollten
Jun 3 17:55:05 harvester2 snapd[978]: daemon.go:347: started snapd/2.50.1 (series 16; classic) ubuntu/20.04 (amd64) linux/5.4.0-73-generic.
Jun 3 17:55:05 harvester2 snapd[978]: daemon.go:440: adjusting startup timeout by 45s (pessimistic estimate of 30s plus 5s per snap)
Jun 3 17:55:05 harvester2 systemd[1]: tmp-sanity\x2dmountpoint\x2d671823329.mount: Succeeded.
Jun 3 17:55:05 harvester2 systemd[1]: Started Snap Daemon.
Jun 3 17:55:05 harvester2 systemd[1]: Finished Wait until snapd is fully seeded.
Jun 3 17:55:05 harvester2 systemd[1]: Condition check resulted in Auto import assertions from block devices being skipped.
Jun 3 17:55:05 harvester2 lxd.activate[924]: ==> Setting LXD socket ownership
Jun 3 17:55:05 harvester2 lxd.activate[924]: ==> LXD never started on this system, no need to start it now
Jun 3 17:55:05 harvester2 systemd[1]: snap.lxd.activate.service: Succeeded.
Jun 3 17:55:05 harvester2 systemd[1]: Finished Service for snap application lxd.activate.
Jun 3 17:55:06 harvester2 kernel: [ 51.656353] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Jun 3 17:55:06 harvester2 kernel: [ 51.656462] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
Jun 3 17:55:06 harvester2 systemd-networkd[563]: eno1: Gained carrier
Jun 3 17:55:06 harvester2 systemd-networkd[563]: eno1: DHCPv4 address 192.168.0.152/24 via 192.168.0.1
Jun 3 17:55:06 harvester2 systemd-timesyncd[865]: Network configuration changed, trying to establish connection.
Jun 3 17:55:06 harvester2 systemd-timesyncd[865]: Initial synchronization to time server 192.168.0.1:123 (192.168.0.1).**
Jun 3 17:55:07 harvester2 glances[922]: Error while initializing the ip plugin ('NoneType' object has no attribute 'split')
Jun 3 17:55:07 harvester2 systemd[1]: systemd-rfkill.service: Succeeded.
Jun 3 17:55:07 harvester2 kernel: [ 52.669053] ucsi_acpi USBC000:00: PPM NOT RESPONDING
Jun 3 17:55:07 harvester2 kernel: [ 52.670189] ucsi_acpi USBC000:00: PPM init failed (-110)
Jun 3 17:55:08 harvester2 snapd[978]: storehelpers.go:551: cannot refresh: snap has no updates available: "core18", "lxd", "snapd"
Jun 3 17:55:08 harvester2 snapd[978]: autorefresh.go:479: auto-refresh: all snaps are up-to-date
Jun 3 17:55:08 harvester2 systemd-networkd[563]: eno1: Gained IPv6LL
Jun 3 17:55:08 harvester2 systemd-networkd-wait-online[640]: managing: eno1
Jun 3 17:55:08 harvester2 set-cpufreq[908]: Setting powersave scheduler for all CPUs
Jun 3 17:55:08 harvester2 systemd[1]: ondemand.service: Succeeded.
Jun 3 17:55:08 harvester2 systemd[1]: dmesg.service: Succeeded.
Jun 3 17:55:33 harvester2 systemd[1]: systemd-fsckd.service: Succeeded.
Jun 3 17:57:02 harvester2 systemd-networkd-wait-online[640]: Event loop failed: Connection timed out
Jun 3 17:57:02 harvester2 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Jun 3 17:57:02 harvester2 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Jun 3 17:57:02 harvester2 systemd[1]: Failed to start Wait for Network to be Configured.
Jun 3 17:57:02 harvester2 systemd[1]: Reached target Network is Online.
Jun 3 17:57:02 harvester2 systemd[1]: Condition check resulted in Login to default iSCSI targets being skipped.
Jun 3 17:57:02 harvester2 systemd[1]: Reached target Remote File Systems (Pre).
Jun 3 17:57:02 harvester2 systemd[1]: Reached target Remote File Systems.
Jun 3 17:57:02 harvester2 systemd[1]: Starting LSB: automatic crash report generation...
Jun 3 17:57:02 harvester2 systemd[1]: Starting Deferred execution scheduler...
Jun 3 17:57:02 harvester2 systemd[1]: Starting Availability of block devices...
Jun 3 17:57:02 harvester2 systemd[1]: Started Regular background program processing daemon.
Jun 3 17:57:02 harvester2 systemd[1]: Starting LSB: disk temperature monitoring daemon...
Jun 3 17:57:02 harvester2 systemd[1]: Starting LSB: Load kernel modules needed to enable cpufreq scaling...
Jun 3 17:57:02 harvester2 systemd[1]: Condition check resulted in Pollinate to seed the pseudo random number generator being skipped.
[..]
Jun 3 17:57:02 harvester2 systemd[1]: Startup finished in 8.862s (firmware) + 7.155s (loader) + 45.180s (kernel) + 2min 1.873s (userspace) = 3min 3.071s. Netzwerk besteht und IP binnen 1-2 Sekunden bezogen.
Und dann macht ein Dienst (systemd-networkd-wait-online) irgendwas was mehr als 2min dauert.
Lt Googel macht dieser:
Systemd-networkd-wait-online ist ein einmalig ausgeführter Systemdienst, der darauf
wartet, dass das Netzwerk eingerichtet wird. In der Voreinstellung werden alle
Netzwerkschnittstellen berücksichtigt, die Systemd-networkd.service(8) bekannt sind und
davon verwaltet werden. Maßgebend ist hierbei die vollständige Einrichtung der Verbindung
oder deren Fehlschlag, beziehungsweise mindestens eine verfügbare Leitung.
wartet, dass das Netzwerk eingerichtet wird. In der Voreinstellung werden alle
Netzwerkschnittstellen berücksichtigt, die Systemd-networkd.service(8) bekannt sind und
davon verwaltet werden. Maßgebend ist hierbei die vollständige Einrichtung der Verbindung
oder deren Fehlschlag, beziehungsweise mindestens eine verfügbare Leitung.
Soweit ok. Netzwerk hat er ja hergestellt. Fraglich ist nun, auf was er wartet.
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.152 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::a6ae:12ff:fe77:2598 prefixlen 64 scopeid 0x20<link>
ether a4:ae:12:77:25:98 txqueuelen 1000 (Ethernet)
RX packets 8718 bytes 850907 (850.9 KB)
RX errors 0 dropped 1346 overruns 0 frame 0
TX packets 8838 bytes 2792724 (2.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0x8e500000-8e520000
enp111s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether a4:ae:12:77:25:97 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0x8e100000-8e17ffff
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 58 bytes 4192 (4.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 58 bytes 4192 (4.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Woher enp111s0 entzieht sich gänzlich meines Wissens.
Das MB hat 2 Netzwerkkarten. aber nur in der 2,5GB Buchse steckt ein Kabel.
Das MB hat aber auch 4 Thunderbold-Anschlüsse. Die sind ja auch Netzwerkfähig. Aber da steckt nichts drin.
Weiß einer Rat was er da macht und was enp111s0 für eine Schnittstelle ist ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667299
Url: https://administrator.de/contentid/667299
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
3 Kommentare
Neuester Kommentar
Zur Verzögerung: Möglicherweise ein anderes Netzwerk? /etc/resolv.conf angepasst?
2 Minuten (120 Sek.) ist der default Wert, bevor der Dienst in einen timeout läuft, siehe auch:
https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-o ...
(-> Abschnitt "--timeout")
Dein eno1 Interface wird ja korrekt erkannt, aber bei dem enp111s0 scheint es so, als sei das weder ein success noch ein fail (?)
Der Dienst jedoch wartet, bis er von ALLEN ihm bekannten Interfaces einen Status erhält (alternativ rennt er halt irgendwann in den timeout).
Hier werden "some corner cases, like having two ethernet interfaces" erwähnt:
https://unix.stackexchange.com/questions/381448/systemd-networkd-wait-on ...
Workaround wäre eine Anpassung des Service mit:
und dann mit --ignore oder auch --any arbeiten
https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-o ...
(-> Abschnitt "--timeout")
Dein eno1 Interface wird ja korrekt erkannt, aber bei dem enp111s0 scheint es so, als sei das weder ein success noch ein fail (?)
Der Dienst jedoch wartet, bis er von ALLEN ihm bekannten Interfaces einen Status erhält (alternativ rennt er halt irgendwann in den timeout).
Hier werden "some corner cases, like having two ethernet interfaces" erwähnt:
https://unix.stackexchange.com/questions/381448/systemd-networkd-wait-on ...
Workaround wäre eine Anpassung des Service mit:
sudo systemctl edit systemd-networkd-wait-online.service
Hallo lord-icon,
enoX ist, wie auch enpXsY ist die durch systemd automatisierte Bezeichnung einer Netzwerkschnittstelle:
Guckst Du: https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
Wobei enpXsY einen fallback darstellt. Schau vielleicht mal nach, aber ich tippe mal, Dein Hauptsystem läuft mit einer enpXsY-Schnittstelle (vielleicht kein on-Board-NIC) und beim Neustart auf dem neuen System hat systemd die Schnittstelle als enoX namenstauglich (also on-Board-NIC) erkannt und ergänzt (siehe Link).
Vielleicht gibt es eine alte config, die das auslöst? Weiß ich aber nicht. Eigentlich wird das ja automatisch vergeben. Gibt es vielleicht in dem neuen Host eine zweite Netzwerkkarte. Ein nicht korrekt erkannter Adapter führt beim Start zu dem vom Kollegen @HanTrio bezeichneten Verhalten.
Gruß commodity
enoX ist, wie auch enpXsY ist die durch systemd automatisierte Bezeichnung einer Netzwerkschnittstelle:
Guckst Du: https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
Wobei enpXsY einen fallback darstellt. Schau vielleicht mal nach, aber ich tippe mal, Dein Hauptsystem läuft mit einer enpXsY-Schnittstelle (vielleicht kein on-Board-NIC) und beim Neustart auf dem neuen System hat systemd die Schnittstelle als enoX namenstauglich (also on-Board-NIC) erkannt und ergänzt (siehe Link).
Vielleicht gibt es eine alte config, die das auslöst? Weiß ich aber nicht. Eigentlich wird das ja automatisch vergeben. Gibt es vielleicht in dem neuen Host eine zweite Netzwerkkarte. Ein nicht korrekt erkannter Adapter führt beim Start zu dem vom Kollegen @HanTrio bezeichneten Verhalten.
Gruß commodity
