ich habe hier einen merkwürdigen Fehler, wo ich momentan nicht weiß, wo ich an mehr Informationen komme um herauszufinden woran es liegt:
Auf 2 Rechnern habe ich von OpenSUSE 13.1 auf 13.2 geupgraded. Vorgehensweise jeweils gleich: Alle Repos deaktiviert, 13.2er hinzugefügt und dann mit zypper dup auf neue Version aktualisiert. Soweit, so gut … funktioniert im prinzip fast alles. Wenn ich aber in Dolphin in USB Datenträger mounten möchte, bekomme ich nur die Meldung “Folgendes Gerät kann nicht eingebunden werden: …” und wenn ich die Details aufklappe, steht dort “An unspecified error has occoured: Not authorized to perform operation”.
Google spuckt zwar was aus, aber nichts was mich bis dato auf das Problem gestoßen hätte.
Was habe ich bis dato gemacht?
Benutzer mal in die Gruppen disk und cdrom gesteckt, kein Erfolg
Mit udisk mal versucht direkt unter dem Benutzer zu mounten:
manuel@sheldon:~> udisksctl mount -b /dev/sdc1
==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-mount-other-seat ===
Legitmierung ist zum Einhängen von ZALMAN External HDD (/dev/sdc1) notwendig
Authenticating as: root
Password:
-> Hier sollte doch eigentlich keine Kennwortabfrage kommen oder?
udisk in Version 1 (war nur udisk2 installiert) nach installiert
plasma-desktop gekillt, neu gestartet und die Logs angesehen. Vorher mit kdebugdialog das Debugging aktiviert. Leider keine hilfreichen Meldungen gefunden.
dolphin mit strace -o out.txt -f dolphin gestartet, aber leider nichts in der out.txt gefunden was helfen könnte, den Fehler einzugrenzen.
polkit nochmal mit zypper in -f neu installiert, vorher vorhandene Dateien weg gesichert - kein Erfolg
Irgendwie ist das für mich momentan ein Stochern im dunkeln. Wenn ich via kdesu dolphin aufrufe, kann ich einen Datenträger mounten. Das Problem tritt wie gesagt auf 2 Rechnern identisch auf, von pieke auf Neu habe ich einen Rechner mit 13.2 noch nicht aufgesetzt (DVD ISO lädt noch), kann also noch nichts dazu sagen ob es da auch auftritt.
Ansonsten was ich auch noch beobachtet habe: Bei beiden Rechnern ging nach dem Upgrade erst mal der Sound nicht. Musste die Benutzer auch erst wieder in die richtigen Gruppen mitaufnehmen und hab die Soundkarte einfach gelöscht und neu eingerichtet.
Ich hab den Eindruck, dass hier irgendwo etwas anders läuft mit den Berechtigungen als bei 13.1 und das jetzt Probleme bereitet.
Klar. KDE benutzt udisks2, die Rechteverwaltung läuft über polkit, damit eben auch normale Benutzer Datenträger mounten können.
Mit udisk mal versucht direkt unter dem Benutzer zu mounten:
manuel@sheldon:~> udisksctl mount -b /dev/sdc1
==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-mount-other-seat ===
Legitmierung ist zum Einhängen von ZALMAN External HDD (/dev/sdc1) notwendig
Authenticating as: root
Password:
-> Hier sollte doch eigentlich keine Kennwortabfrage kommen oder?
Tja, für die Aktion “org.freedesktop.udisks2.filesystem-mount-other-seat” ist eben standardmäßig das Root-Passwort erforderlich.
Ändern könntest du das in /etc/polkit-default-privs.local, aber das würde nur das Symptom bekämpfen, nicht die Ursache. Sh. unten.
udisk in Version 1 (war nur udisk2 installiert) nach installiert
udisks 1 wird von KDE schon seit openSUSE 12.2 nicht mehr verwendet.
Außerdem hat das ähnliche polkit-Regeln.
plasma-desktop gekillt, neu gestartet und die Logs angesehen. Vorher mit kdebugdialog das Debugging aktiviert. Leider keine hilfreichen Meldungen gefunden.
dolphin mit strace -o out.txt -f dolphin gestartet, aber leider nichts in der out.txt gefunden was helfen könnte, den Fehler einzugrenzen.
polkit nochmal mit zypper in -f neu installiert, vorher vorhandene Dateien weg gesichert - kein Erfolg
Das Problem liegt weder bei dolphin/Plasma/KDE, noch bei udisks2, und auch nicht bei polkit.
Das Problem ist, dass deine Benutzersitzung nicht als “aktiv” auf dem lokalen Arbeitsplatz registriert wird. Deswegen auch das “org.freedesktop.udisks2.filesystem-mount-other-seat”, und die fehlenden Zugriffsrechte auf die Soundkarte (die könntest du damit umgehen dass du deinen Benutzer der Gruppe “audio” zuweist, aber auch das behebt nur ein Symptom).
Ich hab den Eindruck, dass hier irgendwo etwas anders läuft mit den Berechtigungen als bei 13.1 und das jetzt Probleme bereitet.
Nein, das läuft alles gleich wie bei 13.1, aber irgendwas läuft leider schief bei dir beim Einloggen so wies scheint…
Ok, an die Fehlersuche:
Was bekommst du, wenn du “loginctl” in KDE als Benutzer in einem Terminalfenster aufrufst?
Wie logst du eigentlich ein? Standard-Boot in den grafischen Modus oder irgendwie anders, z.B. mit “startx” vom Textmodus?
Probier mal plymouth den Boot-Splash zu deaktivieren. Dazu “plymouth.enable=0” zu den Boot-Optionen hinzufügen. Ich hab schon erlebt das der sowas verursacht (in 12.3).
Habe loginctl ausgeführt und gesehen, dass nur der Zugang angezeigt wurde meiner Frau, die parallel mit einer X-Sitzung angemeldet war. Rechner neu gestartet, zuerst meine Frau angemeldet und dann mich und siehe da: Mein Zugang wurde angezeigt, nicht aber der meiner Frau. Natürlich war es so, dass jeweils der Zugang der in der Liste auftauchte, auch externe Datenträger einbinden konnte.
Nächster Versuch: Einfach nur Ab- und wieder Anmelden und auch da ging dann das Einbinden der Datenträger.
Allem anschein nach läuft hier irgendwo etwas bei der aller ersten Anmeldung, egal welcher Benutzer das ist, schief. Anmelden tun wir uns via kdm.
Boot-Splash zu deaktivieren hat in meinem Fall keine Veränderung bewirkt.
Was mir noch aufgefallen ist: Die erste Anmeldung in KDE dauert recht lange. D.h. vom Zeitpunkt Anmeldung bis erscheinen Splash-Screen dauert es einige Sekunden bevor was passiert. Bei allen anderen Anmeldungen im Anschluss ist das nicht mehr der Fall.
Hm. Ich hab da irgendwie einen anderen ähnlichen Thread im Hinterkopf. Allerdings kann ich mich nicht mehr an alle Details erinnern.
Benutzt du den nvidia Treiber?
Im Recovery Mode wird das Problem wahrscheinlich nicht auftreten, oder?
Boot-Splash zu deaktivieren hat in meinem Fall keine Veränderung bewirkt.
Normalerweise wurde so ein Problem früher mal von plymouth verursacht, meistens beim Booten in den Textmodus und späterem starten von kdm.
Das sollte aber an sich sowieso schon seit 1½ Jahren behoben sein…
Was mir noch aufgefallen ist: Die erste Anmeldung in KDE dauert recht lange. D.h. vom Zeitpunkt Anmeldung bis erscheinen Splash-Screen dauert es einige Sekunden bevor was passiert. Bei allen anderen Anmeldungen im Anschluss ist das nicht mehr der Fall.
Tja, das kann normal sein.
Beim Booten/ersten Anmelden muss erst mal alles von der Festplatte geladen werden (also die Programmdateien und Bibliotheken), danach sind sie bereits in den Caches und Buffern, deshalb gehts schneller.
Könnte aber natürlich auch auf eine Problem hinweisen. Zum Beispiel dbus Timeout (30s) wenn kdm die Sitzung bei logind registrieren will. (würde erklären, warum sie dann nicht registriert ist).
Hast du irgendwelche Fehlermeldungen in /var/log/kdm.log bzw. ~/.xsession-errors-:0 nach dieser ersten Anmeldung?
Poste sie evtl., aber bitte während du noch angemeldet bist und die Probleme hast. Speziell ~/.xsession-errors-:0 wird nämlich jedesmal neu angelegt.
(die Dateien am besten auf eine Sharing/Pasting Seite wie z.B. http://susepaste.org hochladen und einen Link posten)
Das eine System hat eine NVIDIA Grafikkarte, das andere eine Intel Grafikkarte.
Leider doch!
Ich gehe ehrlich gesagt davon aus, dass die Verzögerung von irgendwelchen Timeouts kommt. Zum einem ist in dem System eine SSD verbaut, weshalb es hier nicht mehr unbedingt einen Flaschenhals geben sollte, zum anderem lief das vorher mit 13.1 ohne Hänger.
In der kdm.log finden sich Fehlermeldungen zum D-Bus, in der .xsessione-errors finden sich ebenfalls einige (die ich wohl vor lauter lauter zuerst übersehen haben muss). Ehrlich gesagt für mich spanische Dörfer, wie das alles zusammenhängt …
Ja, war ich. Meine Überlegung war, das es auf 2 Systemen unabhängig voneinander auftritt, dass es irgendwo ein Bug im Upgradeprozess sein muss.
Da seh ich jetzt eigentlich nichts Ungewöhnliches drin, dass so ein Problem auslösen könnte.
Ja, war ich. Meine Überlegung war, das es auf 2 Systemen unabhängig voneinander auftritt, dass es irgendwo ein Bug im Upgradeprozess sein muss.
Naja, ich hab hier 2 Systeme mit zypper dup upgegradet, hab aber ein solches Problem auf keinen von beiden…
Ehrlich gesagt, weiß ich jetzt auch nicht so recht, worans liegen könnte. Ein Installationsproblem (fehlende Pakete oder ähnliches) kann man wohl ausschließen, weil ja beim 2. Login alles passt.
Scheint also irgendein Timing-Problem beim Booten/Login zu sein
Vielleicht läuft irgendein Dienst noch nicht richtig wenn kdm gestartet wird oder du dich einloggst.
Gibt “sudo systemctl status display-manager” irgendwelche interessante Ausgaben?
Evtl. die Ausgabe nach dem ersten Einloggen und dem zweiten vergleichen…
Kannst du vielleicht mal einen anderen Login Manager ausprobieren?
In der Distribution sind z.B. noch sddm (der neue “offizielle” DM von Plasma 5), lightdm oder gdm enthalten. Einfach das entsprechende Paket installieren und dann die Variable “DISPLAYMANAGER” in /etc/sysconfig/displaymanager entsprechend setzen.
Oder setz die einfach mal auf DISPLAYMANAGER=“xdm”, der sollte sowieso bereits installiert sein.
Wär interessant ob dann das Problem auch auftritt, oder obs eher kdm spezifisch ist.
Ich habe auf mehreren Rechnern das gleiche Problem. Kein USB einbinden, kein Sound u.a.
Die Rechner starten automatisch in KDE direkt rein. Dies habe ich nun mal abgeschaltet, kurz mit dem Einloggen gewartet und siehe da, alles funktioniert.
Scheinbar ist hier irgendwas zu schnell.
Getestet: Warte ich etwas, wird tatsächlich alles korrekt initialisiert. Macht aber keinen Unterschied, welchen Display Manager ich nehme, ist immer das gleiche Problem.
Edit:
Also es gibt einen sichtbaren Unterschied zwischen den Systemen, wo es geht und wo es nicht geht. Ich hab mal ein ps -ef ausgeführt und auf das Wort “bus” gegreped. Dabei gibt es sichtbare Unterschiede.
Liegt hier vielleicht der Hase im Pfeffer begraben?
Edit 2: Mal ibus auf dem funktionierenden System installiert. Geht immer noch alles. Liegt es vielleicht daran, dass die nicht funktionierenden Systeme SSDs haben und zu schnell sind und das nicht funktionierende eine “normale” Festplatte?
Es gibt da nämlich momentan einen Konflikt zwischen ibus-gtk3 und dem kimpanel Plasmoid aus plasma-addons (ein Update ist bereits unterwegs).
Probier mal ibus oder plasma-addons zu deinstallieren.
Wenn du dich dafür entscheidest, ibus rauszuschmeißen, wirst du libibus behalten müssen, aber das sollte kein Problem verursachen.
Aber ibus, ibus-qt, ibus-gtk3 und so weiter müssen weg.
PS: Das Update für plasma-addons ist eigentlich schon erschienen.
Vielleicht hat das die Sache sogar verschlimmert? Oder du hast es noch nicht installiert?
rpm -q plasma-addons
Oder dein Problem ist vielleicht auch einfach nur von ibus verursacht. Probier also trotzdem mal das zu deinstallieren…
Mal auf dem Lenovo Rechner alles deinstalliert von IBus. Die Anzahl der Prozesse mit dem Begriff “bus” ist jetzt gleich, der Aufruf von dbus-launch unterscheidet sich aber auf den Systemen.
Ansonsten nach wie vor das gleiche Problem. Plasma Addons sind auf beiden Systemen (funktionierend und nicht funktionierend installiert)
Ich hab den hier genauso, also wie auf deinem funktionierenden System. Und ich hab das Problem ja auch nicht.
Ob vielleicht das das Problem ist?
Hm. Ich hab momentan keine Ahnung wo der gestartet wird. Muss ich mal suchen.
Der gpg-agent ist jedenfalls Teil des Pakets gpg2.
Hast du eigentlich schon mal einen neuen Benutzer probiert?
Vielleicht ists ja doch was Benutzerspezifisches, auch wenns bei beiden auftritt.
Plasma Addons sind auf beiden Systemen (funktionierend und nicht funktionierend installiert)
Genau das meinte ich! Hab gestern schon mit fgrep das System durchforstet, ob ich den Aufruf irgendwo finde, aber habe nicht finden können. Ich nehme an, das wird dynamisch bei jedem Start irgendwo irgendwie zusammengebaut.
Werde ich heute Abend mal ausprobieren, wenn ich wieder an den Rechnern sitze.
Es wird von den X startup Scrips in /etc/X11/xdm gestartet. Genau: /etc/X11/xdm/sys.xsession
Werde ich heute Abend mal ausprobieren, wenn ich wieder an den Rechnern sitze.
Ja bitte.
Aber fassen wir nochmal das Problem zusammen: So wie’s ausschaut, startet der display-manager zu früh, bzw. ein notwendiger Dienst braucht zu lange und ist noch nicht bereit wenn der display-manager startet. Deswegen passt alles beim zweiten Login oder wenn du mit dem ersten Login wartest.
Also liegt der Grund wahrscheinlich gar nicht wirklich an den Prozessen die dann als Benutzer gestartet werden, sondern einfach daran dass zu diesem Zeitpunkt was anderes noch nicht bereit/gestartet ist.
Kann jetzt daran liegen, dass dem display-manager eine Abhängigkeit fehlt (er sollte mit dem Starten warten), oder dass da wo anders ein Problem ist (das langsamen Start/Hänger des anderen Dienstes verursacht).
Kannst du vielleicht auch mal /var/log/boot.log posten (vom funktionierenden und vom nicht-funktionierenden System)? Vielleicht sieht man da ja was. Zumindest die Dienste die nach dem display-manager starten wären interessant denke ich (also die Zeilen nach “Starting X Display Manager…”).
Übrigens, ich hab jetzt bei mir Auto-Login aktiviert, und hab das Problem immer noch nicht.
Vielleicht braucht mein Rechner aber auch einfach zu lang zum Booten. Werde wohl mal probeweise Apache und mysql deaktivieren, die brauchen die längste Zeit…
