GNOME Crash beim Start

Wenn man sich von einem Anmeldemanager aus oder mit dem Kommando startx nicht mehr auf dem GNOME-Desktop anmelden kann, sondern dieser sofort wieder den X-Server abschießt und man wieder in der Shell oder auf dem Anmeldemanager landet, kann folgendes passiert sein.

In den Tiefen von /var/log/messages findet sich…

Dec 14 09:37:34 rkCSD-Laptop org.gnome.Shell.desktop[2686]: **
Dec 14 09:37:34 rkCSD-Laptop org.gnome.Shell.desktop[2686]: ERROR:/build/gnome-menus-RL_1GT/gnome-menus-3.13.3/./libmenu/gmenu-tree.c:4020:preprocess_layout_info: assertion failed: (!directory->preprocessed)
Dec 14 09:37:34 rkCSD-Laptop gnome-session[1062]: gnome-session-binary[1062]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
Dec 14 09:37:34 rkCSD-Laptop gnome-session[1062]: gnome-session-binary[1062]: WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
Dec 14 09:37:34 rkCSD-Laptop gnome-session[1062]: Unable to init server: Could not connect: Connection refused
Dec 14 09:37:34 rkCSD-Laptop kernel: [   22.429789] gnome-session-f[3380]: segfault at 0 ip 00007fea0cf34e19 sp 00007ffdde2f91d0 error 4 in libgtk-3.so.0.2200.11[7fea0cc52000+700000]

Segfault in Kombination mit libgtk-3.so liefert unterschiedliche Suchergebnisse, meist Bugs aus dem Jahr 2017. Hier ist der Knackpunkt aber die Zeile mit dem „ERROR“. Das Menü kann nicht gepart werden. In meinem Fall ist der Gnome-Desktop komplett gecrasht und zum Anmeldebildschirm gewechselt, als ich mit MenuLibre das Menü bearbeitet habe. Und so wurde das Menü offenbar beschädigt, sodass es beim Anmelden nicht mehr geladen werden kann und ein Segfault auftritt.

Dies ist natürlich ein schwerer Bug. Nur wegen dem Menü ist der Rechner nicht mehr benutzbar – wenn man nicht gerade der Konsole mächtig ist wie ich

Mit STRG+ALT+F1 kommt man übrigens auf die erste virtuelle Konsole, kann sich im Textmodus einloggen und debuggen. Hier ist dann die Lösung, im Heimatverzeichnis den Ordner .config/menus zu löschen (ggfs. auch .local/share/applications) oder umzubenennen. Dann kann man sich wieder auf dem GNOME-Desktop anmelden.

In meinem Fall, mit seeehr vielen individuell erstellten und sortierten Menüeinträgen mit liebevoll ausgesuchten Icons ist das natürlich eine Kathastophe. Die hälfte der Programme sind nicht als Paket installiert und nun nurnoch per Pfad aufrufbar.

Ich versuche nun, aus meinem Vollfestplattenbackup mit

kpartx -a pcimage_2018-08-15.img

(ohne -a listet die Partitionen; mit -a werden diese in /dev/mapper eingebunden, dort einfach mit ls checken)

dann (für verschlüsselte Partitionen)

cryptsetup luksOpen /dev/mapper/loop1p5 backup

und

mount /dev/mapper/backup /mnt/backup/

die entsprechenden Dateien wiederherzustellen.¹⁾

Wenn dann mount: unknown filesystem type 'LVM2_member' kommt muss man halt weiter fummeln ^^ (siehe Abschnitt ganz unten) Siehe auch Verschlüsseltes Debian (LVM+cryptsetup) auf größere Festplatte umziehen

Bei so einem Fehler die Dateien zu finden, die man löschen muss, ist schwer. Im Netz findet man häuft den Ratschlag, Pakete neu zu installieren, aber das ist eher etwas was unter Windows hilft. Wieso sollte ohne ein vorher vorgenommenes Software-Update hier etwas nicht mehr funktionieren? Die Pakete haben sich ja nicht geändert, bzw. können es nicht haben, wohl aber die Config. Die wird bei Neuinstallation i.d.R. aber nicht gelöscht.

Also nicht gleich den PC neu aufsetzen sondern Logs lesen und Startpagen (NICHT Googlen, wenn es nicht unbedingt sein muss ).

Den besten Hinweis zu diesem Thema habe ich hier gefunden: https://marius.bloggt-in-braunschweig.de/2017/06/03/gdm-crasht-im-endlosloop/ (14. Dezember 2018, 15 Uhr CEST)

Ansonsten hätte ich mir meine Arbeitsverzeichnisse aus dem Heimatordner und anderen Pfaden gesichert, die Festplatte mit oben genanntem Vollbackup überschrieben und die entsprechenden Daten zurückkopiert. Wesentlich Produktiver als Tagelang alles neu einzurichten. Backup rulez!

Zum Fummeln – ich bin mit einer Kombit der Befehle oben und denen hier weiter gekommen, vor allem fdisk auf das Image ist richtig cool

losetup --all

file backup-cloud.img

fdisk -l backup-cloud.img

losetup /dev/loop0 backup-cloud.img

pvs

vgchange -a y vg

mount -o ro /dev/vg/lv_root /mnt/old/

umount /mnt/old/

vgchange -a n vg

losetup -d /dev/loop0

Quelle: http://www.utilities-online.info/articles/Mount-an-LVM-partition-image-cloned-with-dd/ (14. Dezember 2018, 23:22 Uhr CEST)

Am Ende war nicht nur die GUI sondern auch mein Menü wieder da ganz ohne Neuinstallation, Tage gespart durch Intelligenz (Eigenlob stinkt, ich weiß… aber trotzdem!)

Und mit MenuLibre wieder eine Verküpfung angelegt, und… REPRODUZIERBAR! Schließt man MenuLibre und klickt ins Menü stürzt alles ab und alles kann wieder von vorne losgehen, oh mann. Aber jetzt weiß ich ja, wie's gefixt wird. Komischerweise war nach dem erneuten Löschen des .config/menu Verzeichnisses diesmal nix weg, auch nicht die neue Verknüpfung. Also doch lieber nicht .local/share/applications löschen? Jetzt gehts auf jeden Fall wieder. Aber ich unterstelle mal, es lag daran, dass ich ausgerechnet für TeamViewer 14 eine verknüpfung angelegt habe. Siehe verlinkter Artikel. Denn diese Software und ich haben eine besondere Beziehung zueinander.