Beiträge von Wiko

danke, Heinz-Peter . den o.g. Beitrag hatte ich auch schon gefunden. Allerdings hatte ich den Lösungsvorschlag damals nicht ausprobiert, weil ich mir nicht vorstellen konnte, dass es nach einem frischen Reboot "abandoned user sessions" geben sollte. Auf Deinen Rat hin habe ich den Lösungsvorschlag von Markus Oberer nun doch probiert; leider hat es keinen Effekt bei mir. Wenn ich seine Zeilen eingebe und danach neu boote, wird X immer noch nicht geladen.

Nachdem ich ein Mal erfolgreich startx als root durchgeführt habe, funktioniert es danach auch als User. Nach dem nächsten Reboot ist startx als user aber wieder defekt. --> erhärtet für mich den Verdacht des Rechteproblems

Anbei findet ihr nun einmal die X.org.log wenn der X Init durchläuft und einmal wenn er schief geht.

Der erste Punkt, in dem sich die beiden Xorg-logs unterscheiden ist, bei dem fehlgeschlagenen Init die Protokollzeile

systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration

während in der Xorg.log des funktionierenden Init die folgende Zeile steht:

systemd-logind: took control of session /org/freedesktop/login1/session/_31

Wenn ich nun nach der Fehlermeldung im Code Schnipsel oben suche, komme ich im Netz zu diversen möglichen Erklärungen (z.B. X wird gestartet bevor die Grafik richtig initialisiert wurde, Zufallszahlengenerator zu langsam) aber die Lösungsvorschläge dort haben keinen Effekt. Wer hat noch eine Idee?

danke, das ist eine gute Idee.

btrfs qgroup show /

ist ohne Fehler durchgelaufen.

btrfs balance --full-balance /

ist nun auch ohne Fehler abgeschlossen. Das Problem "X startet nicht" tritt aber leider weiterhin auf.

Noch eine Erkenntnis:

Der X-Abbruch erfolgt bereits vor dem Start des Login Managers.

Ich hab nun von einem alten Snapshot einen Rollback gemacht. Der lief noch. Dann habe ich mit

zypper in plasma* kde* x* y* linux*

testweise die ganzen Basics upgedated. Beim ersten Booten danach hat der SDDM login Manager noch funktioniert!! Einzig das SDDM Theme war kaputt, worüber er sich beschwert hat, aber ist ja egal.

Nachdem ich danach dann "zypper dup" gemacht habe, war der grafische Login Manager aber wieder kaputt. Beim "zypper dup" ist mir aufgefallen, dass er "pam-deprecated" deinstalliert hat. Aufgrund der beiden Beobachtungen 1) "pal-deprecated wurde deinstalliert" und 2) grafischer Login im normalen Boot Prozess nicht möglich aber als root per startx schon, würde ich vermuten, dass es etwas mit den Zugriffsrechten zu tun hat.

Wer hat einen Tipp, wie man vielleicht in die Richtung weiter untersuchen könnte?

Ansonsten habe ich auch mal meine xorg.log beigefügt. Vielleicht findet ja jemand von Euch etwas, das ich noch nicht gesehen habe.

vielen Dank für Eure Hilfe.

nein, leider auch nicht mehr. Es kommt das gleiche Problem mit einem älteren Kernel.

Die letzten Fehlermeldungen aus /var/log/x.org sind wie folgt:

-------------------------------------------------------

......

[ 482.866] (--) NVIDIA(GPU-0): Samsung S24D340 (DFP-1): connected

[ 482.866] (--) NVIDIA(GPU-0): Samsung S24D340 (DFP-1): Internal TMDS

[ 482.866] (--) NVIDIA(GPU-0): Samsung S24D340 (DFP-1): 600.0 MHz maximum pixel clock

[ 482.866] (--) NVIDIA(GPU-0):

[ 482.866] (--) NVIDIA(GPU-0): LG Electronics BN650Y (DFP-2): connected

[ 482.866] (--) NVIDIA(GPU-0): LG Electronics BN650Y (DFP-2): Internal DisplayPort

[ 482.866] (--) NVIDIA(GPU-0): LG Electronics BN650Y (DFP-2): 960.0 MHz maximum pixel clock

....

[ 507.940] (II) NVIDIA(0): Setting mode "DP-0: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}, HDMI-0: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}"

[ 508.225] (II) NVIDIA(0): Setting mode "DP-0: nvidia-auto-select @1920x1080 +1920+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}, HDMI-0: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}"

[ 508.502] (EE) modeset(G0): failed to set mode: No space left on device

[ 508.509] (EE) modeset(G0): failed to set mode: No space left on device

[ 543.036] (**) Option "fd" "39"

[ 543.036] (II) event1 - Power Button: device removed

[ 543.036] (**) Option "fd" "42"

[ 543.036] (II) event0 - Power Button: device removed

[ 543.036] (**) Option "fd" "43"

[ 543.036] (II) event2 - Logitech USB Keyboard: device removed

[ 543.036] (**) Option "fd" "44"

[ 543.036] (**) Option "fd" "45"

[ 543.036] (II) event4 - Logitech USB Keyboard System Control: device removed

[ 543.036] (**) Option "fd" "48"

[ 543.036] (II) event8 - HD Pro Webcam C920: device removed

[ 543.036] (**) Option "fd" "49"

[ 543.036] (II) event6 - Microsoft Microsoft Basic Optical Mouse v2.0 : device removed

[ 543.036] (**) Option "fd" "44"

[ 543.036] (II) event3 - Logitech USB Keyboard Consumer Control: device removed

[ 543.039] (II) UnloadModule: "libinput"

[ 543.039] (II) systemd-logind: not releasing fd for 13:67, still in use

[ 543.039] (II) UnloadModule: "libinput"

[ 543.039] (II) systemd-logind: releasing fd for 13:70

[ 543.125] (II) UnloadModule: "libinput"

[ 543.125] (II) systemd-logind: releasing fd for 13:72

[ 543.213] (II) UnloadModule: "libinput"

[ 543.213] (II) systemd-logind: releasing fd for 13:68

[ 543.241] (II) UnloadModule: "libinput"

[ 543.241] (II) systemd-logind: releasing fd for 13:67

[ 543.269] (II) UnloadModule: "libinput"

[ 543.269] (II) systemd-logind: releasing fd for 13:66

[ 543.305] (II) UnloadModule: "libinput"

[ 544.774] (II) systemd-logind: releasing fd for 13:64

[ 544.814] (II) UnloadModule: "libinput"

[ 544.814] (II) systemd-logind: releasing fd for 13:65

[ 545.172] (II) NVIDIA(GPU-0): Deleting GPU-0

[ 545.174] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error

[ 545.174] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error

[ 545.174] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error

[ 545.174] (II) Server terminated successfully (0). Closing log file.

------------------------

was mir dabei auffällt:

- "(EE) modeset(G0): failed to set mode: No space left on device" ---> ???? kann ich mir nicht vorstellen: "btrfs fi usage /" sagt, dass noch genügend frei ist. Quotas habe ich nicht

- die ganzen Einträge zu Keyboard, event failed, device removed

- die ganzen Einträge "unload module "libinput""

- die letzten vier Einträge "Input/Output Error", vielleicht weil der Keyboard Treiber entladen worden ist?

Hmm, noch habe ich keine Ahnung, was da passiert ist.

nach dem Update jetzt nichts mehr. Ist alles installiert.

Oder was genau meinst Du mit der Frage?

Hallo zusammen,

nach dem letzten Tumbleweed Update startet X nicht mehr automatisch beim Hochfahren. Genauer gesagt, es kommt der Ladebildschirm mit den drei Punkten und ca 10 Sekunden nach dem dritten Punkt lande ich wieder auf der Konsole zum Einloggen. Wenn ich dann versuche, X per "startx" manuell zu starten kommt die Meldung, dass xinit nicht gestartet werden kann, weil das setuid Bit nicht gesetzt ist und ich doch bitte X per KDE Session Manager starten soll.

Interessanterweise startet X aber problemlos per startx wenn ich root bin.

Vor dem Update war ich zwei Wochen im Urlaub; entsprechend lange hatten sich die Updates angesammelt. Aber das sollte ja kein Problem sein.

Mein System ist ein AMD Ryzen 7 3700x mit einer Nvidia GTX950 GraKa, proprietäre NVIDIA Treiber. Wenn ich als Root X starte, sagt mir KInfoCenter, dass X mit nvidia Treiber verwendet wird. Die nvidia-Treiber scheinen also grundsätzlich zu funktionieren.

Was kann ich machen, damit X bei Hochfahren wieder normal gestartet wird?

So ... Erstmal vielen Dank in die Runde und die vielen (teilweise sehr deutlichen) Antworten. Um mal einige der oben genannten Dinge aufzugreifen:

- Snapper mit Rollback kenne ich, finde ich gut und würde ich auch nutzen, wenn der Rechner nach dem Update nicht mehr hochfährt. Ist mir bisher aber noch nicht passiert.

- Warum das "erstarren lassen" der "Philosophie von Linux diametral entgegen steht" verstehe ich nicht. Aber ist auch egal. Das Schöne ist ja, dass mit Linux jeder seine eigene Philosophie haben kann.

- Für mein Desktop System mit Linux schätze ich die Gefahr relativ gering ein, dass ich mir mit einem Update neue Bugs einfange, die auch für andere Nutzer sicherheitskritisch sind. Wie schon gesagt, ich habe >15 Linux Erfahrung und kann mich von den größten Gefahren und Unsinnigkeiten inzwischen recht gut fernhalten. Updates für alte Bugs zu bekommen hat natürlich schon Prio.

- Es gab in den letzten 15 Jahren immer mal wieder Zeiten, wo mir (auf dem Desktop, kein Server!) Stabilität wichtiger war und Zeiten wo ich in der Breite einfach neuere Software haben wollte. Falls ich mein Primärsystem mit openSuse statt mit Debian aufsetzen würde, gehe ich davon aus, dass ich diese wechselnden Anforderungen auch mit openSuse haben werde.

- Trekkie00: ein "ewiges hin und her" ist das Erstarren lassen ja gerade nicht, sondern der Stand des Systems wächst sich einfach vom Rolling Release in das nächste reguläre Release aus. Ab dem Releasezeitpunkt läuft der Rechner dann ja auf diesem Release. Ich mach das ja gerade deshalb unter Debian so, weil es so einfach ist.

- egostra: okay, keine Updates machen bei Tumbleweed führt ja dazu, dass ich gar keine Sicherheitsupdate mehr bekomme. Aber der Punkt ist schon richtig: Kann ich nicht einfach aus Tumbleweed heraus das Repository auf das kommende reguläre Release ändern und dann abwarten, bis die Versionsnummern der Pakete im nächsten regulären Release die installierten Versionsnummern überholen? Das meine ich mit "erstarren lassen".

Ich fass jetzt erstmal für mich zusammen, dass das Erstarren lassen unter openSuse nicht geht und Ihr es für eine unsinnige Idee haltet. Ist ja schon mal 'ne Aussage. Danke.

Hallo in die Runde,

leider ist mir kein besserer Titel für diesen Post eingefallen; es geht um Folgendes:

Seit 15 Jahren nutze ich Debian auf dem Desktop und kenne mich da gut aus. Debian hat jeweils drei Release Level: stable, testing und unstable. Normalerweise verwende ich Debian testing. Manchmal lasse ich die Repositories aber auch nach einem Release ein paar Monate auf stable stehen, bevor ich wieder zu testing wechsle. Und selten wechsle ich auch zu unstable. Wenn mich die vielen Updates dann wieder aufregen, lasse ich das System erstarren, d.h. ich ändere die Paketquellen einfach wieder zu testing und warte, bis sich die Updates wieder bei testing eingespielt haben. Mir ist klar, dass ich während dieser Zeit keine Sicherheitsupdates erhalte aber grundsätzlich funktioniert das auf diese Weise gut mit mir und Debian.

Nun habe ich vor ein paar Monaten auf meiner zweiten Festplatte zum Testen openSuse installiert. Zunächst mit Leap 15.2. Später habe ich dann auf Tumbleweed gewechselt. Nun nerven mich auch dort die vielen Updates. Eine komplette Neusinstallation mit Leap ist mir aber zu lästig. Wenn ich nun bei openSuse wieder Leap in die Repositories eintragen, will er alles Mögliche deinstallieren. Und eigentlich geht es gar nicht weil zig Abhängigkeiten nicht erfüllt sind.

Gibt es unter openSuse nun auch eine Möglichkeit, dieses langsame Erstarren des gewählten Release wie oben für Debian beschrieben auch hier umzusetzen?

Was haltet ihr überhaupt von der Vorgehensweise unter openSuse?

Danke für Eure Hilfe.

Wiko