sddm crasht nach Update
Hallo, nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske. /var/log/messages: 2022-09-10T13:11:41.184034+02:00 ksc140 kernel: [ 39.240846][ T2365] sddm-greeter[2365]: segfault at d0 ip 00007fe497099b9d sp 00007fff47bb 7b60 error 4 in iris_dri.so[7fe4962c0000+16d2000] 2022-09-10T13:11:41.184036+02:00 ksc140 kernel: [ 39.240854][ T2365] Code: 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 50 4c 8d 4c 24 1 8 e8 72 e5 9e ff 48 8b 44 24 18 31 d2 4c 89 ef b9 04 00 00 00 <48> 8b a8 d0 00 00 00 48 89 ee e8 14 5c fd ff 49 8b bd 98 02 00 00 2022-09-10T13:11:41.192582+02:00 ksc140 systemd[1]: Created slice Slice /system/systemd-coredump. 2022-09-10T13:11:41.194269+02:00 ksc140 systemd[1]: Started Process Core Dump (PID 2434/UID 0). 2022-09-10T13:11:42.254700+02:00 ksc140 systemd-coredump[2435]: Process 2365 (sddm-greeter) of user 476 dumped core ... Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht. Hat jemand eine Idee, wie ich den sddm wieder zum Laufen kriegen kann? Viele Grüße, Klaus
Hallo Klaus, hallo zusammen, Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de:
nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske.
Leap oder Tumbleweed? (Ohne diese Info fällt es schwer, z. B. etwas zu einem evtl. kaputten Update zu sagen.) Falls Du btrfs verwendest, wäre ein Rollback eine Option.
/var/log/messages: 2022-09-10T13:11:41.184034+02:00 ksc140 kernel: [ 39.240846][ T2365] sddm-greeter[2365]: segfault at d0 ip 00007fe497099b9d sp
Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht.
Mit etwas Glück steht die Frage mitsamt aller Details in /var/log/zypper.log
Hat jemand eine Idee, wie ich den sddm wieder zum Laufen kriegen kann?
Guck erstmal nach, was kaputt ist. Ich würde mal alle Pakete durchprüfen lassen: rpm -Va > /tmp/rpm-Va Entweder Du liest die ganze Datei, oder Du filterst gleich die weniger relevanten Änderungen raus: grep -v ' /var/\| /etc/\| /run/' /tmp/rpm-Va Interessant sind vor allem Dateien mit 5 in der dritten Spalte (= geänderte md5sum). Mit rpm -qf /pfad/zur/datei findest Du raus, zu welchem Paket diese Datei gehört. Falls mehrere Pakete für die gleiche Datei gelistet werden, könnte das Dein Problem erklären. Gruß Christian Boltz --
# man script I'm always fascinated by the bizarre mental gymnastics that programmers go through when naming their programs. :-) I would expect a program designed for recording terminal dialog to be called 'record'. [> Felix Miata and J Leslie Turriff in opensuse-support]
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de:
nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske.
Leap oder Tumbleweed? (Ohne diese Info fällt es schwer, z. B. etwas zu einem evtl. kaputten Update zu sagen.)
Falls Du btrfs verwendest, wäre ein Rollback eine Option.
/var/log/messages: 2022-09-10T13:11:41.184034+02:00 ksc140 kernel: [ 39.240846][ T2365] sddm-greeter[2365]: segfault at d0 ip 00007fe497099b9d sp
Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht.
Mit etwas Glück steht die Frage mitsamt aller Details in /var/log/zypper.log
Hat jemand eine Idee, wie ich den sddm wieder zum Laufen kriegen kann?
Guck erstmal nach, was kaputt ist. Ich würde mal alle Pakete durchprüfen lassen: rpm -Va > /tmp/rpm-Va Entweder Du liest die ganze Datei, oder Du filterst gleich die weniger relevanten Änderungen raus: grep -v ' /var/\| /etc/\| /run/' /tmp/rpm-Va
Interessant sind vor allem Dateien mit 5 in der dritten Spalte (= geänderte md5sum). Mit rpm -qf /pfad/zur/datei findest Du raus, zu welchem Paket diese Datei gehört. Falls mehrere Pakete für die gleiche Datei gelistet werden, könnte das Dein Problem erklären.
Gruß
Christian Boltz
Hallo Christian, vielen Dank, das schaue ich mir an. Und ja, im Eifer des Gefechts die Info vergessen: Leap 15.4 Kernel 5.14.21-150400.24.18-default. Es ist kein btrfs, sondern ext4 in LVM2. Ich habe ein passendes Backupimage eingespielt -> sddm ok, danach wieder Update mit zypper -> sddm crasht. Viele Grüße, Klaus
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de:
nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske.
Leap oder Tumbleweed? (Ohne diese Info fällt es schwer, z. B. etwas zu einem evtl. kaputten Update zu sagen.)
Falls Du btrfs verwendest, wäre ein Rollback eine Option.
/var/log/messages: 2022-09-10T13:11:41.184034+02:00 ksc140 kernel: [ 39.240846][ T2365] sddm-greeter[2365]: segfault at d0 ip 00007fe497099b9d sp
Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht.
Mit etwas Glück steht die Frage mitsamt aller Details in /var/log/zypper.log sind ca 42500 Zeilen. Bin damit etwas ratlos, "sddm", "question", "write", "replace" finde ich darin nicht. Wonach müsste ich denn suchen? Beim Betrachten der Datei kommt mir keine zündende Idee ...
Guck erstmal nach, was kaputt ist. Ich würde mal alle Pakete durchprüfen lassen: rpm -Va > /tmp/rpm-Va Entweder Du liest die ganze Datei, oder Du filterst gleich die weniger relevanten Änderungen raus: grep -v ' /var/\| /etc/\| /run/' /tmp/rpm-Va
Interessant sind vor allem Dateien mit 5 in der dritten Spalte (= geänderte md5sum). Mit rpm -qf /pfad/zur/datei findest Du raus, zu welchem Paket diese Datei gehört. Falls mehrere Pakete für die gleiche Datei gelistet werden, könnte das Dein Problem erklären. Nach dem Greppen gibt es keine Zeile mit "5" in der dritten Spalte. Nur vor dem Greppen, aber in den rausgefilterten Verzeichnissen.
Viele Grüße, Klaus --
Hallo Klaus, hallo zusammen, Am Sonntag, 11. September 2022, 19:41:38 CEST schrieb funedv@gmx.de:
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de:
nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske. ... Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht.
Mit etwas Glück steht die Frage mitsamt aller Details in /var/log/zypper.log
sind ca 42500 Zeilen. Bin damit etwas ratlos, "sddm", "question", "write", "replace" finde ich darin nicht. Wonach müsste ich denn suchen? Beim Betrachten der Datei kommt mir keine zündende Idee ...
Du kannst erstmal zum Timestamp, bei dem Du das Update begonnen hast, springen. Falls es wirklich ein Dateikonflikt war, könnte "conflict" ein passender Suchbegriff sein. Aber da Du in Deiner anderen Mail geschrieben hast, dass Du das Problem mit Backupimage zurückspielen und erneutem zypper up reproduzieren kannst, kannst Du das nochmal machen und erstmal die zypper-Ausgabe mitschreiben: zypper up 2>&1 | tee /root/zypper-ausgabe.txt Anschließend bitte /root/zypper-ausgabe irgendwo hochladen (z. B. paste.opensuse.org) und den Link an die Liste schicken. Außerdem bitte vorher das zypper.log manuell wegrotieren, damit (falls wir das Log brauchen) keine alten Sachen drinstehen: old /var/log/zypper.log && xz /var/log/zypper.log-2022091? Nebenbei: Warum eigentlich "zypper up" und nicht "zypper patch"? Das würde für Leap eher passen. Hast Du zusätzliche Repos im Einsatz?
Guck erstmal nach, was kaputt ist. Ich würde mal alle Pakete durchprüfen lassen: rpm -Va > /tmp/rpm-Va ... Nach dem Greppen gibt es keine Zeile mit "5" in der dritten Spalte. Nur vor dem Greppen, aber in den rausgefilterten Verzeichnissen.
OK, dann sollten die relevanten Dateien (hauptsächlich in /usr/) in Ordnung sein. (Die Erklärung für alle Spalten steht übrigens in man rpm am Ende des Abschnitts VERIFY OPTIONS.) Gruß Christian Boltz -- Should you ever feel lonely or be overwhelmed with spare time: you know where to find us. [Dominique Leuenberger in opensuse-project]
Am 11.09.22 um 20:42 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Sonntag, 11. September 2022, 19:41:38 CEST schrieb funedv@gmx.de:
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de:
nach einem umfangreichen Update mit zypper up crasht der sddm. Es erscheint zwar ein verschiebbarer Mauszeiger, aber nicht mehr die Anmeldemaske. ... Bei dem Update wurde gefragt (sinngemäß), ob abweichende Dateiinhalte überschrieben werden sollen. Da ich im Terminalfenster nicht rückwärts scrollen konnte, habe ich diese Frage bejaht.
Mit etwas Glück steht die Frage mitsamt aller Details in /var/log/zypper.log
sind ca 42500 Zeilen. Bin damit etwas ratlos, "sddm", "question", "write", "replace" finde ich darin nicht. Wonach müsste ich denn suchen? Beim Betrachten der Datei kommt mir keine zündende Idee ...
Du kannst erstmal zum Timestamp, bei dem Du das Update begonnen hast, springen. Falls es wirklich ein Dateikonflikt war, könnte "conflict" ein passender Suchbegriff sein.
Aber da Du in Deiner anderen Mail geschrieben hast, dass Du das Problem mit Backupimage zurückspielen und erneutem zypper up reproduzieren kannst, kannst Du das nochmal machen und erstmal die zypper-Ausgabe mitschreiben:
zypper up 2>&1 | tee /root/zypper-ausgabe.txt
Anschließend bitte /root/zypper-ausgabe irgendwo hochladen (z. B. paste.opensuse.org) und den Link an die Liste schicken. Hier der Link: https://paste.opensuse.org/10244443
Außerdem bitte vorher das zypper.log manuell wegrotieren, damit (falls wir das Log brauchen) keine alten Sachen drinstehen:
old /var/log/zypper.log && xz /var/log/zypper.log-2022091?
/var/log/zypper.log gibts jetzt nicht mehr, dafür /var/log/zypper.log-20220913 mit dem Inhalt von /var/log/zypper.log. Hab ich da was falsch gemacht?
Nebenbei: Warum eigentlich "zypper up" und nicht "zypper patch"? Das würde für Leap eher passen.
Hm, habe ich immer so gemacht. Ist "zypper up" nicht ok?
Hast Du zusätzliche Repos im Einsatz?
Ja, ein paar.
Guck erstmal nach, was kaputt ist. Ich würde mal alle Pakete durchprüfen lassen: rpm -Va > /tmp/rpm-Va ... Nach dem Greppen gibt es keine Zeile mit "5" in der dritten Spalte. Nur vor dem Greppen, aber in den rausgefilterten Verzeichnissen.
OK, dann sollten die relevanten Dateien (hauptsächlich in /usr/) in Ordnung sein. (Die Erklärung für alle Spalten steht übrigens in man rpm am Ende des Abschnitts VERIFY OPTIONS.)
Gruß
Christian Boltz
Viele Grüße, Klaus
Hallo Klaus, hallo zusammen, Am Dienstag, 13. September 2022, 13:09:20 CEST schrieb Klaus Schneider- Grosch:
Am 11.09.22 um 20:42 schrieb Christian Boltz:
Am Sonntag, 11. September 2022, 19:41:38 CEST schrieb funedv@gmx.de:
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de: ... zypper up 2>&1 | tee /root/zypper-ausgabe.txt
Anschließend bitte /root/zypper-ausgabe irgendwo hochladen (z. B. paste.opensuse.org) und den Link an die Liste schicken.
Hier der Link: https://paste.opensuse.org/10244443
Danke, das hilft schonmal. (Details unten.)
Außerdem bitte vorher das zypper.log manuell wegrotieren, damit (falls> wir das Log brauchen) keine alten Sachen drinstehen: old /var/log/zypper.log && xz /var/log/zypper.log-2022091?
/var/log/zypper.log gibts jetzt nicht mehr, dafür /var/log/zypper.log-20220913 mit dem Inhalt von /var/log/zypper.log. Hab ich da was falsch gemacht?
Nö, das ist das erwartete Ergebnis. Wenn Du das nächste Mal zypper aufrufst, wird ein frisches zypper.log angelegt (ohne die Logzeilen der vorherigen zypper-Aufrufe).
Nebenbei: Warum eigentlich "zypper up" und nicht "zypper patch"? Das würde für Leap eher passen.
Hm, habe ich immer so gemacht. Ist "zypper up" nicht ok?
Hast Du zusätzliche Repos im Einsatz?
Ja, ein paar.
So könnte man das nennen ;-) Aus Deinem paste.o.o: Retrieving repository 'RepoMozilla' metadata [.done] Building repository 'RepoMozilla' cache [....done] Retrieving repository 'hardware' metadata [.done] Building repository 'hardware' cache [....done] Retrieving repository 'Publishing' metadata [.done] Building repository 'Publishing' cache [....done] Retrieving repository 'home:mnhauke' metadata [..done] Building repository 'home:mnhauke' cache [....done] Retrieving repository 'home:ithod:signal' metadata [..done] Building repository 'home:ithod:signal' cache [....done] Retrieving repository 'home:ecsos' metadata [..done] Building repository 'home:ecsos' cache [....done] Retrieving repository 'Emulators' metadata [.done] Building repository 'Emulators' cache [....done] Retrieving repository 'Packman Repository' metadata [.done] Building repository 'Packman Repository' cache [....done] [... die üblichen 15.4-Repos ...] Retrieving repository 'utilities' metadata [..done] Building repository 'utilities' cache [....done] Die Dateikonflikte entstehen, weil sich Pakete aus diesen Zusatzrepos "beißen". Das sollten wir zuerst reparieren: File /usr/bin/aviocat (+ diverse andere) from install of ffmpeg-4-4.4-pm154.2.7.x86_64 (Packman Repository) conflicts with file from install of ffmpeg-3-3.4.9-pm154.1.11.x86_64 (Packman Repository) -> zypper in ffmpeg-4 -ffmpeg-3 also ffmpeg-4 installieren und gleichzeitig ffmpeg-3 deinstallieren (und ein Bugreport an Packman wäre nett - eigentlich[tm] sollten die Pakete mindestens ein Conflicts: haben, wenn sie die gleichen Dateien ausliefern) File /usr/bin/ocrmypdf from install of python3-ocrmypdf-12.7.2-lp154.6.50.noarch (home:ecsos) conflicts with file from package OCRmyPDF-10.3.1-lp152.26.1.noarch (@System) OCRmyPDF-10.3.1-lp152 scheint ein altes Paket ("lp152") zu sein. Guck Dir rpm -qi OCRmyPDF an, vermutlich willst Du das deinstallieren und durch python3-ocrmypdf ersetzen. File /usr/bin/ts from install of ts-1.0.1-lp154.1.1.x86_64 (utilities) conflicts with file from package moreutils-0.66-bp154.1.20.x86_64 (@System) @System spricht auch für ein älteres / nicht mehr in einem Repo verfügbaren Paket (wobei mir der "bp154"-Suffix nix sagt). Auch hier würde ich eins der beteiligten Pakete deinstallieren (Auswahl anhand von "rpm -qi $paket"). Nebenbei: "moreutils" gibt es auch direkt in den Leap-Repos. Gibt es einen Grund, warum Du das aus einem anderen Repo installiert hast? Falls nicht, würde ich das Paket aus den Leap-Repos empfehlen. Und ganz allgemein: bist Du sicher, dass Du die ganzen Zusatz-Repos wirklich brauchst? Gruß Christian Boltz -- Most languages allow you to shoot your own foot, C just gives you a tank instead of a handgun ;-) [Cristian Rodríguez in opensuse-factory]
Am 13.09.22 um 23:30 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Dienstag, 13. September 2022, 13:09:20 CEST schrieb Klaus Schneider- Grosch:
Am 11.09.22 um 20:42 schrieb Christian Boltz:
Am Sonntag, 11. September 2022, 19:41:38 CEST schrieb funedv@gmx.de:
Am 10.09.22 um 21:22 schrieb Christian Boltz:
Am Samstag, 10. September 2022, 15:44:57 CEST schrieb funedv@gmx.de: ... zypper up 2>&1 | tee /root/zypper-ausgabe.txt
Anschließend bitte /root/zypper-ausgabe irgendwo hochladen (z. B. paste.opensuse.org) und den Link an die Liste schicken.
Hier der Link: https://paste.opensuse.org/10244443
Danke, das hilft schonmal. (Details unten.) [...]
Nebenbei: Warum eigentlich "zypper up" und nicht "zypper patch"? Das würde für Leap eher passen.
Hm, habe ich immer so gemacht. Ist "zypper up" nicht ok? zypper up installiert wohl neuere Versionen, während zypper patch wohl die Versionen beibehält, also keine Updates durchführt? Was ist denn für mich besser rsp. sicherer?
Hast Du zusätzliche Repos im Einsatz?
Ja, ein paar.
So könnte man das nennen ;-) [...]
Die Dateikonflikte entstehen, weil sich Pakete aus diesen Zusatzrepos "beißen". Das sollten wir zuerst reparieren:
File /usr/bin/aviocat (+ diverse andere) from install of ffmpeg-4-4.4-pm154.2.7.x86_64 (Packman Repository) conflicts with file from install of ffmpeg-3-3.4.9-pm154.1.11.x86_64 (Packman Repository) durchgeführt.
-> zypper in ffmpeg-4 -ffmpeg-3 also ffmpeg-4 installieren und gleichzeitig ffmpeg-3 deinstallieren (und ein Bugreport an Packman wäre nett - eigentlich[tm] sollten die Pakete mindestens ein Conflicts: haben, wenn sie die gleichen Dateien ausliefern) mache ich noch.
File /usr/bin/ocrmypdf from install of python3-ocrmypdf-12.7.2-lp154.6.50.noarch (home:ecsos) conflicts with file from package OCRmyPDF-10.3.1-lp152.26.1.noarch (@System)
OCRmyPDF-10.3.1-lp152 scheint ein altes Paket ("lp152") zu sein. Guck Dir rpm -qi OCRmyPDF an, vermutlich willst Du das deinstallieren und durch python3-ocrmypdf ersetzen. erledigt.
File /usr/bin/ts from install of ts-1.0.1-lp154.1.1.x86_64 (utilities) conflicts with file from package moreutils-0.66-bp154.1.20.x86_64 (@System)
@System spricht auch für ein älteres / nicht mehr in einem Repo verfügbaren Paket (wobei mir der "bp154"-Suffix nix sagt). Auch hier würde ich eins der beteiligten Pakete deinstallieren (Auswahl anhand von "rpm -qi $paket").
Nebenbei: "moreutils" gibt es auch direkt in den Leap-Repos. Gibt es einen Grund, warum Du das aus einem anderen Repo installiert hast? Falls nicht, würde ich das Paket aus den Leap-Repos empfehlen. habe ich jetzt aus den Leap-Repos.
Und ganz allgemein: bist Du sicher, dass Du die ganzen Zusatz-Repos wirklich brauchst? Das System wurde seit 42.3 immer wieder mit zypper dup gemäß diversen Empehlungen hier in der Liste / opensuse-Website hochgezogen. Wenn ich Werkzeuge in den Suse-üblichen Repos nicht bekommen konnte, hab ich sie aus den Community-Repos genommen. Im Lauf der Jahre ist das ziemlich unübersichtlich geworden. Ich würde die Repos wirklich gerne ausmisten, weiß aber nicht so richtig, wie ich das systematisch und sicher durchführen kann.
Leider crasht der sddm immer noch, s. /var/log/messages: 2022-09-14T10:59:42.135455+02:00 ksc140 systemd[1]: Started Process Core Dump (PID 3351/UID 0). 2022-09-14T10:59:43.185656+02:00 ksc140 systemd-coredump[3352]: Process 3282 (sddm-greeter) of user 476 dumped core.#012#012Found module linu x-vdso.so.1 with build-id: 267a3e00bc5c234ec8c0c4c68ca478a2844e3338#012Found module libqmlfolderlistmodelplugin.so with build-id: 5f886f473be ... Ich könnte das zuletzt funktionierende Backup-Image wieder einspielen und zunächst die Ursache der Konflikte ausräumen, s.o., und Repos ausmisten, bevor ich zypper patch / up durchführe (und hoffen, dass der sddm dann nicht crasht). Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten? Viele Grüße, Klaus
Am 13.09.22 um 23:30 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen, [...] Die Dateikonflikte entstehen, weil sich Pakete aus diesen Zusatzrepos "beißen". Das sollten wir zuerst reparieren:
File /usr/bin/aviocat (+ diverse andere) from install of ffmpeg-4-4.4-pm154.2.7.x86_64 (Packman Repository) conflicts with file from install of ffmpeg-3-3.4.9-pm154.1.11.x86_64 (Packman Repository)
-> zypper in ffmpeg-4 -ffmpeg-3 also ffmpeg-4 installieren und gleichzeitig ffmpeg-3 deinstallieren also das habe ich gemacht. Hatte ich in meiner letzten Mail falsch angegeben.
(und ein Bugreport an Packman wäre nett - eigentlich[tm] sollten die Pakete mindestens ein Conflicts: haben, wenn sie die gleichen Dateien ausliefern) kommt noch.
Viele Grüße, Klaus
Am 14.09.22 um 12:57 schrieb funedv@gmx.de:
... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Kannst du vielleicht einen anderen Displaymanager verwenden? Ich verwende lightdm (mit fvwm als Windowmanager, aber das sollte doch egal sein), vielleicht läuft der bei dir auch stabil. -- Viele Grüße Michael
Am 14.09.22 um 16:55 schrieb Michael Behrens:
Am 14.09.22 um 12:57 schrieb funedv@gmx.de:
... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Kannst du vielleicht einen anderen Displaymanager verwenden? Ich verwende lightdm (mit fvwm als Windowmanager, aber das sollte doch egal sein), vielleicht läuft der bei dir auch stabil.
Aktuell läuft behelfsweise lightdm. Damit könnte ich leben, wenn anydesk brauchbar wäre. Aber das läuft nur mit dem sddm, die Alternativen gdm und xdm gestatten auch kein Arbeiten mit anydesk. Viele Grüße, Klaus
Hallo Klaus, hallo zusammen, Am Mittwoch, 14. September 2022, 12:57:37 CEST schrieb funedv@gmx.de:
Am 13.09.22 um 23:30 schrieb Christian Boltz: ...
[zypper up vs. zypper patch]
zypper up installiert wohl neuere Versionen, während zypper patch wohl die Versionen beibehält, also keine Updates durchführt? Was ist denn für mich besser rsp. sicherer?
zypper up aktualisiert alle Pakete aus allen Repos. zypper patch installiert nur Patches bzw. aktualisiert die zum jeweiligen Patch gehörigen Pakete. Wenn ich schon dabei bin: zypper dup ("distribution upgrade") verhält sich ähnlich wie zypper up, erlaubt aber zusätzlich z. B. Downgrades. Das kann nötig sein, wenn in Tumbleweed mal ein kaputtes Paket zur vorherigen Version reverted wird. zypper up würde dieses "alte" Paket (kleinere Versionsnummer als das installierte Paket) nicht installieren. Für Dein Leap mit diversen Zusatzrepos wird sich "zypper up" nicht vermeiden lassen. Du kannst aber auch erstmal mit "zypper patch" nur die offiziellen Updates installieren.
Und ganz allgemein: bist Du sicher, dass Du die ganzen Zusatz-Repos wirklich brauchst?
Das System wurde seit 42.3 immer wieder mit zypper dup gemäß diversen Empehlungen hier in der Liste / opensuse-Website hochgezogen. Wenn ich Werkzeuge in den Suse-üblichen Repos nicht bekommen konnte, hab ich sie aus den Community-Repos genommen. Im Lauf der Jahre ist das ziemlich unübersichtlich geworden. Ich würde die Repos wirklich gerne ausmisten, weiß aber nicht so richtig, wie ich das systematisch und sicher durchführen kann.
Verschaffe Dir erstmal einen Überblick, welches Paket aus welchem Repo kommt: zypper se -si Pakete, bei denen in der letzten Spalte "(Systempakete)" steht, gibt es in keinem Repo mehr. Das sind Kandidaten zum Deinstallieren. Ich würde aber erstmal so viele Updates wie möglich installieren - mit etwas Glück werden ein paar der "(Systempakete)" einfach nur aktualisiert und passen dann wieder zu einem der Repos. Ach so: Repos, zu denen "zypper se -si" keine Pakete auflistet, sind überflüssig.
Leider crasht der sddm immer noch, s. /var/log/messages: ... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Wenn Du rausfindest, welches Paket Deine Probleme verursacht, schon. Ich würde die Pakete in Teilmengen updaten (z. B. immer 50 Pakete statt alle 500 auf einmal). Damit kannst Du eingrenzen, welches Paket den Crash verursacht, und dann (nach einem Restore) aus den 50 Kandidaten in kleineren Mengen (z. B. jeweils 10) die Sache weiter eingrenzen. Alternativ kannst Du auch nach Repo gruppiert updaten: zypper up -r $REPO Anfangen würde ich mit den "offiziellen" Update-Repos - zumindest theoretisch sollten die ja nix kaputtmachen ;-) Gruß Christian Boltz --
Wieso ich, ich habe 1,5 Mbit anbindung, ständig. Du? Oder dein Rechner? :-) Was meinst du wie ich nach 1,500,000 Bit aussehe, glaubst du, dann könnte ich noch schreiben, geschweige denn programmieren? [> Ratti und Gerald Goebel in fontlinge-devel]
Am 14.09.22 um 20:24 schrieb funedv@gmx.de:
Am 14.09.22 um 16:55 schrieb Michael Behrens:
Am 14.09.22 um 12:57 schrieb funedv@gmx.de:
... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Kannst du vielleicht einen anderen Displaymanager verwenden? Ich verwende lightdm (mit fvwm als Windowmanager, aber das sollte doch egal sein), vielleicht läuft der bei dir auch stabil.
Aktuell läuft behelfsweise lightdm. Damit könnte ich leben, wenn anydesk brauchbar wäre. Aber das läuft nur mit dem sddm, die Alternativen gdm und xdm gestatten auch kein Arbeiten mit anydesk.
Viele Grüße, Klaus
Hi, wenn es nur anydesk ist... versuch mal rustdesk - opensource und m.E. funktional wie teamviewer & co. Man kann sogar einen eigenen Server für die Vermittlung aufsetzen, hab ich aber noch nicht getestet. Zumindest, wenn man es nur, wie üblich, für ein bißchen "Krisenmanagement" braucht, scheint es mir recht gut... -- cu jth
Am 15.09.22 um 00:00 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Mittwoch, 14. September 2022, 12:57:37 CEST schrieb funedv@gmx.de:
Am 13.09.22 um 23:30 schrieb Christian Boltz: ...
[zypper up vs. zypper patch]
zypper up installiert wohl neuere Versionen, während zypper patch wohl die Versionen beibehält, also keine Updates durchführt? Was ist denn für mich besser rsp. sicherer?
zypper up aktualisiert alle Pakete aus allen Repos.
zypper patch installiert nur Patches bzw. aktualisiert die zum jeweiligen Patch gehörigen Pakete.
Wenn ich schon dabei bin: zypper dup ("distribution upgrade") verhält sich ähnlich wie zypper up, erlaubt aber zusätzlich z. B. Downgrades. Das kann nötig sein, wenn in Tumbleweed mal ein kaputtes Paket zur vorherigen Version reverted wird. zypper up würde dieses "alte" Paket (kleinere Versionsnummer als das installierte Paket) nicht installieren.
Für Dein Leap mit diversen Zusatzrepos wird sich "zypper up" nicht vermeiden lassen. Du kannst aber auch erstmal mit "zypper patch" nur die offiziellen Updates installieren.
[...]
Verschaffe Dir erstmal einen Überblick, welches Paket aus welchem Repo kommt: zypper se -si
Pakete, bei denen in der letzten Spalte "(Systempakete)" steht, gibt es in keinem Repo mehr. Das sind Kandidaten zum Deinstallieren.
Ich würde aber erstmal so viele Updates wie möglich installieren - mit etwas Glück werden ein paar der "(Systempakete)" einfach nur aktualisiert und passen dann wieder zu einem der Repos.
Ach so: Repos, zu denen "zypper se -si" keine Pakete auflistet, sind überflüssig.
Leider crasht der sddm immer noch, s. /var/log/messages: ... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Wenn Du rausfindest, welches Paket Deine Probleme verursacht, schon.
Ich würde die Pakete in Teilmengen updaten (z. B. immer 50 Pakete statt alle 500 auf einmal). Damit kannst Du eingrenzen, welches Paket den Crash verursacht, und dann (nach einem Restore) aus den 50 Kandidaten in kleineren Mengen (z. B. jeweils 10) die Sache weiter eingrenzen.
Alternativ kannst Du auch nach Repo gruppiert updaten: zypper up -r $REPO Anfangen würde ich mit den "offiziellen" Update-Repos - zumindest theoretisch sollten die ja nix kaputtmachen ;-)
[...] Hallo Christian, vielen Dank für Deine Tipps und Erläuterungen, das sind Informationen, die mir gefehlt haben. Die werden mir weiterhelfen. Ich bin einfach nur froh, dass es diese Liste gibt. Viele Grüße, Klaus
Am 15.09.22 um 07:30 schrieb Jörg Thümmler:
Hi,
wenn es nur anydesk ist... versuch mal rustdesk - opensource und m.E. funktional wie teamviewer & co. Man kann sogar einen eigenen Server für die Vermittlung aufsetzen, hab ich aber noch nicht getestet. Zumindest, wenn man es nur, wie üblich, für ein bißchen "Krisenmanagement" braucht, scheint es mir recht gut...
Hallo Jörg, habe grad von rustdesk gelesen, vielen Dank für den Hinweis. Ich werde das sicherlich mal ausprobieren, aber jetzt auf rustdesk umsteigen würde eine weitere Baustelle bedeuten. Ich versuche jetzt erst mal meinen Recher wieder so hinzukriegen, dass anydesk wieder gescheit läuft. Viele Grüße, Klaus
Am 15.09.22 um 00:00 schrieb Christian Boltz:
Hallo Klaus, hallo zusammen,
Am Mittwoch, 14. September 2022, 12:57:37 CEST schrieb funedv@gmx.de:
Am 13.09.22 um 23:30 schrieb Christian Boltz: ...
[zypper up vs. zypper patch]
zypper up installiert wohl neuere Versionen, während zypper patch wohl die Versionen beibehält, also keine Updates durchführt? Was ist denn für mich besser rsp. sicherer?
zypper up aktualisiert alle Pakete aus allen Repos.
zypper patch installiert nur Patches bzw. aktualisiert die zum jeweiligen Patch gehörigen Pakete.
Wenn ich schon dabei bin: zypper dup ("distribution upgrade") verhält sich ähnlich wie zypper up, erlaubt aber zusätzlich z. B. Downgrades. Das kann nötig sein, wenn in Tumbleweed mal ein kaputtes Paket zur vorherigen Version reverted wird. zypper up würde dieses "alte" Paket (kleinere Versionsnummer als das installierte Paket) nicht installieren.
Für Dein Leap mit diversen Zusatzrepos wird sich "zypper up" nicht vermeiden lassen. Du kannst aber auch erstmal mit "zypper patch" nur die offiziellen Updates installieren.
Und ganz allgemein: bist Du sicher, dass Du die ganzen Zusatz-Repos wirklich brauchst?
Das System wurde seit 42.3 immer wieder mit zypper dup gemäß diversen Empehlungen hier in der Liste / opensuse-Website hochgezogen. Wenn ich Werkzeuge in den Suse-üblichen Repos nicht bekommen konnte, hab ich sie aus den Community-Repos genommen. Im Lauf der Jahre ist das ziemlich unübersichtlich geworden. Ich würde die Repos wirklich gerne ausmisten, weiß aber nicht so richtig, wie ich das systematisch und sicher durchführen kann.
Verschaffe Dir erstmal einen Überblick, welches Paket aus welchem Repo kommt: zypper se -si
Pakete, bei denen in der letzten Spalte "(Systempakete)" steht, gibt es in keinem Repo mehr. Das sind Kandidaten zum Deinstallieren.
Ich würde aber erstmal so viele Updates wie möglich installieren - mit etwas Glück werden ein paar der "(Systempakete)" einfach nur aktualisiert und passen dann wieder zu einem der Repos.
Ach so: Repos, zu denen "zypper se -si" keine Pakete auflistet, sind überflüssig.
Leider crasht der sddm immer noch, s. /var/log/messages: ... Oder gibt es noch eine andere Möglichkeiten, die aktuelle Installation zu retten?
Wenn Du rausfindest, welches Paket Deine Probleme verursacht, schon.
Ich würde die Pakete in Teilmengen updaten (z. B. immer 50 Pakete statt alle 500 auf einmal). Damit kannst Du eingrenzen, welches Paket den Crash verursacht, und dann (nach einem Restore) aus den 50 Kandidaten in kleineren Mengen (z. B. jeweils 10) die Sache weiter eingrenzen.
Alternativ kannst Du auch nach Repo gruppiert updaten: zypper up -r $REPO Anfangen würde ich mit den "offiziellen" Update-Repos - zumindest theoretisch sollten die ja nix kaputtmachen ;-)
Gruß
Christian Boltz
Hallo Christian und alle anderen, mit den Hinweisen habe ich das Paket Mesa-dri Version 21.2.4-150400.68.6.1 (aus dem Repo "Update repository with updates from SUSE Linux Enterprise 15") als Schuldigen gefunden. Nach dem Downgrade auf 21.2.4-150400.68.3.1 funktioniert der sddm wieder. Ich habe diese Version jetzt erst mal geblockt. Dazu hatte ich mein Backup-Image eingespielt und anhand der vorherigen Zypper-Updateprotokollmitschnitte gruppenweise upgedatet. Nach den 18 Mesa-Updates funktionierte der sddm nicht mehr, also hab ich diese Updates einzeln auf die Vorversion gesetzt. Für mich bleibt nur noch die Frage, wie ich meinen historisch gewachsenen Repo-Wildwuchs wieder in den Griff kriegen kann. Herzlichen Dank an alle, die hier mitdenken. Ohne eure Kenntnisse und Tipps würde es zumindest bei mir ziemlich klemmen ... Viele Grüße, Klaus
Am 16.09.22 um 11:07 schrieb Klaus Schneider-Grosch:
mit den Hinweisen habe ich das Paket Mesa-dri Version 21.2.4-150400.68.6.1 (aus dem Repo "Update repository with updates from SUSE Linux Enterprise 15") als Schuldigen gefunden.
Nach dem Downgrade auf 21.2.4-150400.68.3.1 funktioniert der sddm wieder. Ich habe diese Version jetzt erst mal geblockt.
Dazu hatte ich mein Backup-Image eingespielt und anhand der vorherigen Zypper-Updateprotokollmitschnitte gruppenweise upgedatet. Nach den 18 Mesa-Updates funktionierte der sddm nicht mehr, also hab ich diese Updates einzeln auf die Vorversion gesetzt. [...]
Leider glimmt's nach, nachdem packagekit bereitstehende Updates meldet, die dann nicht installiert werden können: Hier das Protokoll des Versuchs, der Sache näher zu kommen, zum Schluss mit c abgebrochen: # zypper patch | tee zypper_PatchProblem.txt Loading repository data... Reading installed packages... Resolving package dependencies... 2 Problems: Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2487-1.noarch conflicts with 'python-urlgrabber.noarch < 4.1.0-150400.4.3.1' provided by the installed python-urlgrabber-3.9.1-1.37.noarch Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2967-1.noarch conflicts with 'Mesa-dri.x86_64 < 21.2.4-150400.68.6.1' provided by the installed Mesa-dri-21.2.4-150400.68.3.1.x86_64 Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2487-1.noarch conflicts with 'python-urlgrabber.noarch < 4.1.0-150400.4.3.1' provided by the installed python-urlgrabber-3.9.1-1.37.noarch Solution 1: deinstallation of python-urlgrabber-3.9.1-1.37.noarch Solution 2: do not install patch:openSUSE-SLE-15.4-2022-2487-1.noarch Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2967-1.noarch conflicts with 'Mesa-dri.x86_64 < 21.2.4-150400.68.6.1' provided by the installed Mesa-dri-21.2.4-150400.68.3.1.x86_64 Solution 1: remove lock to allow removal of Mesa-dri-21.2.4-150400.68.3.1.x86_64 Solution 2: do not install patch:openSUSE-SLE-15.4-2022-2967-1.noarch Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): Wie kann ich denn der Sache beikommen? Bei meinen anderen Systemen ist die aktuelle Version Mesa-dri-21.2.4-150400.68.6.1.x86_64 installiert und schießt den sddm nicht ab. Viele Grüße, Klaus
Hello, Am Freitag, 16. September 2022, 11:07:20 schrieb Klaus Schneider-Grosch: ...
mit den Hinweisen habe ich das Paket Mesa-dri Version 21.2.4-150400.68.6.1 (aus dem Repo "Update repository with updates from SUSE Linux Enterprise 15") als Schuldigen gefunden.
Nach dem Downgrade auf 21.2.4-150400.68.3.1 funktioniert der sddm wieder. Ich habe diese Version jetzt erst mal geblockt.
Das ist interessant[tm] - und definitiv einen Bugreport auf bugzilla.opensuse.org wert. Schreibst Du bitte einen? Ein Update sollte nie etwas kaputtmachen - auch wenn andere Repos im Spiel sind. Bei Mesa-dri könnte das Problem auch von der (Grafik-)Hardware abhängig sein.
Dazu hatte ich mein Backup-Image eingespielt und anhand der vorherigen Zypper-Updateprotokollmitschnitte gruppenweise upgedatet. Nach den 18 Mesa-Updates funktionierte der sddm nicht mehr, also hab ich diese Updates einzeln auf die Vorversion gesetzt.
Für mich bleibt nur noch die Frage, wie ich meinen historisch gewachsenen Repo-Wildwuchs wieder in den Griff kriegen kann.
Ein "Fremdpaket" nach dem anderen durchsehen und dann entscheiden, - ob Du es überhaupt brauchst - ob Du es auch aus einem offiziellen Repo beziehen kannst Hinterher siehst Du dann, ob ein paar Deiner Repos überflüssig geworden sind ;-) Zu den Konflikten aus Deiner nächsten Mail: Die kommen daher, dass Du Mesa-dri gesperrt hast - aber einer der Patches möchte es updaten. Die kurzfristige/einmalige Lösung ist, "do not install patch:..." auszuwählen. Längerfristig sollte sich der Patch auch sperren lassen. Ungetestet: zypper al -t patch openSUSE-SLE-15.4-2022-2487-1.noarch Gruß Christian Boltz -- * cboltz wonders if jjohansen already regrets calling me "a devs walking nightmare" <jjohansen> cboltz: no it still fits :P [from #apparmor]
Am 16.09.22 um 20:01 schrieb Christian Boltz:
Hello,
Am Freitag, 16. September 2022, 11:07:20 schrieb Klaus Schneider-Grosch: ...
mit den Hinweisen habe ich das Paket Mesa-dri Version 21.2.4-150400.68.6.1 (aus dem Repo "Update repository with updates from SUSE Linux Enterprise 15") als Schuldigen gefunden.
Nach dem Downgrade auf 21.2.4-150400.68.3.1 funktioniert der sddm wieder. Ich habe diese Version jetzt erst mal geblockt.
Das ist interessant[tm] - und definitiv einen Bugreport auf bugzilla.opensuse.org wert. Schreibst Du bitte einen? https://bugzilla.opensuse.org/show_bug.cgi?id=1203499
Ein Update sollte nie etwas kaputtmachen - auch wenn andere Repos im Spiel sind. Bei Mesa-dri könnte das Problem auch von der (Grafik-)Hardware abhängig sein. [...]
Für mich bleibt nur noch die Frage, wie ich meinen historisch gewachsenen Repo-Wildwuchs wieder in den Griff kriegen kann.
Ein "Fremdpaket" nach dem anderen durchsehen und dann entscheiden, - ob Du es überhaupt brauchst - ob Du es auch aus einem offiziellen Repo beziehen kannst Hab es befürchtet, dass es nur so geht. Na dann ...
Hinterher siehst Du dann, ob ein paar Deiner Repos überflüssig geworden sind ;-)
Zu den Konflikten aus Deiner nächsten Mail:
Die kommen daher, dass Du Mesa-dri gesperrt hast - aber einer der Patches möchte es updaten.
Die kurzfristige/einmalige Lösung ist, "do not install patch:..." auszuwählen.
Längerfristig sollte sich der Patch auch sperren lassen. Ungetestet: zypper al -t patch openSUSE-SLE-15.4-2022-2487-1.noarch Das tut es. Leider schert sich packagekit nicht darum und bietet solche Patches unverdrossen weiterhin an. Aktualisieren scheitert dann natürlich, sind ja gelockt. zypper patch zeigt dann, warum.
Viele Grüße, Klaus
Am 17.09.22 um 14:54 schrieb funedv@gmx.de:
Am 16.09.22 um 20:01 schrieb Christian Boltz:
Hello,
Am Freitag, 16. September 2022, 11:07:20 schrieb Klaus Schneider-Grosch: ...
mit den Hinweisen habe ich das Paket Mesa-dri Version 21.2.4-150400.68.6.1 (aus dem Repo "Update repository with updates from SUSE Linux Enterprise 15") als Schuldigen gefunden.
Nach dem Downgrade auf 21.2.4-150400.68.3.1 funktioniert der sddm wieder. Ich habe diese Version jetzt erst mal geblockt.
Das ist interessant[tm] - und definitiv einen Bugreport auf bugzilla.opensuse.org wert. Schreibst Du bitte einen? https://bugzilla.opensuse.org/show_bug.cgi?id=1203499
Hallo, mit der in Bugzilla vorgeschlagenen Lösung konnte ich den sddm updaten und die weiteren davon abhängigen Paketupdates / -Patches installieren. Alles funktioniert wieder perfekt! Herzlichen Dank an alle, die mitgeholfen haben! Viele Grüße, Klaus
participants (5)
-
Christian Boltz -
funedv＠gmx.de -
Jörg Thümmler -
Klaus Schneider-Grosch
-
Michael Behrens