Beiträge von Hidalgo

Zitat von Heinz-Peter

Du darfst schon Deine Meinung haben, wir sind hier im freien Land

Was ich aber nicht verstehe? Wenn der neue Kernel nicht geht dann kannst Du noch immer mit dem alten Kernel booten.

Ja - habe ich ja auch gemacht.

Inzwischen läuft ja auch der ***60er Kernel mit dem AMD Treiber,

siehe Thread: "Nach Sicherheitsupdate Leap 15.2 startet Grafik nicht mehr".

Trotzdem ist es ein gravierender Fehler, der nun zweimal auftrat.

Beim ersten Mal als das auftrat, wurde allerdings - sicher durch meinen Fehler auch

wenn ich Anweisungen befolgte - der vorherige Kernel wegen eines Korrekturversuchs überschrieben

und nun lief nichts mehr.

Über ssh installierte ich über yast damals dann zwar den alten Kernel, aber die Grafik wurde

wegen inkompatibler Grafikeinstellungen nur im Vesa-Modus angezeigt. Da war einiges kaputt

gegangen.

Über das BTRFS-Filesystem machte ich ein "Rolling Back" und schon war alles wieder klar -

natürlich mit altem Kernel.

Dann kam einen Monat später der korrigierte Kernel bis nun das Spiel wieder von vorn losging.

Nun habe ich die "wasweissich.conf" - war es zypp.conf (?) so geändert, dass die letzten fünf Kernel

behalten werden - sicher ist sicher und auf der SSD ist genug Platz.

Ja - man lernt dazu, aber man macht das ja nicht jeden Tag

Zitat von sterun

Um auch vorherige Boots / Shutdowns via Logfiles auswerten zu können, muss eine kleine Änderung vorgenommen werden in:

/etc/systemd/journald.conf

In diesen zwei Zeilen die "#" entfernen und folgende Änderungen vornehmen:

Storage=persistent

SystemMaxUse=100M

Zur Erklärung:

Storage=persistent (Dauerhaftes Speichern der Logfiles ermöglichen)

SystemMaxUse=100M (Logfiles sollen jedoch eine Größe von 100MB nicht überschreiten)

Danach funktioniert:

Code

journalctl -b -1 -p err

oder

Code

journalctl -b -2 -p err

u.s.w.

Wenn du ....-p err weglässt, bekommst du alle Meldungen.

-p err (bedeutet, dass nur Meldungen mit Prio Error oder sogar schlimmer angezeigt werden)

-b -3 (zeige mir alle Meldungen aus dem drittletzten Boot / Shutdownvorgang)

Alles anzeigen

Ganz hervorragend! Danke - das werde ich bei mir gleich ändern.

Gruß ...

Zur Behebung des Problems würde ich folgenden Weg gehen

falls der vorhergehende Kernel mit Kaffeine die gleiche Problematik zeigt:

Diesen hier:

https://opensuse-guide.org/codecs.php

@ MA

Auch ich hätte einiges zu meckern - aber einem geschenkten Betriebssystem schaut man nicht ins Maul

und da reagieren einige allergisch drauf nach dem Motto: "Mach' selbst!" Und irgendwie haben die Recht.

Aber wenn der screen nach einem Kernel-Update zweimal innerhalb von vier Monaten abranzt, weil komplette

AMD-Grafikkarten nicht korrekt bedient werden, dann kann ich einen Windows User schlecht von Linux,

speziell OpenSuSE überzeugen. Noch nicht mal Textkonsole geht mit dem *60er Kernel und klar kann man

sich helfen, weil Linux transparent ist und log-files ausführliche Hilfe zur Selbsthilfe leisten. Dazu braucht man

nur einen zweiten Rechner und ssh-Zugriff. Wie man allerdings an das log-file des vorher fehlgeschlagenen Boots

kommt nachdem man danach mit dem funktionierenden Kernel bootete weiß ich immer noch nicht - dann das wäre

der einfachere Weg. Da kann man die Konfigurationsdateien für dmesg umstellen und dann soll das funzen -

eingestellt ist das Vorab aber nicht.

Auf Bugzilla sollte ich das Logfile dmesg des funktionierenden Kernels liefern, des nicht funktionierenden

Kernels und von hwinfo. Als ich das endlich hinbekam, war jemand anderes schon schneller und wies darauf

hin, dass der kernel-Bug schon mal aufgetreten ist. Das hatte ich eingangs auch gleich und auf die Nummer

hingewiesen - aber man ist ja höflich und das auf englisch.

Ja - Hilfe bekommt man und alle sind sehr nett ...

aber irgendwie habe ich den Eindruck mit SuSE geht das den Bach 'runter, was das Debugging betrifft.

Wäre jammerschade!

Ist nur meine Meinung - bitte nicht böse sein.

Ich will hier eigentlich nur helfen falls ich es kann.

Recht haben will ich nicht ... ich habe wie gesagt nur eine subjektive Meinung.

Gruß ...

Nur mal zur Info: Pavucontrol habe ich bei mir nicht installiert, weil ich es

nicht vermisse und Kaffeine aber auch VLC machen was sie sollen (Radio / TV)

Ich spiele auch ein wenig Klavier und Aufnahmen mit audacity lassen sich problemlos

bewerkstelligen nachdem die korrekte Quelle angewählt wurde (über USB).

Ich weiß gar nicht wozu ich Pavucontrol brauchen sollte. Pulseaudio ist natürlich

installiert ...

Wann ist das Problem mit Kaffeine denn aufgetreten - nach einem Softwareupdate?

Vielleicht mal mit dem älteren Kernel das System starten?

Gruß ...

Kaffeine ist mMn. nur eine Benutzeroberfläche wie auch der vlc

und diese setzen zum Abspielen von Video oder Musik auf keine eigenen

Programmfunktionen, sondern setzen auf libraries. Die libraries werden i.d.R.

weiterentwickelt. Kaffeine setzte mal auf "xine-lib" und nun auschließlich auf "libvlc"

wenn ich mich nicht täusche.

Kaffeine nutze ich seit frühesten SuSE-Versionen - auch Tumbleweed und Leap

weil es mir von der Benutzeroberfläche am besten gefällt, statt z.B. der Dragonplayer

oder auch der vlc. Es macht ja auch wenig bis keinen Sinn, die Benutzeroberfläche umzugestalten

wenn die pragmatisch genug ist. Auch der vlc sieht ja seit Jahren gleich aus.

Selten gab es Probleme mit Bild / Ton und auch der Umstieg auf DVBT-2 funktionierte

tadellos, sobald das Subsystem (damit meine ich die o.a. Libraries und auch den Treiber

für meinen Hauppauge Win-TV Nova welcher ja vom Kernel erkannt werden muss) ok war.

Zum Thema Kaffeine gibt es auf der Support Seite der Entwickler aktuelle Beiträge.

Gab es Probleme, dann saß der Übeltäter vor dem Bildschirm - weil der wieder mal an

den Multimedia-Codecs rumexperimentiert hatte.

Gruß ...

Super! - Ja so kann man das auch bewerkstelligen. Mir kam zugute,

dass ich einen ssh-Server auf dem SuSE-Rechner eingerichtet hatte, da ich

mit Netzwerken unter Linux Erfahrungen sammelte. Dazu nutzte ich damals

noch den Laptop meiner Frau. Port 22 war somit auch freigeschaltet und der Zugriff war

dann überhaupt kein Problem auf das 60er System, nachdem ich mich dort vorher

blind anmeldete und der dann ohne Grafikanzeige hochfuhr.

Danke für die Rückmeldung und auch nochmal danke an Hans Braun für seinen Tipp.

Gruß ...

Ich würde mal versuchsweise die swap aus der fstab herausnehmen und schauen,

wie es beim darauffolgenden Boot reagiert. Da sind ja auch noch Parameter in der

fstab bzgl der swap angegeben.

Mach' mal - der Rechner startet auch ohne swap.

Ich bin mir ziemlich sicher, dass der Hase da im Pfeffer begraben liegt.

Moin!

Das Problem hatte ich in der Vergangenheit zwei Mal, suchte und fand darüber nichts was half.

Leider ist das schon länger her - das Problem hing eindeutig (bei mir) mit der Swap-Partition

zusammen. Die UUID dieser Swap stimmte nicht in der fstab. Warum sich das änderte konnte

ich nicht nachvollziehen, aber genau dort lag der Fehler welcher den zeitaufwendigen Systemstart

verursachte.

Bitte prüfe, ob die UUID der jetzigen Swap-Partition mit derjenigen übereinstimmt, die in der fstab

eingetragen ist. Wie man die aktuelle UUID der Swap-Partition herausfindet weiss ich jetzt nicht aus

dem Kopf - sollte aber kein Problem sein. Diese UUID muss natürlich mit derjenigen in der fstab übereinstimmen.

Gruß ... und viel Erfolg!!!

Es ist der gleiche Fehler. Die Treiber für die AMD Grafik werden nicht geladen,

so dass auch das Einloggen in die Textkonsole nicht funktioniert (klar ... wenn

die Grafikkarte überhaupt nicht mehr angesprochen wird).

Den Fehler habe ich wie auch schon damals vor ca. vier Monaten gemeldet

und in Bugzilla auf diesen im aktuellen Fall hingewiesen.

Da ich von einem Freund einen Laptop zur Verfügung gestellt bekommen habe

konnte ich von diesem via ssh auf den Linux-Rechner mit dem 60er Kernel zugreifen

und diesen dazu veranlassen, die Grafiktreiber für meine AMD-Karte korrekt

zu laden, mit folgenden Schritten als SuperUser (su):

mkdir /lib/modules/5.3.18-lp152.60-default/extra
cp /lib/modules/5.3.18-lp152.57-default/kernel/drivers/gpu/drm/radeon/radeon.ko /lib/modules/5.3.18-lp152.60-default/extra/
depmod 5.3.18-lp152.60-default
mkinitrd

Obiger Tipp stammt von "Hans Braun", der diesen im entsprechenden Thread auf

Bugzilla mitteilte und funktioniert einwandfrei. Ich arbeite also inzwischen mit dem

neuen 60er Kernel, nachdem ich diesen Tipp anwendete.

Bis zum nächsten Kernelupdate also am einfachsten den 57er Kernel verwenden.

Gruß ...

Zitat von Sauerland

Ich schätze einmal, es wird bald einen neuen kernel geben, Problem ist erkannt.

Ja, deshalb habe ich die Bug-Meldung als "fixed" deklariert. War übrigens eine tolle Erfahrung mit Bugzilla und dort sofort Unterstützung zu erhalten - zumal ich bei den geforderten Informationen manchmal auf dem Schlauch stand. So kam ich z.B. nicht an die vorherigen Boot Informationen des *.44 Kernel nachdem ich danach wieder mit dem *.41er bootete, obwohl ich die journald.conf auf "persistent" setzte. Ob das vielleicht durch das btrfs-Filesystem verursacht wurde, da es ja mit einem Snapshot vielleicht auch die vorherigen Meldungen verbirgt? Ich weiß es (noch) nicht - in erster Linie suche ich die Fehler sowieso bei mir. Naja ... eine Datei nicht hochladen zu können, weil diese zu "expensive" (zu teuer) ist, war dann ein bisschen lustig - ich meinte natürlich "large". Man "compressed" das und klar geht das problemlos - aber man macht es eben nicht jeden Tag. Wichtig ist aber auf jeden Fall, dass man Zeit mitbringt und somit auf "Standby" die Ursache eines Fehlers unterstützen kann. Auch an dieser Stelle herzlichen Dank für die Eröffnung dieses Threads und allen daran Beteiligten - hat sich gelohnt! So - melde mich erstmal aus dem Kreis - die Pflicht ruft - und bleibt gesund!

Mit dem Kernel Parameter "nomodeset" läuft nun auch der 5.3.18-lp152.44-default, d.h. nun auch mit Grafik. Allerdings nur mit einer Auflösung von 1450*1050. Das weist m.M.n. auf einen Bug im Kernel hin, Bugzilla habe ich entsprechend aktualisiert. Schön, dass mir dort ein weiterer User mit mehr Linux-Wissen unter die Arme griff. MfG