Tastatur friert ein mit xorg und fbsd 6.1

reaper

Well-Known Member
Hallo,

ich habe gestern von 6.0 auf 6.1 geupdated und seit den ein Problem bei dessen Ansatz ich nicht mehr wirklich weiter weiß und auch Google nichts sinnvolles mehr bringt.

Das Problem ist folgendes:

Nach dem Update auf 6.1 startet der Rechner erstmal ohne Probleme, der GDM klinkt sich irgendwann ein und startet auch ohne zu murren und zeigt den Login Bildschirm. Hier hängt nun aber die Tastatur, soll heißen ich kann tippen was ich will es passiert rein gar nix :( Die Maus läuft aber unbeindruckt weiter, so das ich noch neustarten und im Single-User den GDM disablen kann.

Soweit so gut, ich dachte also zuerst an ein Problem mit dem neuen kbdmux und hab diesen in der /boot/device.hints ausgeknipst. Leider ohne Erfolg. Auch eine frische xorg.conf hat nicht das geringste geändert. Hinzu kommt das X und auch GDM problemlos laufen wenn sie von Hand gestartet werden. Also nach dem Booten einloggen und das Startskript anwerfen, daher schließe ich eigentlich XOrg als direkte Fehlerquelle aus.

Hat hier vielleicht jemand ähnliche Beobachtungen gemacht? Bzw. weiß noch jemand Rat?

System Konfig: xorg 6.9.0 / fbsd 6.1 / thinkpad r40

Thanks schonmal für alle Ideen :)
Hanjo

PS.: Mein derzeitiger Verdacht beruht auf dem Startzeitpunkt vom GDM, also das noch irgendetwas dannach gestartet wird was dann alles aus dem Tritt bringt :( Kann man vielleicht beeinflußen wann der gdm gestartet wird? Also das er definitiv als letztes hochfährt, wenn alle anderen Dienste bereits laufen?
 
Kenne ich nur zu gut von meiner nForce4 Box. Dort tritt ein ähnliches Phänomen auf, egal ob mit Displaymanager oder der klassischen Konsole. Allerdings löst sich die Sperren von allein nach ca. 30 - 60 Sekunden. Schuld ist die Netzwerkkarte, die gedenkt irgendwelchen Datenmüll ins System zu pumpen. Lösung wäre in meinem Fall eine bessere Karte, aber das tut zur Zeit nicht Not :)

Keine Ahnung, ist ein wenig am Thema vorbei, aber vielleicht hilft es dir ja oder gibt dir wenigestens eine neue Richtung zum Suchen.

Den Startzeitpunkt eines rc-Scripts legen mehrer Variablen fest. Die wichtigsten sind REQUIRE und BEFORE. Am besten schaust du dir mal einige rc-Skripte an, dann solltest du das eigentlich recht schnell verstehen.
 
So etwas ähnliches hatte ich auch schon mal nach einem Upgrade. Ist schon länger her, aber bei mir hat
Code:
VTAllocation=true

in der Konfigurationsdatei gdm.conf geholfen.
 
... bei mir funktionierts mit

FirstVT=9
VTAllocation=true

die Datei heißt heutzutage "custom.conf"
 
Thx für den guten Ratschlag, VTAllocation hat es getan. Ich fürchte mein Problem geht mal wieder auf das Konto meiner Nachlässigen Update Strategie zurück ;) Ich hatten den GDM immer aktualisiert, jedoch nie die Konfigurationsdateien überprüft...
 
Hallo reaper,

das Problem kenne ich zu gut.
Es hat sich herausgestellt, dass ein Prozess (meist war es Squid) beim Startvorgang die Start-Skripte blockiert. Auch ein "VTAllocation=true" half überhaupt nicht.

Nun starte ich den gdm über ein Skript alter Machart in /usr/X11R6/etc/rc.d: xxxserver.sh. Das wird garantiert als letztes aufgerufen.

Nun funktioniert alles wieder.

Viele Grüße

Jürgen
 
Zurück
Oben