[Leap 15.1] Unregelmäßig sterbender X11-Server

@Sauerland

Den Tipp probier ich am Wochenende mal aus.

Der Fehler ist ja urplötzlich aufgetreten, bei Leap 15.0 und auch nach dem Upgrade auf Leap 15.1 war das Problem zu Beginn noch nicht vorhanden.

So "unklare" Fehler machen mich immer etwas hibbelig. Ist für mich wie stochern im Nebel, wenn ich mit einer Fehlermeldungen in den Suchmaschinen auch nicht weiterkomme und wie ein Ochse vor Scheunentor stehe.

Ich komm halt aus *ner IT-Welt, da hab ich die Message-ID des Errors und in gefühlt 1000 Seiten Messages and Codes einen Hinweis auf den Fehler und ob bzw. wie der zu beheben ist. So etwas wie eine eindeutig erkennbare Error-Id fehlt mir im Systemlog, mit der man dann einen Hinweis auf die mögliche oder tatsächliche Ursache findet oder eine genauere Fehleranalyse betreiben kann.

Aber mir fällt gerade etwas ein, das ich Wochenende auch noch mal prüfen muss. Bis vor einem halben Jahr hatte ich ja noch eine Dockingstation für mein Dienst-Notebook hier und meine Tastatur, Maus und Monitor über einen ATEN CS692 2-Port USB HDMI KVM Switch mit PC und Dockingstation verbunden. Seit Dezember hängt an dem Switch meist nur mein PC und nur gelegentlich (um Updates einzuspielen) das HP Notebook meiner Frau dran.

Eben ist es bei der Benutzung vom Chromium "eingefroren" bzw. abgestürzt.

Zitat von Sauerland

Code

acpi=off

Das hat nicht geholfen, der Rechner bleibt beim laden der initial Ram-Disk hängen.

Nach dem Neustart war jetzt plötzlich die Netzwerkkarte nicht mehr eth0 sondern eth1.

Ich versuch jetzt erstmal dahinter zu kommen, wie ich Fehlermeldungen im Systemjournal erkennen kann. Aber nur im Terminal sind einige Meldungen hervorgehoben und ein paar sogar in rot. Wobei die roten sich auf meinen eingebauten USB3-Kartenleser (no caching mode found) beziehen bzw. gelegentlich Meldungen vom smartd.

Bei der Netzsuche nach folgender Meldung:

kwin_x11[2081]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 42950, resource id: 146800649, major code: 19 (DeleteProperty), minor code: 0

Hab ich einen Hinweis zu kwin_x11 instabil gefunden. Ich werde auch mal versuchen die beiden Verzeichnis .local und .config wegsichern und neu aufzubauen.

Kanonentux

Danke für die Info. Ich hab eine AMD FX-6300 CPU in meinem Rechner. Der Grub-Parameter würde mich schon interessieren, falls du in noch auftreiben kannst.

Ich hab auf jeden Fall gestern die Verzeichnisse .config, .local. .kde4 und .cache gelöscht und bin jetzt gerade dabei meine ganzen Konfigurationen wieder neu aufzubauen. Ich hab auch erstmal wieder den Display-Manager auf sddm gesetzt. Werde aber noch einen Versuch mit xdm starten

Ich hab aber noch 2 Einstellungen im BIOS angepasst. Nach einer Meldung im Systemjournal sollte IOMMU enabled gesetzt werden, was ich getan hab, die Meldung im Systemjournal ist aber weiterhin vorhanden (wohl nur ein Hinweis auf die Bios-EInstellung). Und Suspend to RAM war im BIOS eingestellt, was bisher scheinbar nicht gestört hat, ist jetzt disabled.

Nach einem ersten Blick ins System-Journal tauchen jetzt auch haufenweise plasmashell Meldungen auf. Ich werde im Laufe des Tages mal versuchen, einen Teil des Systemjournals in einen Textfile zu kopieren und hier einbringen. Versuche aber vorher noch ein paar von den Meldungen mit Hilfe der Suchmaschinen zu analysieren.

Möglicherweise hab ich den Übeltäter gefunden. Ich hatte das Repo KDE:Extra eingebunden, weil ich eine aktuellere Version von digikam (6.4), wegen dem digikam-plugin haben wollte.

Ich hab da wohl bei den letzten Updates geänderte Versionen von KDE-Programmen und -Libs (5.5.x) erwischt. Ich hab das REPO rausgenommen und einen Downgrade der Files vorgenommen, die aus diesem Repo kamen. Bis jetzt sind die meisten Plasmashell_Meldungen nicht mehr aufgetaucht.

Ich beobachte das jetzt mal ein paar Tage, wenn das Problem nicht mehr auftaucht, dann setze ich das Thema auf erledigt.

Danke an alle die mir mit ihren Tipps geholfen haben.

Zitat von Trekkie00

Hattest du das auch passend priorisiert und dann tatsächlich nur digikam und eventuell nötige Abhängigkeiten daraus installiert oder ein komplettes zypper dup auf das Repository oder sogar ein Repository übergreifendes zypper dup gemacht?

Erstere Lösung sollte eigentlich relativ unfallfrei funktionieren. Habe das allerdings jetzt nicht selbst getestet.

Das Repo war anfangs mit der Standardpriorrität eingebunden. Ich hab dann irgendwann mal die Prioritäten verändert, so dass es zwischen den Distri-Repos und den Update-Repos hing. Wenn ich das laufende System aktualisiere, dann nur mit zypper patch bzw. zypper up. Ich hab zwischendurch beim Suchen nach einem bestimmten Software-Paket dabei ein- oder zweimal mit Yast Pakete aktualisiert, und wohl in den Fällen nicht darauf geachtet, aus welchem Repo sie gezogen werden. Normalerweise schaue ich dabei aus welchem Repo sie kommen.

Die aktuellere Version von digikam hatte ich gezielt über YAST installiert. Was wäre denn die sicherere Variante, aus so einem repo nur ein ganz bestimmtes Paket zu ziehen und auch mal upzudaten, ohne sich andere Pakete zu überschreiben?

Ich würde jetzt das Repo nochmal aktiviert, digikam 6.4 installiert und das Repo wieder abgehängen, ich bekomme dann zwar keine Updates mehr für digikam, aber damit kann ich leben.

Danke für den Hinweis. Falls das Einfrieren bei mir wieder auftaucht, probier ich das mal für den AMD-Proc aus.

Möglicherweise hab ich aber meinen Übeltäter gefunden, den ich mir selber über das KDE:EXTRA-Repo eingebrockt habe. Bisher sind viel weniger Plasmashell Meldungen aufgetaucht.