• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

OpenSuse Leap 42.1: Aufhängen beim Runterfahren - immer !

OP
L

lin

Hacker
hallo - das ist komplett durchgelaufen. So gesehen sind wir hier jetzt weiter.

Allerdings sind die Ergebnisse des Shutdown-Befehls immer noch die gleichen. Der Rechner bleibt hängen - immer noch.

Kann es denn ggf. mit dem/n Plasmoiden zusammen hängen. Hab gehoert dass es hier noch Fehler / Bugs geben sollte.
Hab da ggf. auch etwas schlecht konfiguriert. Meld mich abends wieder....

LG Lin
 

Sauerland

Ultimate Guru
Eventuell die file-permissions:
https://forums.opensuse.org/showthread.php/511702-Leap-user-can-t-reboot-shutdown-with-permissions-set-to-quot-secure-quot?highlight=shutdown+leap
 

josef-wien

Ultimate Guru
Sauerland schrieb:
Eventuell die file-permissions
Das paßt mir nicht zur Fehlerbeschreibung.

Der Log-Auszug in Deinem ersten Beitrag umfaßt einen ziemlich großen Zeitraum, und ich sehe dort nichts im Zusammenhang mit dem Herunterfahren. Vor allem
lin schrieb:
aber das friert dann regelrecht ein - von hier aus geht dann gar nichts mehr. Null, nix!

weiters: Wenn ich das Notebook dann zuklappe - dann läuft alles weiter
schaut ja so aus, als ob der Befehl zum Herunterfahren (fast) ignoriert wird. Kann man systemd dazu bringen, mehr zu protokollieren?

Was passiert, wenn Du Dich abmeldest, dann zur Textkonsole wechselst und dort nach Anmeldung den Ausschalt-Befehl eingibst?
 
Diesem Link mal folgen und umsetzen auch wenn er für centOS geschrieben ist, funktioniert das bei suse genauso. Danach kann man per journal auch die Meldungen von vorherigen boots sehen.
 
OP
L

lin

Hacker
hallo Josef-Wien, hallo Geier0815,

habe den Stack-Artikel mal durchgelesen - die Befehle ausgefuehrt u. dann nochmals logfiles abgerufen;



hier hab ich diese dann reingestellt..; http://pastebin.com/B1HEMcWE

ist etwas viel - zu viel um es hier reinzustellen...

vg lin
 
OP
L

lin

Hacker
hi

sorry - ich lass ihn nochmals zu einem kontrollierten u. ausgewählten Zeitpunt runterfahren.
Mach ich u- poste das nochmals. VG (komm bis do aber nicht dazu. Hab den Rechner nicht bei mir. Meld mich aber dann)
VG
 
OP
L

lin

Hacker
hallo @ all

habe das hier beschriebene alles gemacht -

http://unix.stackexchange.com/questions/159221/how-display-log-messages-from-previous-boots-under-centos-7

Der Rechner wurde um exakt 15.30 heruntergefahren,,,

Code:
martin@linux-o61y:~> journalctl --boot=-1
-- Logs begin at Do 2015-02-12 01:34:42 CET, end at So 2016-01-31 15:33:44 CET. --
Jan 31 15:25:17 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11700): Communication problem with  "kwalletd" , it probably
Jan 31 15:25:18 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:25:18 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11704): Communication problem with  "kwalletd" , it probably
Jan 31 15:25:18 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:25:21 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11707): Communication problem with  "kwalletd" , it probably
Jan 31 15:25:21 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:25:21 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11710): Communication problem with  "kwalletd" , it probably
Jan 31 15:25:21 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:27:39 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11755): Communication problem with  "kwalletd" , it probably
Jan 31 15:27:39 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:27:39 linux-o61y.site org.kde.kwalletd[1697]: kwalletd(11758): Communication problem with  "kwalletd" , it probably
Jan 31 15:27:39 linux-o61y.site org.kde.kwalletd[1697]: Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message
Jan 31 15:31:05 linux-o61y.site systemd[1617]: pam_unix(systemd-user:session): session closed for user martin
lines 1-14/14 (END)


hmmm - hoffentlich gibt das mehr aufschluss - ich weiß bald nicht mehr was ich noch machen kann?
Meint ihr denn dass es etwas bringt wenn ich den Rechner komplett (!) neu aufsetze? Ich kann das machen - Wenn sonst nix mehr helfen sollte, dann kann ich ja eine komplette Neuinstallation machen.

Es wäre halt wichtig, dass ich dann das auch gleich richtig mache - und sauber durchführe. Was meint ihr denn dazu?




hier die Hintergruende zu dem oben genannten Ideen

http://unix.stackexchange.com/questions/159221/how-display-log-messages-from-previous-boots-under-centos-7


On CentOS 7, you have to enable the persistent storage of log messages:
Code:
# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald
Otherwise, the journal log messages are not retained between boots.

Details
Whether journald retains log messages from previous boots is configured via /etc/systemd/journald.conf. The default setting under CentOS 7 is:

[Journal]
Storage=auto
Where the journald.conf man page explains auto as:

One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes.


-hoffe dass wir damit weiterkommen - ansonsten freu ich mich sehr über Ideen, die das Problem weiter eingrenzen. GGF kann ich den Rechner aber auch mal komplett neu aufsetzen, Was meint Ihr denn!?


Viele Grüße lin
 
OP
L

lin

Hacker
hallo u. guten Abend,

update nach dem nix mehr gehollfen hat - auch nicht die neuinstallation der opensuse leap 42-1 hab ich dann die version 13.2 installiert.

damit - kann ich den Rechner herunterfahren...







hier die vorigen versuche - auch nochmals einer neuaufgesetzten leap 42.1



hab alles neu installiert - mit opensuse leap 42.1

es ist leider nicht besser geworden - beim Runterfahren hängt sich das Notebook leider immer noch auf - nun mit der folgenden Meldung:

Code:
Ignoring BGRT: invalid status 0 (expected 1)

Das Einfrieren - woher kommt es: Hat es mit dem Linux-kernel oder Systemd zu tun?

Wie gesagt - bei der Version 13.2 war alles okay.

Code:
BGRT is the ACPI Boot Graphics Resource Table.

hier habe ich folgendes gefunden:
http://askubuntu.com/questions/688860/ignoring-bgrt-invalid-status-0-expected-1

The error you see is because the status value in the table is zero, hence bit 0 (the display bit) is not turned on, so the boot graphic is not being displayed. The BGRT message is just reporting that this is disabled on your machine, and it is not a fatal error.

Was kann man dagegen jetzt tun?
 

wolfi_z

Hacker
Gibt es dafuer eigentlich inzwischen irgendeine Loesung?

Ich habe das Problem mit einem Lenovo Laptop seit ich diesen besitze und es ist mit 42.x und dito mit Tumbleweed nicht zu beheben.
Manchmal funktioniert der Shutdown, in aller Regel bleibt der Rechner aber bei einer Welcome-Zeile (quasi wie Login auf Terminal 1) stehen.

LG ... Wolfi
 

marky

Newbie
Es klingt ein wenig nach beklopptem Voodoo, aber ich stand eine ganze Weile vor dem gleichen Problem. Nur hartes Ausschalten half. Aus Lust und Laune wechselte ich mal das Desktop Theme unter KDE von dem default openSUSE auf Breeze. Seither keine Probleme mehr. Mir fehlt zwar der Kontext, aber es klappt zumindest. Zurückgewechselt, Rechner hängt fest. Also muss es da einen Zusammenhang geben. Also gut möglich, dass ein Plasmoid verantwortlich ist, was unter dem default Theme läuft.
 

wolfi_z

Hacker
OK marky, ich probier das mal aus ;)

LG ... Wolfi :D

Edit: Aendert nix ... ausser dass es haesslich aussieht - Breeze halt ... :igitt:
 

goeba

Hacker
Probleme mit dem Desktop kann man einfach ausschließen, wenn man

a) Sich z.B. in eine ICEWM Session einloggt und dort in einem xterm als root "shutdown -h now" eingibt.

b) Wenn Du bei Deinem Login Manager eine Terminal-Session definiert hast, nimm die, probiere dort den shutdown

c) Mit ctrl-alt-f1 eine Konsole öffnen, dort init 3 eingeben, dann shutdown

Sollte eines von denen funktionieren, wäre man einen Schritt weiter. Wenn a) geht, könnte es an einem Plasmoid liegen. Wenn b/c geht, aber nicht a, am Grafiktreiber.

Mein Notebook beispielsweise funktioniert mit dem SuSE-Standardkernel überhaupt nicht gut, ich verwende den neusten Kernel aus "kernel-stable", das wäre dann meine Empfehlung.
 

wolfi_z

Hacker
Hi goeba,

Das manuelle Runterfahren (allerdings nicht ueber IceWM) hab ich IIRC auch schon mal versucht, ohne nennenswerten Erfolg.

Tumbleweed installiert eigentlich fast laufend neue Kernel. Ich pruefe das mal mit dem Kernel-Stable, bin jetzt auf der anderen Dose.

LG ... Wolfi ;)
 

goeba

Hacker
Wenn Du Tumbleweed verwendest, bringt das nichts mit dem Kernel ändern, der ist aktuell genug. Ich dachte, es geht noch um Leap.
 

goeba

Hacker
wolfi_z schrieb:
Hi goeba,

Das manuelle Runterfahren (allerdings nicht ueber IceWM) hab ich IIRC auch schon mal versucht, ohne nennenswerten Erfolg.

Hast Du denn beim manuellen Herunterfahren dafür gesorgt, dass KDE bzw. X nicht mehr läuft?

Du könntest auch noch den Rechner direkt in eine Konsole booten (ohne X) und schauen, ob er dann wieder runterfährt. Oder Du bootest ihn so, dass er einen Standard VGA Treiber lädt (wie heißt der nochmal? Ich stehe gerade auf dem Schlauch). Wie das geht findest Du im Internet, da ich das nur selte mache, weiß ich es nicht auswendig.
 

wolfi_z

Hacker
goeba schrieb:
Wenn Du Tumbleweed verwendest, bringt das nichts mit dem Kernel ändern, der ist aktuell genug. (...)
Ja richtig, hat sich auch nix geaendert mit 'Kernel-Stable'.
Ich hab in diesem Thread weitergeschrieben, weil das Problem unabhaengig von Leap / Tumbleweed ist und mit verschiedenerlei neuerer Hardware auftritt.

Jetzt grad hab ich mal folgendes (= erst X stoppen, dann Runterfahren) ausprobiert und das hat zumindest schon einmalig funktioniert - ist jetzt noch keine Garantie, dass es immer funktioniert, denn manchmal ging es ja auch vorher schon
Code:
root@linux-iodi:/home/wolfi> init 3
root@linux-iodi:/home/wolfi> shutdown -h now
Ich probier das jetzt die naechsten paar mal wieder so, und falls es auf diese Weise zuverlaessig funktioniert, dann haengt es tatsaechlich am X System.

LG ... Wolfi ;)
 

goeba

Hacker
Dann könnte es auch immer noch an KDE bzw. einer der gestarteten Anwenungen / Plasmoids liegen oder an irgend etwas anderem, was in Runlevel 5 läuft, in 3 aber nicht.

Daher noch mein Rat, mal von X aus, aber ohne KDE zu probieren. Noch elementarer als ICEwm wäre es, nur ein xterm zu starten. (wenn das dann zuverlässig funktioniert, liegt es wahrscheinlich an KDE und eben nicht an X selbst)

Ich hatte mal irgendwann für sowas eine .desktop Datei, Infos dazu findest Du aber auch im Internet.
 

wolfi_z

Hacker
So alles probiert, sowohl von Ice WM als auch noch zweimal zweistufig per Kommandozeile (was ja einmal funktioniert hatte) -> hilft alles nix :schockiert:

Dass das 'Zweistufige' einmal funktioniert hat, war wohl ein Glueckstreffer. Es liegt also nicht an X oder KDE, da es auch ohne haengenbleibt :igitt:

LG ... Wolfi :eek:0:
 
Oben