[Workaround] Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM (e100)

Debian auf Notebooks und speziellen Geräten wie eingebetteten Systemen, Routern, Set-Top-Boxen, ...
Antworten
Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

[Workaround] Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM (e100)

Beitrag von hikaru » 06.10.2021 19:08:42

Hallo,

ich habe hier ein altes Core2Duo-Notebook, das unter Buster mit Xfce noch problemlos lief. Auch unter Bullseye tut es das, so lange ich es nicht in Suspend2RAM schicke.
Wenn ich das aber tue, dann bekomme ich zwei Probleme:

1. Debiannetwork-manager-gnome stellt die Verbindung (egal ob LAN oder WLAN nicht wieder her). Außerdem friert nach ein bis zwei Minuten die gesamte grafische Oberfläche ein. Die virtuellen Terminals funktionieren aber noch.

2. Ein nach so einem Suspend-Zyklus ausgeführter poweroff/reboot fahren zwar das Betriebssystem und die HDDs herunter, aber das Notebook selbst geht nicht aus bzw. rebootet nicht.


1. habe ich teilweise lösen können, indem ich vor dem Suspend die Systemd-Units "NetworkManager.service" und "networking.service" stoppe und nach dem Resume wieder starte. Das GUI friert nun nicht mehr ein und die WLAN-Verbindung wird zügig wiederhergestellt. Allerdings kommt die LAN-Verbindung erst nach mehreren (5?) Minuten wieder:

Code: Alles auswählen

Okt 06 18:37:02 amilo NetworkManager[554]: <warn>  [1633538222.2450] dhcp4 (enp7s8): request timed out
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2451] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2454] device (enp7s8): state change: ip-config -> failed (reason 'ip-config->
Okt 06 18:37:02 amilo NetworkManager[554]: <warn>  [1633538222.2503] device (enp7s8): Activation: failed for connection 'Kabelgebundene Ver>
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2510] device (enp7s8): state change: failed -> disconnected (reason 'none', >
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2660] dhcp4 (enp7s8): canceled DHCP transaction
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2674] dhcp4 (enp7s8): state changed timeout -> done
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2784] manager: startup complete
[..]
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2450] policy: auto-activating connection 'Kabelgebundene Verbindung 1' (8cb9>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2466] device (enp7s8): Activation: starting connection 'Kabelgebundene Verbi>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2469] device (enp7s8): state change: disconnected -> prepare (reason 'none',>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2482] device (enp7s8): state change: prepare -> config (reason 'none', sys-i>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2517] device (enp7s8): state change: config -> ip-config (reason 'none', sys>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2556] dhcp4 (enp7s8): activation: beginning transaction (timeout in 45 secon>
Okt 06 18:42:02 amilo NetworkManager[554]: <info>  [1633538522.2714] dhcp4 (enp7s8): state changed unknown -> bound, address=192.168.1.8
Okt 06 18:42:02 amilo avahi-daemon[551]: Joining mDNS multicast group on interface enp7s8.IPv4 with address 192.168.1.8.
Okt 06 18:42:02 amilo avahi-daemon[551]: New relevant interface enp7s8.IPv4 for mDNS.
Okt 06 18:42:02 amilo avahi-daemon[551]: Registering new address record for 192.168.1.8 on enp7s8.IPv4.
Ein zusätzliches Entladen/Laden des Kernel-Moduls (e100) brachte keine Besserung.

Zu 2. stehe ich völlig auf dem Schlauch, denn ich weiß hier nicht mal wo ich ansetzen soll. Ich sehe vor dem Ende des missglückten Reboots noch diese Meldungen, die dann (auch deutlich länger als 10min) auf dem Schirm stehen bleiben:

Code: Alles auswählen

Okt 06 18:32:19 amilo systemd[1]: Reached target Reboot.
Okt 06 18:32:19 amilo systemd[1]: Shutting down.
Okt 06 18:32:19 amilo systemd[1]: Using hardware watchdog 'iTCO_wdt', version 0, device /dev/watchdog
Okt 06 18:32:19 amilo systemd[1]: Set hardware watchdog to 10min.
Okt 06 18:32:19 amilo kernel: watchdog: watchdog0: watchdog did not stop!
Okt 06 18:32:19 amilo systemd-shutdown[1]: Syncing filesystems and block devices.
Okt 06 18:32:19 amilo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Okt 06 18:32:19 amilo systemd-journald[213]: Journal stopped
Zeile 5 "watchdog did not stop!" erscheint in rot. Das brachte mich auf die Idee, danach zu suchen, führte mich zu [1], aber der dort gebrachte Tipp, dem Kernel die Option "reboot=bios" bzw. "reboot=acpi" mitzugeben brachte keine Änderung. Soweit ich das verstehe, wäre das aber ohnehin nur ein Workaround. Die wahre Lösung wäre vermutlich auch hier, eine oder mehrere problematische Systemd-Units zu identifizieren. Nur wie?


[1] https://unix.stackexchange.com/question ... d-not-stop

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von KP97 » 06.10.2021 20:29:40

Vielleicht hilft Dir das weiter:
https://access.redhat.com/solutions/5118401

In /etc/systemd/system.conf kann man auch noch was zu watchdog einstellen.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 06.10.2021 20:55:41

KP97 hat geschrieben: ↑ zum Beitrag ↑
06.10.2021 20:29:40
Vielleicht hilft Dir das weiter:
https://access.redhat.com/solutions/5118401
Nein, leider nicht. Die Symptome bleiben mit und ohne "mem_sleep_default=deep" identisch.
KP97 hat geschrieben: ↑ zum Beitrag ↑
06.10.2021 20:29:40
In /etc/systemd/system.conf kann man auch noch was zu watchdog einstellen.

Code: Alles auswählen

# grep -i watchdog /etc/systemd/system.conf 
#RuntimeWatchdogSec=0
#RebootWatchdogSec=10min
#ShutdownWatchdogSec=10min
#KExecWatchdogSec=0
#WatchdogDevice=
Da auch nach Ablauf der 10 Minuten nichts psasiert vermute ich, dass mich der Watchdog nicht weiter bringt.

Übrigens habe ich festgestellt, dass selbst wenn die LAN/WLAN-Verbindung wieder eine IP bekommen hat (dhcp), nicht immer auch eine erfolgreiche Verbindung (Ping) gegeben ist, egal in welche Richtung.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von eggy » 07.10.2021 03:15:47

hikaru hat geschrieben: ↑ zum Beitrag ↑
06.10.2021 19:08:42
Okt 06 18:37:02 amilo NetworkManager[554]: <info> [1633538222.2454] device (enp7s8): state change: ip-config -> failed (reason 'ip-config->
[/code]
Schau mal was da sonst noch steht, vielleicht versteckt sich im Abgeschnittenen doch noch ein brauchbarer Hinweis

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 10:12:57

Danke! Das hatte ich übersehen:

Code: Alles auswählen

Okt 06 18:37:02 amilo NetworkManager[554]: <warn>  [1633538222.2450] dhcp4 (enp7s8): request timed out
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2451] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2454] device (enp7s8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Okt 06 18:37:02 amilo NetworkManager[554]: <warn>  [1633538222.2503] device (enp7s8): Activation: failed for connection 'Kabelgebundene Verbindung 1'
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2510] device (enp7s8): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2660] dhcp4 (enp7s8): canceled DHCP transaction
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2674] dhcp4 (enp7s8): state changed timeout -> done
Okt 06 18:37:02 amilo NetworkManager[554]: <info>  [1633538222.2784] manager: startup complete
Ich vermute, das sollte mir Auskunft darüber geben, was das Problem ist:

Code: Alles auswählen

ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Leider kann ich es nicht deuten.

Unter [1] habe ich gelesen, dass es vielleicht irgendwas mit dhcp zu tun haben könnte. Wenn ich nach entsprechenden Paketen suche bekomme ich das:

Code: Alles auswählen

# dpkg -l | grep dhcp
ii  isc-dhcp-client                       4.4.1-2.3                       amd64        DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common                       4.4.1-2.3                       amd64        common manpages relevant to all of the isc-dhcp packages
Parallel habe ich eine Buster-Installation, die das gleiche Ergebnis liefert und jahrelang keine Probleme hatte:

Code: Alles auswählen

# dpkg -l | grep dhcp
ii  isc-dhcp-client                       4.4.1-2                             amd64        DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common                       4.4.1-2                             amd64        common manpages relevant to all of the isc-dhcp packages
Beides sind Minimalinstallationen.
Beim direkten Vergleich der Paketlisten beider Systeme bekam ich diese Liste möglichwerweise netzwerkrelevanter Pakete, die auf dem Buster-System installiert ist, es unter Bullseye aber nicht war:

Code: Alles auswählen

acpid acpi-support dbus-user-session dnsutils iptables net-tools
Ich habe die Pakete unter Bullseye nachinstalliert, sehe jedoch keine Besserung.
In der aktuellen Session bekam ich nicht mal direkt nach dem Booten (ohne Suspend) eine LAN-Verbindung:

Code: Alles auswählen

Okt 07 09:55:25 amilo NetworkManager[561]: <warn>  [1633593325.3028] dhcp4 (enp7s8): request timed out
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3029] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3031] device (enp7s8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Okt 07 09:55:25 amilo NetworkManager[561]: <warn>  [1633593325.3076] device (enp7s8): Activation: failed for connection 'Kabelgebundene Verbindung 1'
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3122] device (enp7s8): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3220] dhcp4 (enp7s8): canceled DHCP transaction
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3221] dhcp4 (enp7s8): state changed timeout -> done
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3332] policy: auto-activating connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3361] device (enp7s8): Activation: starting connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3365] device (enp7s8): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3377] device (enp7s8): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3470] device (enp7s8): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:55:25 amilo NetworkManager[561]: <info>  [1633593325.3494] dhcp4 (enp7s8): activation: beginning transaction (timeout in 45 seconds)
Okt 07 09:55:25 amilo wpa_supplicant[567]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-26 noise=9999 txrate=1000
Okt 07 09:55:38 amilo systemd[1]: NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Okt 07 09:55:38 amilo systemd[1]: NetworkManager-wait-online.service: Failed with result 'exit-code'.
Okt 07 09:55:38 amilo systemd[1]: Failed to start Network Manager Wait Online.
[..]
Okt 07 09:56:10 amilo NetworkManager[561]: <warn>  [1633593370.3009] dhcp4 (enp7s8): request timed out
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3010] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3013] device (enp7s8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Okt 07 09:56:10 amilo NetworkManager[561]: <warn>  [1633593370.3057] device (enp7s8): Activation: failed for connection 'Kabelgebundene Verbindung 1'
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3073] device (enp7s8): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3421] dhcp4 (enp7s8): canceled DHCP transaction
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3422] dhcp4 (enp7s8): state changed timeout -> done
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3480] policy: auto-activating connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3513] device (enp7s8): Activation: starting connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3526] device (enp7s8): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3554] device (enp7s8): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3579] device (enp7s8): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:10 amilo NetworkManager[561]: <info>  [1633593370.3597] dhcp4 (enp7s8): activation: beginning transaction (timeout in 45 seconds)
Okt 07 09:56:55 amilo NetworkManager[561]: <warn>  [1633593415.3020] dhcp4 (enp7s8): request timed out
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3022] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3023] device (enp7s8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Okt 07 09:56:55 amilo NetworkManager[561]: <warn>  [1633593415.3073] device (enp7s8): Activation: failed for connection 'Kabelgebundene Verbindung 1'
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3095] device (enp7s8): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3261] dhcp4 (enp7s8): canceled DHCP transaction
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3262] dhcp4 (enp7s8): state changed timeout -> done
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3343] policy: auto-activating connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3359] device (enp7s8): Activation: starting connection 'Kabelgebundene Verbindung 1' (8cb99e2c-558a-35b2-81d5-c8334abf5623)
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3362] device (enp7s8): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3395] device (enp7s8): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3425] device (enp7s8): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Okt 07 09:56:55 amilo NetworkManager[561]: <info>  [1633593415.3440] dhcp4 (enp7s8): activation: beginning transaction (timeout in 45 seconds)
[..]
Okt 07 09:57:29 amilo wpa_supplicant[567]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Okt 07 09:57:40 amilo NetworkManager[561]: <warn>  [1633593460.3008] dhcp4 (enp7s8): request timed out
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3009] dhcp4 (enp7s8): state changed unknown -> timeout
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3010] device (enp7s8): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Okt 07 09:57:40 amilo NetworkManager[561]: <warn>  [1633593460.3060] device (enp7s8): Activation: failed for connection 'Kabelgebundene Verbindung 1'
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3081] device (enp7s8): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3221] dhcp4 (enp7s8): canceled DHCP transaction
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3222] dhcp4 (enp7s8): state changed timeout -> done
Okt 07 09:57:40 amilo NetworkManager[561]: <info>  [1633593460.3284] manager: startup complete
Die WLAN-Verbindung funktioniert aktuell.

In's Auge springen mir diese Meldungen (weiß, gelb, rot):

Code: Alles auswählen

Okt 07 09:55:38 amilo systemd[1]: NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Okt 07 09:55:38 amilo systemd[1]: NetworkManager-wait-online.service: Failed with result 'exit-code'.
Okt 07 09:55:38 amilo systemd[1]: Failed to start Network Manager Wait Online.
Kann man dazu Näheres erfahren?


[1] https://www.linuxquestions.org/question ... ost5064266

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 14:22:20

Wenn ich den LAN-Controller im BIOS deaktiviere, scheinen alle Probleme zu verschwinden.

Dass die Schnittstelle an sich funktioniert weiß ich von Etch bis Buster. Also muss irgendetwas in Bullseye kaputtgegangen sein. Weiß dazu jemand etwas?:

Code: Alles auswählen

07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)
	Subsystem: Fujitsu Technology Solutions PRO/100 VE Network Connection
	Flags: bus master, medium devsel, latency 64, IRQ 20
	Memory at dc000000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at 5000 [size=64]
	Capabilities: [dc] Power Management version 2
	Kernel driver in use: e100
	Kernel modules: e100

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von eggy » 07.10.2021 14:35:43

Was passiert, wenn erstmal das Device auf unmanaged einstellst? Sollte irgendwie in der Gui/Cli vom nm gehen.
Sonst schau mal, obs nen Eintrag für das Device in der /etc/networking/interfaces gibt, den entsprechend wegkommentieren bzw. einfügen falls es ihn nicht gibt.

Ich denke, da prügeln sich drei Automatiken gleichzeitig um "nee, ich hab grad keinen Bock, der andere macht doch schon": die normalen /etc/networking Sachen, systemd-network und der nm ... man könnt noch wicd dazu Installieren um das Chaos vollständig zu perfektionieren :mrgreen:

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 14:59:12

Ich hatte zwischenzeitlich schon mal Debiannetwork-manager und Debiannetwork-manager-gnome deinstalliert, aber das brachte keine Änderung. Auch hatte ich enp7s8 in /etc/network/interfaces eingetragen, woraufhin ja der Netwok-Manager die Schnittstelle ignoriert. Auch das brachte nichts.
(Debianwicd gibt's übrigens nicht mehr. Stattdessen könnte man wohl Debianconnman als Alternative zum Network-Manager nutzen. Erfahrung hab ich damit bisher aber nicht.)

Inzwischen habe ich unter Buster den Backports-Kernel ausprobiert, der ja mit dem Bullseye-Kernel identisch sein sollte. Und siehe da, nun habe ich die selben Probleme wie unter Bullseye.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von eggy » 07.10.2021 15:15:19

Doch mal nen Bugreport aufmachen? bzw nochmal schauen, ob schon was entsprechendes bekannt ist?
Wenn es ne Regression ist, betriffts ja selten nur ein Gerät.
Falls Du extrem viel Zeit und Langeweile hast, könntest Du versuchen rauszufinden, ab wann genau das Problem auftaucht ... aber das wird sicher sehr zeitaufwendig.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 15:30:41

Darauf wird's wohl hinauslaufen. Scharf darauf bin ich allerdings nicht. Ich hatte in letzter Zeit öfter schon mal sowas gelesen wie "X funktioniert mit Kernel 5 nicht mehr. Ich bin wieder zurück zu 4.", aber mich nie näher damit beschäftigt.
Die Buster-Backports-Kernel aus den Snapshots durchzuprobieren wäre recht einfach, aber echtes Bisecting? Und so ganz ohne Kernel-Kenntnisse ... :x

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von Tintom » 07.10.2021 15:56:59

Was mich wundert ist das Kernelmodul e100. Wurde das nicht schon vor langem ersetzt durch e1000?

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von KP97 » 07.10.2021 16:51:35

Sehr seltsam...das habe ich doch richtig verstanden, daß das Wlan läuft nur nicht das Lan?
Dann könntest Du doch mal testen, das Lan durch systemd zu steuern. Aus dem NM-Gnome das Lan herausnehmen, hat @eggy aber schon gesagt.
Es gibt für Wlan auch noch den Netzwerkmanager Debianiwd von Intel. Lehnt sich an connman an, ist aber einfacher. Eine grafische Oberfläche kann man sich von github selbst kompilieren, ist ohne Aufwand machbar. (1) Iwd braucht auch keinen wpasupplicant, sehr übersichtlich.
Habe ich hier auf meinem Desktop mit Sid laufen. Wenn ich Wlan ausschalten will, brauche ich nur den Service zu stoppen bzw. disablen. Auf einem Laptop soll Wlan natürlich immer da sein,
da braucht es das nicht.

Für systemd-networkd legst Du eine Datei in /etc/systemd/network an.
Meine z.B. heißt 60-kabel.network mit diesem Inhalt

Code: Alles auswählen

[Match]
Name=e*

[Network]
DHCP=yes 
Damit vergibt systemd eine IP-Adresse zum richtigen Zeitpunkt beim Start und nichts funkt dazwischen.
Die Services systemd-networkd und systemd-resolved müssen laufen. Der Service networkmanager-wait-online.service wird nicht benötigt und kann disabled werden.
Die Pakete zu dhcp können entfernt werden, das macht systemd intern.
Abfragen kannst Du dann mit
systemctl status systemd-networkd
und
networkctl status

Dann Services überprüfen und nach einem Neustart sollte das Lan laufen.
(1) https://github.com/J-Lentz/iwgtk

Wenn man den Namen nach z.B. eth0 ändern will, kann man eine zusätzliche Datei namens 60-kabel.link anlegen mit diesem Inhalt:

Code: Alles auswählen

[Link]
Name=eth0

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 17:03:09

Tintom hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 15:56:59
Was mich wundert ist das Kernelmodul e100. Wurde das nicht schon vor langem ersetzt durch e1000?
Keine Ahnung. e100 zu blacklisten führt jedenfalls nicht dazu, dass e1000 geladen wird. Und selbst wenn man das erzwingt funktioniert damit nicht der Adapter. Ohne e100 gibt's gar kein LAN.
Ich hatte auch mal ausgiebig Datenblätter gewälzt. Der Chip kann wirklich nur 100MBit/s, auch wenn seinerzeit Gbit-Chips in Notebooks schon eine gewisse Verbreitung hatten.

KP97 hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 16:51:35
Sehr seltsam...das habe ich doch richtig verstanden, daß das Wlan läuft nur nicht das Lan?
Vor dem Suspend läuft beides. Danach laufen beide bestenfalls unzuverlässig. Ich vermute, der Kernel macht beim Suspend irgendwas Komisches mit e100 und danach verschluckt sich der ganze Netzwerk-Stack.
KP97 hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 16:51:35
Dann könntest Du doch mal testen, das Lan durch systemd zu steuern. Aus dem NM-Gnome das Lan herausnehmen, hat @eggy aber schon gesagt.
Schon passiert, siehe oben!
Dass der NM nach dem Suspend verrückt spielt mag ein gesondert zu betrachtendes Problem sein, ist aber hier nicht die eigentliche Ursache.

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von KP97 » 07.10.2021 17:07:48

Läuft denn das Lan über systemd, so wie von mir beschrieben, also getrennt vom Netzwerkmanager?

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von Tintom » 07.10.2021 19:55:36

hikaru hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 17:03:09
Tintom hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 15:56:59
Was mich wundert ist das Kernelmodul e100. Wurde das nicht schon vor langem ersetzt durch e1000?
Keine Ahnung. e100 zu blacklisten führt jedenfalls nicht dazu, dass e1000 geladen wird. Und selbst wenn man das erzwingt funktioniert damit nicht der Adapter. Ohne e100 gibt's gar kein LAN.
Ich hatte auch mal ausgiebig Datenblätter gewälzt. Der Chip kann wirklich nur 100MBit/s, auch wenn seinerzeit Gbit-Chips in Notebooks schon eine gewisse Verbreitung hatten.
Ich nehme das zurück. Ich meinte damals irgendwo gelesen zu haben, dass e1000 die Funktionen von e100 übernimmt und e100 damit obsolet geworden ist. Aber eine Suche danach bringt nichts eindeutiges zu Tage und im Kernel-git scheint beim Modul e100 noch ordentlich Aktivität zu sein.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 07.10.2021 20:12:19

KP97 hat geschrieben: ↑ zum Beitrag ↑
07.10.2021 17:07:48
Läuft denn das Lan über systemd, so wie von mir beschrieben, also getrennt vom Netzwerkmanager?
Zumindest testweise ja - ohne Besserung.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von Tintom » 08.10.2021 06:51:35

Ich werde den Verdacht nicht los, dass der Kernel nicht ganz unschuldig an der Situation ist. Hattest du mal andere Kernelversionen ausprobiert? Mit Kernel 5.9 wurde etwas am Suspend-/Resume-Verhalten des Moduls geändert. In der Commit-Message steht zudem:

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 08.10.2021 11:12:50

Danke! Ich glaube das ist die Ursache.
Ich wusste nicht wo ich ansetzen soll, deshalb wollte ich am Wochenende mal alle Buster-Backports-Kernel durchprobieren - von 5.2 bis 5.9. Mit diesem konkreten Hinweis ließ sich das beschleunigen. Unter 5.8 ist augenscheinlich noch alles in Ordnung, unter 5.9 gibt es aber die beschriebenen Probleme.
Dann kann ich mich direkt an einen Bugreport machen (Edit: Debian Bugreport995927).

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bullseye, Notebook: Probleme mit Network-manager, poweroff/reboot nach suspend2RAM

Beitrag von hikaru » 08.10.2021 16:29:11

Als Workaround scheint es zu funktionieren, e100 vor dem Suspend zu entladen und hinterher wieder zu laden (nach Vorbild aus [1]):

Code: Alles auswählen

root@amilo:~# cat /etc/systemd/system/mysyssuspend.service
[Unit]
Before=suspend.target
[Service]
Type=simple
StandardOutput=syslog
ExecStart=modprobe -r e100
[Install]
WantedBy=suspend.target

Code: Alles auswählen

root@amilo:~# cat /etc/systemd/system/mysysresume.service
[Unit]
After=suspend.target
[Service]
Type=simple
StandardOutput=syslog
ExecStart=sh -c "modprobe e100 && dhclient enp7s8"
[Install]
WantedBy=suspend.target
Voraussetzung ist, dass das LAN nicht über den Networkmanager verwaltet wird:

Code: Alles auswählen

# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug enp7s8
iface enp7s8 inet dhcp

[1] https://itectec.com/unixlinux/ubuntu-st ... er-resume/

Antworten