Vorbemerkung:
In diesem Artikel kommen Konsolen/Terminal-Eingaben vor auch wenn viele User damit nie oder ganz selten arbeiten. Für die Fehlersuche sind sie teils absolut notwendig für alle Fehler bevor das grafische System gestartet ist, sonst sind sie für den Helfenden viel einfacher und praktischer. Es schadet also nicht sich mal mit der Eingabe in der Kommandozeile zu beschäftigen. Als reiner Anwender muss man zwar keine Befehle auswendig kennen, sollte aber in der Lage sein, die Befehle, die der Helfer übermittelt, einzugeben und die Ergebnisse hier in talk wiederzugeben.
Dazu sollte man wissen, wie man das Terminal startet, wie man die Ergebnisse kopiert und hier so einfügt, dass sie auch gut lesbar sind (alle mit dieser nicht proportionalen Schrift sind entweder Ergebnisse von Eingaben oder Pfade zu Dateien.
Eine mögliche Vorgehensweise anhand eines konkreten Beispiels.
Am 6.7. wollte ich meinen Passwortmanager aufrufen und nichts tat sich.
Wer seinen Passwortmanager nur an einer Stelle hat, sollte sich überlegen, welche Konsequenz dies bedeuten könnte.
Die üblichen Gedanken:
- Habe ich an der HW was geändert?
- Habe ich was installiert, entfernt oder irgendwelche Einstellungen geändert?
- Wurden Updates eingespielt?
- Wurde ein Prozess gestartet, der sich dann nicht melden konnte oder konnte kein Prozess gestartet werden?
Ja Updates wurden eingespielt, aber keine Änderungen HW und SW.
Um die letzte Frage zu beantworten, hilft es meist den Programmnamen im Terminal einzugeben. Wenn das nicht funktioniert, weil der Name falsch ist kommt man auf den richtigen Namen mit
- das Programm im Startmenü suchen
- über das Kontextmenü Anwendung bearbeiten aufrufen
- dort steht dann der richtige Programmnamen
am besten nichts ändern, sondern nur nach den Namen schauen.
keepassxc
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Der Prozess wurde nicht gestartet, wohl weil die Module dazu nicht gefunden wurden und es hat mit qt zu tun. qt ist ein Framework für grafische Oberflächen auf unterschiedlichen Plattformen.
Wenn man export QT_DEBUG_PLUGINS=1 in der Datei .bashrc oder .profile setzt erhält man mehr Informationen. Das sieht dann so aus:
> keepassxc
QFactoryLoader::QFactoryLoader() checking directory path "/usr/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at "/usr/plugins/platforms/libqwayland.so"
"Failed to extract plugin meta data from '/usr/plugins/platforms/libqwayland.so'"
not a plugin
QFactoryLoader::QFactoryLoader() looking at "/usr/plugins/platforms/libqxcb.so"
"Failed to extract plugin meta data from '/usr/plugins/platforms/libqxcb.so'"
not a plugin
QFactoryLoader::QFactoryLoader() checking directory path "/usr/bin/platforms" ...
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
fish: Job 1, 'keepassxc' terminated by signal SIGABRT (Abort)
Lass euch von fish nicht irritieren, das ist eine Shell wie die bash, die mir aber besser gefällt.
Die Meldungen besagen, dass im Verzeichnis /usr/plugins/platforms/ gesucht wird, aber dort die nötigen Plugins nicht zu finden sind.
root@udoo /h/fli# ls -l /usr/plugins/platforms/
insgesamt 40
-rw-r--r-- 1 root root 19000 7. Mai 18:05 libqwayland.so
-rw-r--r-- 1 root root 19000 7. Mai 18:05 libqxcb.so
Tatsächlich sind nur die beiden Module vorhanden. qt ist was Großes, ich nehme an der sucht an der falschen Stelle und suche im System nach libqxcb.so.
root@udoo /h/fli# updatedb
root@udoo /h/fli# locate libqxcb.so
/mnt/fuss12/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/mnt/fuss12/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so
/mnt/fuss12/usr/share/gcompris-qt/bin/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so
/usr/plugins/platforms/libqxcb.so
Man wird nicht immer das Vorgängersystem lokal zum Vergleich eingehängt haben, damit ist die Sache ganz klar, aber auch ohne käme man weiter.
Beim Starten wird in /usr/plugins/platforms/ gesucht, die Dateien sind jedoch auf /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/.
Jetzt könnte man die beiden libqxcb.sovergleichen, das erspare ich mir, sie sind sicher verschieden. Interessanter ist das Datum des Ordners /usr/plugins/platforms/
root@udoo /u/plugins# ls -l
insgesamt 56
drwxr-xr-x 2 root root 4096 6. Jul 20:35 egldeviceintegrations/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 generic/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 iconengines/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 imageformats/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 networkinformation/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 platforminputcontexts/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 platforms/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 platformthemes/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 printsupport/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 tls/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 wayland-decoration-client/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 wayland-graphics-integration-client/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 wayland-shell-integration/
drwxr-xr-x 2 root root 4096 6. Jul 20:35 xcbglintegrations/
Das Datum könnte mit einem Update zu tun haben. Auf /var/log/apt steht mehr dazu:
/var/log/apt/history.log
Start-Date: 2026-07-06 20:35:38
Commandline: packagekit role=‘update-packages’
Requested-By: fli (1002)
Upgrade: fet:amd64 (7.0.8-3, 7.9.0~fuss13)
Remove: fet-data:amd64 (7.0.8-3)
End-Date: 2026-07-06 20:35:49
und in
/var/log/apt/term.log
Log started: 2026-07-06 20:35:38
dpkg: fet-data: Abhängigkeitsprobleme, wird aber wie gefordert dennoch entfernt:
fet hängt ab von fet-data.
(Lese Datenbank … ^M(Lese Datenbank … 5%^M(Lese Datenbank … 10%^M(Lese Datenbank … 15%^M(Lese Datenbank … 20%^M(Lese Datenbank
Entfernen von fet-data (7.0.8-3) …
(Lese Datenbank … ^M(Lese Datenbank … 5%^M(Lese Datenbank … 10%^M(Lese Datenbank … 15%^M(Lese Datenbank … 20%^M(Lese Datenbank
Vorbereitung zum Entpacken von …/fet_7.9.0~fuss13_amd64.deb …
Entpacken von fet (7.9.0~fuss13) über (7.0.8-3) …
fet (7.9.0~fuss13) wird eingerichtet …
Trigger für desktop-file-utils (0.28-1) werden verarbeitet …
Trigger für hicolor-icon-theme (0.18-2) werden verarbeitet …
Trigger für man-db (2.13.1-1) werden verarbeitet …
Trigger für shared-mime-info (2.4-5+b2) werden verarbeitet …
Trigger für mailcap (3.74) werden verarbeitet …
Log ended: 2026-07-06 20:35:49
Was ist fet? Debian sagt dazu: FET is a program for automatically generating the timetable of a school, high-school or university.
Also etwas, was ich nicht brauche, deshalb ein Versuch diese SW zu deinstallieren.
root@udoo /u/plugins# apt remove fet
ENTFERNE:
fet fuss-office
Zusammenfassung:
Aktualisiere: 0, Installiere: 0, Entferne: 2, Aktualisiere nicht: 0
Freigegebener Platz: 12,3 kB
Fortfahren? [J/n] j
(Lese Datenbank … 650703 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von fuss-office (13.0.16) …
Entfernen von fet (7.9.0~fuss13) …
Trigger für hicolor-icon-theme (0.18-2) werden verarbeitet …
Trigger für man-db (2.13.1-1) werden verarbeitet …
Trigger für shared-mime-info (2.4-5+b2) werden verarbeitet …
Trigger für mailcap (3.74) werden verarbeitet …
Trigger für desktop-file-utils (0.28-1) werden verarbeitet …
root@udoo /u/plugins#
root@udoo /h/fli# less .bashrc
Ich weiß nicht ob sich die Standardshell (bash) auch so verhält. Vor dem Aufruf war /usr/plugins das aktuelle Verzeichnis, durch das Löschen der SW, wurde auch das Verzeichnis gelöscht und automatisch ohne Fehlermeldung auf das Standardverzeichnis umgeschaltet. Ich nehme an, dass es eine Eigenschaft der fish-Shell ist
Damit funktioniert mein Passwortmanager wieder, auch gtqr, was sich ebenfalls nicht mehr aufrufen ließ. Da es auf fuss 2 verschiedene .iso-Dateien gibt, würde ich fet eher in der education-Variante erwarten als in der basis-iso.
Auch wenn es nicht angenehm ist, wenn durch ein Update eines Programms mehrere andere nicht mehr funktionieren, hat mir das saubere rückstandsfreie Deinstallieren gefallen.
Normalerweise ist die Fehlersuche abgeschlossen, wenn man einen Grund für den Fehler findet und ihn beseitigt und damit auch das Fehlverhalten nicht mehr auftritt. Es könnten mehrere verschiedene Gründe sein oder eine Hypothese am Anfang der Fehlersuche stellt sich als falsch heraus, weil das Problem nach wie vor vorhanden ist. Das war dieses mal nicht so, weil ich selbst nichts geändert habe und deshalb war die Hypothese “es muss über die Updates” kommen, einfach. Man stelle sich vor, ich hätte in der fraglichen Zeit die Grafikkarte getauscht oder wäre von xfce auf eine andere Oberfläche umgestiegen.
Dennoch geht die Geschichte weiter.
Am Tag darauf kamen wieder Updates, die ich bisher immer zulasse ohne genauer hinzusehen, diesmal waren es Browser.
Etwas später wollte keepassxc wieder nicht starten.
Der Ordner /usr/plugins war wieder da mit Datum 9.07.2026 8:54
und in /var/log/apt/history.log:
Start-Date: 2026-07-08 15:20:08
Commandline: apt remove fet
Requested-By: fli (1002)
Remove: fet:amd64 (7.9.0~fuss13), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-08 15:20:16
Start-Date: 2026-07-09 08:54:39
Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -o DPkg::Lock::Timeout=60 ins
Install: fet:amd64 (7.9.0~fuss13, automatic), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-09 08:54:50
Mit apt remove fet wieder entfernt, damit ich zu meinen Passwörtern komme.
dann dahinter ein apt update mit dem Ergebnis, dass alle Pakete aktuell seien.
Die erneute Installation wirft schon Fragen auf:
- Wenn es Abhängigkeiten gibt, hätten sie beim Deinstallieren angezeigt werden müssen.
- Gibt es Unterschiede bezüglich Paketen, zwischen den apt-Befehlen und dem gpk-update-viewer?
An so einer Stelle lohnt es sich zu überlegen, wer alles betroffen ist und wie man Hilfe holen kann.
Auf einem weiteren fuss13 System war dasselbe Verhalten, dort stellte ich auch fest, dass qtqr, ein praktisches Programm zum QR-Handling ebenfalls nicht funktioniert. Kein Problem jedoch bei fuss12, weil dort das PET-Programm nicht installiert ist. Mir fielen dann gleich ein paar Bekannte ein, die von mir das fuss13 installiert bekamen.
Ich sammelte deshalb die nötigen Logs und übermittelte sie mit der Fehlerbeschreibung an ein LUGBZ-Mitglied der die Entwicklung von fuss koordiniert, störte ihn im Urlaub, aber damit konnte der Fehler dann endgültig beseitigt werden.
Auf /var/log/apt/history.log sieht man die automatischen Installationen und meine remove-Aktionen hier nur fet betreffend:
Start-Date: 2026-07-06 20:35:38
Commandline: packagekit role='update-packages'
Requested-By: fli (1002)
Upgrade: fet:amd64 (7.0.8-3, 7.9.0~fuss13)
Remove: fet-data:amd64 (7.0.8-3)
End-Date: 2026-07-06 20:35:49
Start-Date: 2026-07-08 15:20:08
Commandline: apt remove fet
Requested-By: fli (1002)
Remove: fet:amd64 (7.9.0~fuss13), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-08 15:20:16
Start-Date: 2026-07-09 08:54:39
Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -o DPkg:
:Timeout=60 install fuss-office=13.0.16
Install: fet:amd64 (7.9.0~fuss13, automatic), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-09 08:54:50
Start-Date: 2026-07-09 11:43:55
Commandline: apt remove fet
Requested-By: fli (1002)
Remove: fet:amd64 (7.9.0~fuss13), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-09 11:44:02
Start-Date: 2026-07-09 14:53:21
Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -o DPkg:
:Timeout=60 install fuss-office=13.0.16
Install: fet:amd64 (7.9.0~fuss13, automatic), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-09 14:53:31
Start-Date: 2026-07-09 18:49:44
Commandline: apt remove fet
Requested-By: fli (1002)
Remove: fet:amd64 (7.9.0~fuss13), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-09 18:49:52
Start-Date: 2026-07-10 09:05:34
Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -o DPkg:
:Timeout=60 install fuss-office=13.0.16
Install: fet:amd64 (7.9.1~fuss13, automatic), fuss-office:amd64 (13.0.16)
End-Date: 2026-07-10 09:05:48
Beim letzten Eintrag sieht man, dass jetzt eine neuere Version als zuvor fet:amd64 (7.9.1~fuss13, automatic) installiert wird. Diese Version legt das /usr/plugins-Verzeichnis nicht mehr an und meine beiden qt-Programme funktionieren wieder.
Ich weiß jetzt auch, dass FET gerade jetzt von den Schulen benötigt wird, um die Lehr- und Stundenpläne zu erstellen. Deshalb steht das Programm in der Default-Liste, wird also immer installiert. Man kann es entfernen, weil damit keine Abhängigkeiten verletzt werden, aber es kommt wieder.
Mir ist durch die Kommunikation mit den Fuss-Leuten so richtig bewusst worden, was für Arbeit dahinter steckt. Fuss ist viel mehr als ein gut zusammengestelltes Debian-Paket, für das ich es anfangs hielt.
Noch ein paar Hinweise für Linuxer, die ein Problem haben und Hilfe benötigen.
- Den Fehler möglicht genau beschreiben, also nicht “Programm xy funktioniert nicht” sondern möglichst genau alles dokumentieren, am besten mit Bildschirmabzügen. Dazu gehört auch die Angaben der Versionen von Programm und verwendetes Betriebsystem/Oberfläche.
- Bei Fragen zu Installationen und Konfigurationen ist es hilfreich zu beschreiben, was man tun will und oft auch, warum man es gerade so tun will.
- Wer kann, gern auch irgendwelche Einstellungen zum Programm und Logeinträge im Systemlog.
- Nicht vergessen auf Tipps zeitnah zu antworten, ggf. das Problem als gelöst definieren oder begründen warum es nicht funktionert hat mit den jeweiligen Bildschiermabzügen und Logs.