• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]Tumbleweed: nach Kernelupdate keine Anmeldung an KDE

mojo

Member
Hallo,

vorhanden sind Acer 1810TZ (Intel Pentium SU4100 1.3GHz, 2GB RAM, 250GB HDD, Intel GMA 4500MHD) und Opensuse 11.4 (kein Upgrade, wurde neu installiert).

Da es von Anfang an Probleme mit Maus und Touchpad gab (System fror regelmäßig ein), habe ich das Tumbleweed-Repo eingebunden.

Beim letzten Update wurde der Kernel 3.0.0-39-desktop eingespielt.

Seitdem ist keine Anmeldung an KDE (4.6.5) mehr möglich!
Auch nicht im KDE failsafe oder gar an XFCE!
Die Umbenennung von /.kde hat auch nicht geholfen.


Nachfolgende Symptome treten auf:

Mit den bisher eingerichteten Usern:
1. User gelangt zum Anmeldebildschirm.
2. Nach Eingabe des Passwort erscheint kurz ein schwarzer Bildschirm und danach wieder die Eingabemaske.
3. Änderungen bei "Sitzungsart" bringen das gleiche Ergebnis.
4. Anmeldung an der Konsole funktioniert!
5. Eingabe von "startx" funktioniert nicht. Fehlermeldung:
xauth:file /home/username/.serverauth.3604 does not exist
Fatal server error: Cannot move old log file /var/logXorg.0.log to /var/log/Xorg.0.log.old


Anmeldung als root:
1., 2., 3. und 4. wie bei den "bisher eingerichteten Usern"
Aber bei Eingabe von startx startet KDE!

Anmeldung als neuer User, der nachdem Kernelupdate eingerichtet wurde:
Anmeldung funktioniert einwandfrei!!!


Bevor ich jetzt irgendwie planlos an den Zugriffsrechten von Xorg.0.log rumschraube (und gar nicht glaube, dass es daran liegt, da root sich ja auch nicht am Anmeldebildschirm anmelden kann), wollte ich lieber vorher mal fragen, woran es denn wirklich liegen könnte. Anmeldungmanager oder sowas in der Art?

mojo
 

josef-wien

Ultimate Guru
mojo schrieb:
Eingabe von "startx" funktioniert nicht.
Die Ausführung dieses Befehls ist normalen Benutzern standardmäßig nicht mehr möglich (siehe release notes).

Die Aussagen
mojo schrieb:
Auch nicht im KDE failsafe oder gar an XFCE!
Die Umbenennung von /.kde hat auch nicht geholfen.
(ich nehme an, Du meintest .kde4) und
mojo schrieb:
Anmeldung als neuer User, der nachdem Kernelupdate eingerichtet wurde:
Anmeldung funktioniert einwandfrei!!!
deuten darauf hin, daß es weder mit KDE-4/XFCE noch mit KDM zu tun hat, sondern mit irgendwelchen Eintragungen im Home-Verzeichnis des Benutzers, aber dazu paßt wieder nicht, daß startx bei root funktioniert. Steht bei den letzten Eintragungen in /var/log/kdm.log oder nach einem mißlungenen und unmittelbar darauf gelungenen Einstieg in /var/log/Xorg.0.log.old etwas Auffälliges?
 

/dev/null

Moderator
Teammitglied
Ich wollte eigentlich ganz still sein ....
... zumal im Forum zu diesem Thema einfach nichts zu lesen war.

Mir passierte genau das beschriebene vor einer Woche.
Nach einem Update konnte ich mich nicht mehr als User anmelden.
- Bei allen anderen eingerichteten Usern ging die Anmeldung problemlos!
- Nur bei dem Konte, aus dem ich per Yast das Update gemacht habe, war kein Anmelden mehr möglich.
- Neu angelegte Konten hatten dieses Problem auch nicht.
[Meine "Lösung" folgt weiter unten.]

Einen Tag später rief mich mein Sohn (User "harley") an, und teilte mir mit, dass er sich nach einem Update nicht mehr anmelden könne ... .
Und schon waren wir zu zweit.
Ansteckung und Vererbung schließe ich mal aus.

Jetzt wollte ich es wissen!
Der Desktop-PC lief ja wieder (WAF ...). Also beim Notebook ebenfalls mutig das Update gemacht => Und schon hatten drei Rechner das gleiche Problem.


Hier meine Krückenlösung:
init 3
mv /home/peter /home/peter_old
useradd peter ...
Schrittweise (mit ständiger An- und Abmeldung) fast alles außer .kde4 ins Profil reinkopiert (da trat der Fehler wieder auf!)
Desktop neu eingerichtet, fertig

Was es war, weiß ich auch heute noch nicht.
Aber Fakt ist, da war was ....

Den Kernel schließe ich "gefühslmäßig" aus.
Und Tumbleweed nutze ich auch schon, seit es diesen gibt.
Leider schreibe ich mir nicht auf, was alles geupdated wurde (macht das etwa jemand?).

MfG Peter
 

harley

Hacker
Dann gebe ich auch noch meine fünf cent dazu.

Einstellungen im Ordner .kde4 kann ich ausschließen. Ich bin den selben Weg gegangen wie Peter:
  • init 3
  • altes home/xxx sichern -> home/xxx_old
  • Benutzer löschen
  • Benutzer neu anlegen mit gleicher uid -> neues home/xxx mit Standartwerten
  • einmal gestartet (init 5): funktioniert -> Standartwerte für kde
  • Daten von home/xxx_old nach home/xxx kopiert
  • (auch .kde4)
  • Mein System ist wieder online - un die Einstellungen sind auch wieder da.

Das Spiel habe ich mehrfach versucht. Was genau nun den Start blockiert hat, kann ich aber nicht sagen. Es lag aber anscheinend nicht nur an KDE, da ich auch auf andere (XFCE etc.) nicht kam.

Micha :-D
 

Atalanta

Newbie
Hallo Leute.

Hatte ebenfalls dieses Problem nach dem Kernel-Update aus dem Tumbleweed-Repro.
Dieses Problem trat erst nach dem Umstieg auf Kernel 3.0.0-39-default auf.
Wie von euch schon beschrieben, wählte ich nach allen Versuchen die Neuinstallation
und ließ ein Update aus dem Tumbleweed-Repro aus.

Gruß Atalanta
 

/dev/null

Moderator
Teammitglied
Wie von euch schon beschrieben, wählte ich nach allen Versuchen die Neuinstallation

Weder ich noch harley haben eine Neuinstallation gemacht. Warum auch?
Wir haben lediglich den Benutzer, über den das Update erfolgte, neu angelegt.
Wie josef-wien schon schrieb, hat es da irgendwas am Userprofil verbogen bei dem Update. Sonst gibt es wirklich keine Probleme, weder mit dem neuen Kernel, noch mit Tumbleweed.

MfG Peter
 

Atalanta

Newbie
Hallo /dev/null,

Ich habe nur meine Version der Problemlösung in den Raum geworfen.
Schließe natürlich andere Lösungen nicht aus.
Habe durch eure Lösungsansätze wieder was dazu gelernt.


Gruß Atalanta
 

/dev/null

Moderator
Teammitglied
Das war auch keinesfalls "böse" gemeint.
Wir wissen ja, dass die Nutzer des "alternativen Betriebssystems" des öfteren ihr System platt machen "müssen". Im Unterschied dazu ist es bei uns üblich, den Fehler zu finden und zu beseitigen. Manche Systeme laufen Jahrelang ... .

Sicherlich hätten wir auch irgendwann den nachweislich durch das Update verursachten Fehler gefunden. Aber zum einen bin ich nicht derjenige, der dieses aus dem Ärmel schüttelt, und zum anderen habe ich ja schon den WAF erwähnt. Und wir sind froh, dass unsere Frauen Linux nutzen. Und da spielen auch die Stunden oder gar Tage der Funktionslosigkeit eine Rolle ... .
Aber auch mit einer rabiaten Krückenlösung kann man Linux reparieren ;-)


MfG Peter
 

Atalanta

Newbie
Hallo Peter,

Danke für deine Antwort. Ich habe mit SUSE Linux 9.3 angefangen und ich bin ein Fan von openSUSE.
Nomalerweise versuche ich immer eine Lösung zufinden, doch ich fand einfach keinen vernünfigen Ansatz.
Als letztes führte ich das Kernel-Update durch, danach kein Login möglich. Habe diesen Fehler noch nicht
gehabt.
Die Neuinstallation war eine Notlösung, denn ich erweitere gerne mein Wissen.
Sorry, wenn meine Antwort zu agressiv rüber kam.

Gruß Sandra
 
Hi,

auch bei mir gab es Probleme nach dem Update.
Ich habe dann versucht in runlevel 5 zu kommen indem ich der Reihe nach Konfigurationsdateien aus meinem Homeverzeichnis in ein Backupverzeichnis verschoben habe.
Letztendlich bestand die Lösung bei mir darin, das die Datei ~/.dmrc einen anderen Inhalt benötigte.
Von:
[Desktop]
Session=failsafe
auf:
[Desktop]
Session=default

Hoffe es hilft, bei mir ist wieder alles 1a.
 

/dev/null

Moderator
Teammitglied
Hallo Rincewind_Zaubberer,

du bist wirklich ein Zauberer! Toller erster Beitrag hier im Forum!
Ja, in meinen (neuen) Datei steht auch "default" drin.
Damit hätte ich mir zumindest die Neueinrichtung des KDE mit sämtlichen KDE-Programmen ersparen können. Aber ich hatte nicht die Geduld dazu (ja, der WAF ...).

MfG Peter
 
OP
M

mojo

Member
Hi,

ich habe nun auch eine Lösung gefunden (das Problem hat mir einfach keine Ruhe gelassen).

Nach erneutem "Googeln" bin ich auf Beitrag Nr. 9 in folgendem Link gestoßen:
http://forums.opensuse.org/english/...eed/463672-cant-login-kde-x64-tumbleweed.html

Mit Yast habe ich dann mal nachgeschaut, welche Version der libassuan bei mir installiert ist. Und siehe da: es war noch die alte Version - nicht die neue Version aus dem Tumbleweed-Repo (warum auch immer die nicht beim Update mitinstalliert wurde). Die Versionsnummer kann ich gerade nicht nachschauen, da ich nicht an besagtem Rechner sitze.

Also diese lib aus dem Tumbleweed-Repo eingespielt, Neustart und.... voila: ich kann mich wieder mit den "alten" Usern in KDE anmelden.

mojo

PS: mich wundert nur, dass es hier verschiedene Lösungen gibt, um das Problem zu beseitigen.
 

harley

Hacker
mojo schrieb:
PS: mich wundert nur, dass es hier verschiedene Lösungen gibt, um das Problem zu beseitigen.

Ja, viele Wege ...
Dein Tipp ist interessant. Bei mir ist die Datei ebenfalls nicht auf dem neuesten Stand. Ich schaue mir das gleich mal an.
Micha :-D

@Rincewind
Willkommen im Forum. Ich denke mal, daß dies - im Gegensatz zu den Befähigungen Deines Namensvetter - nicht nur ein zufälliger Glücksgriff gewesen war. Danke.
 

harley

Hacker
Die genannte Bibliothek dürfte eigentlich keine Auswirkungen auf das System allgemein haben. Sie wird von GnuPG zur Kommunikation zwischen Prozessen verwendet. Ansonsten sollte sie gar nicht aufgerufen werden. Aber wer weiß ...

Micha :-D

Nachtrag:

Ich habe meinen großen Rechner gestern auf den neuesten Stand gebracht. Aufgrund meiner Erfahrungen in init 3 als root auf der Konsole. Mit dem Ergebnis, daß ich als normaler Benutzer ohne Probleme auf die graphische Oberfläche komme - nicht aber als root. Ich bleibe immer im kdm hängen. Die Einstellung in der /root/.dmrc stand auf default. Also keine Möglichkeit. Bleibt noch die Aktualisierung der libassuan0. Diese brachte ebenfalls keine Lösung. Root darf nicht graphisch spielen.

Nun stört mich das keineswegs, da root eh lieber die Konsole nimmt. Mal sehen, ob es noch eine Lösung geben wird. Bestimmt werde ich jetzt nicht testen, ob ich root löschen und neu anlegen kann ;-) Aber als normaler User kann ich graphisch arbeiten und das reicht erst mal. Wahrscheinlich wird das so ein "Einzelfall" bleiben, der nie wirklich geklärt wird.
 

josef-wien

Ultimate Guru
Was ergibt:
Code:
egrep "ROOT_LOGIN_LOCAL=|SHUTDOWN=" /etc/sysconfig/displaymanager
grep PERMISSION_SECURITY= /etc/sysconfig/security
 

harley

Hacker
Code:
Rechner1:~ # egrep "ROOT_LOGIN_LOCAL=|SHUTDOWN=" /etc/sysconfig/displaymanager
DISPLAYMANAGER_ROOT_LOGIN_LOCAL="yes"
DISPLAYMANAGER_SHUTDOWN="auto"
Rechner1:~ # grep PERMISSION_SECURITY= /etc/sysconfig/security
PERMISSION_SECURITY="easy local"
 
Hallo,

ich habe wegen der libassuan mal nachgesehen. Meine Version ist 2.0.2-4.1aus Tumbleweed. Die hatte ich auch schon drauf, als das Problem noch bestand.

in /var/log/messages habe ich noch folgendes gefunden, obwohl apparmor nicht geladen ist.
Aug 8 22:48:51 name kernel: [ 20.108539] type=1400 audit(1312836531.737:2): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=1674 comm="kdm"
Aug 8 22:48:51 name kernel: [ 20.108553] type=1400 audit(1312836531.737:3): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=1674 comm="kdm"

name:~ # rcapparmor status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode :
0 processes are in complain mode.
0 processes are unconfined but have a profile defined

Keine Ahnung ob das mehr verwirrt oder hilft.


Und noch etwas ist mir in /var/log/messages aufgefallen, als KDM nicht starten wollte:
Aug 8 22:44:52 name kdm[28453]: Cannot create/lock pid file /var/run/kdm.pid

Mehr kann ich Euch zu dem Thema leider nicht bieten. Wenn jemand raus bekommt, woran es genau lag, interessiert mich das zwar, aber im Moment bin ich einfach nur froh, das alles funktioniert.

Danke an all die Aktiven hier im Forum, die eine oder andere Antwort hat mir in der Vergangenheit auch schon gut geholfen und mit meinem kleinen Beitrag wollte ich einfach nur mal was zurück geben.

Viel Erfolg noch denen, die immer noch mit dem Fehler zu kämpfen haben.

Grüße,
Rincewind

P.S.: nicht wundern, meinen hostnamen habe ich in den logs durch name ersetzt :)
 

josef-wien

Ultimate Guru
harley schrieb:
DISPLAYMANAGER_ROOT_LOGIN_LOCAL="yes"
DISPLAYMANAGER_SHUTDOWN="auto"
PERMISSION_SECURITY="easy local"
Damit sollte es funktionieren, aber vielleicht hat KDE-4 zusätzliche Einstellmöglichkeiten?

Rincewind_Zaubberer schrieb:
Aug 8 22:44:52 name kdm[28453]: Cannot create/lock pid file /var/run/kdm.pid
Das wäre ein Ansatzpunkt, wenn der Grund dabei stünde (was z. B. bei einem bereits laufenden display manager der Fall ist), aber dieses "ätsch, geht nicht" nützt nichts.
 
Hallo mojo,
mojo schrieb:
Wollte mal das Ergebnis mitteilen ;) :
Nach Aktualisierung der libassuan gab/gibt es bis jetzt keine Probleme mit der Anmeldung.
Das Thema dieses Thread hat meinen Desktop-PC am Montag (15.08.2011) Mittag heimgesucht, ich war auf Montage und meine Tochter startete den Computer neu um Windows zu booten, danach kamen wohl die vergangenen Updates zum tragen.
Mein PC ist nahezu ohne Unterbrechung an und deshalb habe ich das nicht sofort gemerkt.

Zuerst dachte ich das es an der Passworteingabe liegt und es da zu einem Tippfehler (Capslock ect.) liegt, dieses hat sich dann, als ich am Donnerstag von der Montage zurück kam, als falsch herausgestellt.
Auf meiner Suche nach einer Lösung habe ich meinen Grafiktreiber deinstalliert und neu installiert, auch Umbenennen von .kde/.kde4 aber nichts davon hat geholfen.
Dann, als ich hier einen neuen Eintrag eröffnen wollte, stieß ich auf diesen Thread hier.
So versuchte ich es direkt damit das ich folgenden Befehl in der Konsole absetzte:
Code:
zypper se -s libassuan
um zu sehen das auch meine installierte Version nicht aktuell war:
Code:
S | Name                       | Type       | Version   | Arch   | Repository                                                                                                       
--+----------------------------+------------+-----------+--------+------------------                                                                                                
i | libassuan0                 | package    | 2.0.0-5.1 | x86_64 | kde4.6                                                                                                           
v | libassuan0                 | package    | 2.0.0-5.1 | i586   | kde4.6                                                                                                           
v | libassuan0                 | package    | 2.0.2-4.1 | x86_64 | tumbleweed                                                                                                       
v | libassuan0                 | package    | 2.0.1-4.1 | x86_64 | openSUSE-11.4-Oss
v | libassuan0                 | package    | 2.0.2-4.1 | i586   | tumbleweed       
v | libassuan0                 | package    | 2.0.1-4.1 | i586   | openSUSE-11.4-Oss
Ergo startete ich die Aktualisierung:
Code:
zypper in libassuan0-2.0.2-4.1
The following package is going to be upgraded:
  libassuan0 

The following package is going to change vendor:
  libassuan0  obs://build.opensuse.org/KDE -> obs://build.opensuse.org/openSUSE:Tumbleweed

1 package to upgrade, 1 to change vendor.
Overall download size: 37.0 KiB. After the operation, additional 8.0 KiB will be used.
Continue? [y/n/?] (y): y
Retrieving package libassuan0-2.0.2-4.1.x86_64 (1/1), 37.0 KiB (93.0 KiB unpacked)
Retrieving: libassuan0-2.0.2-4.1.x86_64.rpm [done]
Installing: libassuan0-2.0.2-4.1 [done]
Sogleich startete ich erwartungsvoll meinen Computer neu und Heureka mein System startete wieder durch bis zum Desktop des Users. :D
mojo schrieb:
Haben das Problem auch mehrer und trauen sich nur nocht es hier zu posten?
Ich nicht, das Überfliegen der Themen-Überschriften genügte um hellhörig zu werden.

lieben Gruß aus Hessen
 
Oben