[GELÖST] Kein kompletter Shutdown nach dem Upgrade auf Buster

[salero]

Nach dem Upgrade auf Debian Buster schaltet sich mein Laptop Lenovo Legion Y520 nicht mehr vollständig aus und es dauert ewig bis er zur Marke kommt

Shutdown target reached. (schaltet sich aber nicht aus)

Ich vermute, es liegt am Kernel. Das Problem existiert nur wenn ich den 4.19.0-5-amd64 verwende, mit dem alten Kernel (ich glaube es war der 4.09.irgendwas) gibt es keinerlei Probleme. Auch jetzt nach dem Upgrade nicht.
Ist das Problem bekannt? Ich habe im Internet schon gesucht, aber eigentlich nichts dazu gefunden.

http://nopaste.debianforum.de/40808

http://nopaste.debianforum.de/40809

und da ich nicht weiß, wo der Shutdown geloggt wir hier ein Foto:

gallery/image/2221

[salero]

So, ein paar Logausgaben nachgereicht.

[msrx111]

Auf dem Bild sieht man, dass er Probleme hat die Festplatten auszuhängen..... Vermutlich stimmt die /etc/fstab nicht.

[salero]

OK, Im Log steht, dass er SWAP nicht deaktivieren kann:

in der fstab steht zu diesem Laufwerk

Code: Alles auswählen

UUID=32b31b18-dd8b-4fa6-9275-b90e765622ff none            swap    sw              0       0

was mit dem Kernel 4.9.0.9 noch funktioniert.

Seht ihr einen Fehler?

[willy4711]

Vielleicht mal so:

Code: Alles auswählen

UUID=4e9bde7e-3bae-41c7-bb65-6e5f11135644 swap           swap    defaults,noatime 0 0

Ist aber wohl nicht das Problem. Soweit ich das entziffern konnte betrifft es ja alle Platten.
Vorher kommt immer die Meldung, mit der ich nichts anfangen kann:

Code: Alles auswählen

watchdog: BUG: soft lockup - CPU#24 stuck for 23s! [systemd-udevd:7322]

Ich glaube nicht, dass es was mit der fstab zu tun hat. Dann sollte auch beim hochfahren Fehlermeldungen kommen.

Das Journal von systemd ist eventuell gesprächiger.
Dazu musst du es persistent machen mit

Code: Alles auswählen

mkdir /var/log/journal

beim nächsten start kannst du dan das Journal der vorherigen Sitzung mit

Code: Alles auswählen

journalctl -b -1

aufrufen und den Schluss mal hier posten

Um Fehler auszuschließen:

Wie genau hast du das Upgrade gemacht ? (apt full-upgrade ??)
Hast du den alten Kernel gepurgt ?
Sind die Meldungen aus dem Syslog vom Hochfahren ?
Bekommst du überhaupt einen grafische Oberflächen ? Sieht ja fast nicht so aus.

[salero]

So, ich habe das Verzeichnis angelegt und das Log sieht wie folgt aus:

http://nopaste.debianforum.de/40810

Wie genau hast du das Upgrade gemacht ? (apt full-upgrade ??)

Ja, ich habe ein full-upgrade gemacht

Hast du den alten Kernel gepurgt ?

Nein, zum Glück war der alte Kernel noch da. Sonst hätte ich gar nichts mehr so leicht ändern können. S.u.

Sind die Meldungen aus dem Syslog vom Hochfahren ?

Nein, die Angaben müssten ebenfalls vom Runterfahren stammen. Um die Zeit bin ich schon im Bett. Wie man im journalctl-Log sieht braucht er ja bis 7 Uhr morgens, bis er sich dann in den suspense mode legt.

Bekommst du überhaupt einen grafische Oberflächen ? Sieht ja fast nicht so aus.

Ja, Aber nach dem ersten Hochfahren nach dem Upgrade mit dem neuen Kernel hatte ich in der Tat keine graphische Oberfläche. Der Kernel schien zu diesem Zeitpunkt auch kein Netzwerk zu haben. Ich habe dann mit dem alten Kernel das System neu gestartet und hatte wieder Verbindung zum Netzwerk. Ich habe den KDE reinstalliert und seit dem habe ich wieder eine graphische Oberfläche -- auch mit dem neuen Kernel, ebenso Netz.

[willy4711]

Uff was für ein Kauderwelsch
Was noch wichtig wäre, das du uns deine Hardware mitteilst. Installiere doch mal inxi
und stelle hier die Ausgabe von

Code: Alles auswählen

inxi -F

ein.
Mit dem Journal bin ich ehrlich gesagt überfragt.
ich kann die auf die Zeile

Code: Alles auswählen

Aug 05 01:43:10 RECHNER kernel: watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-udevd:14722]

folgenden Meldungen auch nicht deuten, die sich ja dann bis Zeile 6339 wiederholen .

Man könnte ja mal mit einer Live -CD testen, ob sich das Problem dort auch zeigt.
Aktuelle Live CD's:
http://cdimage.debian.org/debian-cd/cur ... so-hybrid/
Bei deinem Rechner würde ich die "unfreien" Versionen bevorzugen:
http://cdimage.debian.org/cdimage/unoff ... so-hybrid/

[salero]

Uff was für ein Kauderwelsch
...
Mit dem Journal bin ich ehrlich gesagt überfragt.

Du wolltest die ungeschminkte Log-Wahrheit haben. Scherz beiseite. Es gibt so einiges was ich an dem Log nicht verstehe.

Aber das was mich im Moment am meisten interessiert ist, warum gibt es einen reboot? Ich hab dem System doch über die Oberfläche gesagt es soll runterfahren. Den reboot habe ich zumindest nicht wissentlich veranlasst.

Code: Alles auswählen

-- Reboot --
Aug 05 07:55:48 RECHNER kernel: microcode: microcode updated early to revision 0xb4, date = 2019-04-01

Nachtrag:
Ok, könnte ich doch gewesen sein. Die Zeit hat mich verwirrt. Aber wahrscheinlich ist sie zu dem Zeitpunkt noch nicht gesynct.

Was noch wichtig wäre, das du uns deine Hardware mitteilst.

Mach ich noch.

[salero]

Ok, hier zunächst nochmal meine Hardwareausstattung:
http://nopaste.debianforum.de/40812

Ich habe in den letzten Tagen mal versucht einige Probleme, die ich im Log gesehen habe, zu eleminieren. Einiges konnte tatsächlich lösen. Dabei stieß ich auch auf die Seite
https://www.dedoimedo.com/computers/ubu ... -boot.html

wo ähnliche Dinge drinstehen, wie ich sie auch bei mir habe. Hat zwar nichts geholfen, weil ich meine UUID rauf und runter überprüft habe, da scheint alles in Ordnung zu sein. (Außer der Tatsache, dass in alten Threads steht, dass SWAP-Partitionen keine UUID haben sollten. Aber ich glaube, das ist mittlerweile überholt, wenn es je gestimmt hat.)

Nichtsdestotrotz mag ich den Ansatz aus der Seite, systematisch vorgehen. Und wären folgende Dinge zu klären:

1. Warum braucht mein System ewig beim Shutdown, die Platten auszuhängen (aber beim Booten gibt es keine Probleme)?
2. Warum braucht mein System ewig beim Shutdown den Netzwerk-Manager zu deaktivieren?
3. Auf welche Dienste werden gewartet?

Nun, ich bin noch nicht sehr vertraut mit dem systemd-Kram. Wie kommt man bei den Fragen weiter? Kann man systemd-analyze blame und systemd-analyze critical-chain auf den Shutdown eingrenzen?

Aktuell sind es folgende beim Shutdown.

#journalctl -b -1|grep -i 'failed with'
Aug 07 19:45:37 RECHNER systemd[1]: sddm.service: Failed with result 'timeout'.
Aug 07 19:50:58 RECHNER systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Aug 07 19:50:58 RECHNER systemd[1]: NetworkManager.service: Failed with result 'timeout'.
Aug 07 19:54:59 RECHNER systemd[1]: Failed deactivating swap /dev/disk/by-uuid/32b31b18-dd8b-4fa6-9275-b90e765622ff.
Aug 07 19:56:19 RECHNER systemd[1]: systemd-timesyncd.service: Failed with result 'timeout'.

[salero]

Ok, der vollständigkeithalber :

Vorgestern gab es eine Aktualisierung einiger Libs, z.B. libkf5, und seit dem hat sich mein System wieder erholt und führt den Shutdown wieder normal durch.
Es gibt noch ein paar kleinere Fehler im Log, die auch schon vorher da waren, aber das braucht nicht in diesem Thread behandelt zu werden.

danke an alle soweit.