Hallo
Es tut mir sehr leid, aber ich muss passen.... ich kann Dir leider bei Deinem Problem nicht helfen. Ich kenne den Fehler, ich kann ihn auf meinen Laptop's beliebig reproduzieren, ich kann ihn natürlich auch jederzeit beseitigen, ich kenne den Verursacher und die Maßnahmen dagegen. Nur ist das leider etwas, was nicht mit ein paar Klicks irgendwo eingestellt werden kann, sondern ein wenig Erfahrung mit dem CLI bedarf.
Fakt ist: Der Networkmanager ist der Verursacher, weil er definitiv die WLAN-Hardware abschaltet, ohne vorher die Netzwerkverbindungen zu lösen. Meines Erachtens trifft das zu, was ich vorher schon vermutet habe, der NM hat noch nicht absschliessend die Veränderungen mit Systemd verinnerlicht. Deaktiviere ich zuerst den NM und trage dann die Netwerkverbindungen in die /etc/network/interfaces ein, kann ich präzise an Hand des Journals feststellen, dass Systemd sich absolut sauber an die umgekehrte Boot-Reihenfolge der Unit-Direktiven hält und die Wifi-Verbindung erst dann abschaltet, nachdem alle Prozesse ordentlich aufgeräumt haben.... mit dem Ergebnis, dass der Shutdown ohne Fehlermeldungen flüssig durchläuft. Es ist eindeutig feststellbar, dass der umount bei beiden Rechnern etwa 5-6 Sekunden nach dem
"systemctl poweroff" durchgeführt wird und weitere zig Sekunden danach erst Wifi von systemd abgeschaltet wird. Die 5-6 Sekunden nach Poweroff ist die Regel auf beiden Maschinen! Der NM hingegen schaltet schon vor Ablauf der 1. Sekunde nach "Poweroff" das Wifi aus... danach hat kein Prozess mehr die Chance das "Netzwerk" aufgeräumt zu verlassen... die mounts hängen in den 120-Sekunden-Stopjobs. Das ist durch nichts zu verhindern. Kriegt der NM ein Signal, Kill oder Term oder wasauchimmer, knallt er das Wifi auf beiden Rechnern sofort weg.
Die Bootphase habe ich über eine eigene Unit "
network_wait_online" geregelt, die absolut zuverlässig darauf wartet, dass der Rechner auch wirklich mit dem Netz verbunden ist, also das er eine gültige IP hat. Interessant wäre jetzt das Ergebnis, wie sich
"x-systemd.requires=network_wait_online" in der fstab auswirkt, da "requires" als
requires und after interpretiert wird. Das sollte eigentlich gut funktionieren und dürfte keinen negativen Einfluss auf den Bootvorgang haben.... bis nach Ablauf des Timeouts im Hintergrund die Bemühungen zu mounten eingestellt werden, wenn das Netzwerk nicht verfügbar ist.Davon sollte man aber nix mitkriegen, allenfalls das Journal. Aber um auch das wiederum eindeutig zu gestalten und selber die Kontrolle zu haben, habe ich das ebenfalls über eine eigene Unit
mountctrl geregelt, die eben mit genau diesen wechselnden Situationen klar kommt, wenn mal
das Netz da, mal
ein Netz da ist, mal der Server da ist, und mal gar nix da ist.
Und um den Kreislauf Boot und Shutdown mit einer weiteren Komponente zu vervollständigen und weil ich natürlich nicht auf den grundsätzlichen Komfort eines NM verzichten möchte, nutze ich dafür einen eigenen rudimentären Script-NM, mit dem ich wechselnde (vor-konfigurierte) Netze komfortabel verbinden und lösen kann.
Das Problem ist jetzt, dass ich bei der Ursachensuche wegen der Probleme beim Shutdown auf einmal über diesen Fehler gestolpert bin:
Code: Alles auswählen
Jan 09 14:53:58 Dell-Laptop colord[878]: (colord:878): Cd-WARNING **: failed to get session [pid 816]: Unbekannter Fehler -2
Jan 09 14:54:10 Dell-Laptop colord[878]: # ERROR: snmp_send failed, Network is unreachable
Jan 09 14:54:10 Dell-Laptop colord[878]: # ERROR: snmp_send failed, Network is unreachable
Erwähnenswert ist, dass das Netz gestartet ist und das ich colord sogar "after network_wait_online" konfiguriert habe.... interessiert ihn aber nicht. Möglicherweise guckt er nur auf den Zustand des NM, der aber jetzt im Moment nicht lebt. Ich habe keine Ahnung, ob ich diesen Fehler jetzt verursacht habe, ob es da überhaupt einen Zuammenhang gibt, was das bedeutet, wofür colord überhaupt verwendet wird und ob der vielleicht schon immer besteht. Dummerweise habe ich wegen der Fehersuche auch erst heute das Journal aktiviert... also kann ich nicht nachsehen, obs den früher schon gab. Und da Du die KDE verwendest, die ebenfalls den Networkmanager beinhaltet, möchte ich jetzt lieber keinen Rat geben, wenn die Gefahr besteht, dass danach andere Fehler bestehen, bzw., das danach vielleicht gar nix mehr geht.
Das einfachste wäre jetzt (was auch auf jeden Fall funkioniert), ein Shutdown-Desktop-Icon, welches auf ein kleines Script verweist, mit dem zuerst "umount'ed" wird und dann erst "poweroff" ausgeführt wird. In Verbindung mit noauto in der fstab wären damit also die Probleme gelöst, ohne sich in Gefahr zu begeben, was kaputt zu machen.