[gelöst] tty wechsel ab X11 geht nicht?

revealed · 30 Sep. 2011

Hallo!

Ich hab meine SuSE 11.4 jetzt auf (64 bit) umgerüstet... Dabei konnte ich so einige alte Geschichten beheben, wie die Nötigkeit einer Xorg.conf damit ich via LIRC meinen Mauszeiger steuern kann. (Das nur am Rande).

Jedenfalls hat sich dabei ergeben, dass ich nicht mehr die Option:

Code:

  Option       "AutoAddDevices" "off" # or lircmd will not function!

In der xorg.conf habe. Das ist eigentlich auch gut so. Ich möchte im Grunde nicht auf Hotplug verzichten.

Ich hatte kurzzeitig das Problem, dass der Anmeldungsmanager nicht starten wollte. Um ihn wieder ans Laufen zu bewegen, habe ich die /usr/share/kde4/config/kdm/kdmrc gelöscht, und dann hat er wieder gestartet. Jedenfalls hab ich die Einstellungen wiederhergestellt mit Hilfe der KDE dialoge in systemsettings.

Ich habe ein Logitech Access Keyboard. Normalerweise (Früher) hatte ich dieses via dem Treiber "kbd" in der xorg.conf eingebunden.

Ohne Xorg.conf also mit HAL und udev und via FDI files usw. erkennt X11 die Tastatur allerdings mit dem Treiber "evdev"? Dann kam noch dazu, dass ich Schwierigkeiten hatte, weil nodeadkeys nicht so akzeptiert wird wie früher mit kbd. Ich hatte keine Tilde~ mehr usw.

Das habe ich gelöst, indem ich in YasT nochmal die Tastatur und Sprache korrigiert habe. Dazu habe ich im KDE bei den Systemsettings für Eingabegeräte bei der Tastatur "Logitech Access Keyboard" eingestellt. ("logiaccess").
Und ich hab in dem Zuge auch, wie auf dieser Seite:
http://de.opensuse.org/ISO-Zeichensatz_statt_UTF-8_verwenden
den Zeichensatz von UTF-8 auf ISO umgestellt.

Jetzt gehen also die Geschichten ~@€ usw wieder. Auch einige Multimediatasten wie Lauter/Leiser, Ton aus und an.

Allerdings habe ich jetz das eigentlichen Problem:

Wenn ich beispielsweise ins Runlevel 3 boote, kann ich tty umschalten. STRG+ALT+(F1.. F2.. F3.. F4..) <- ganz normal.

Wenn ich von dort beispielsweise init 5 ausführe, und mich anmelde, geht es auch. <- (Das finde ich interessant).

Wenn ich allerdings dann den Rechner herunterfahre und neustarte. (shutdown -r now) und den Rechner einfach in die Volle grafische mehrbenutzerumgebung booten lasse, dann Geht der tty switch nicht.

Und zwar nicht erst beim User oder so. Sondern schon bei XDM (Dem Anmeldemanager).

Es geht nur, wenn ich mich zunächst beispielsweise im Runlevel 3 einmal anmelde.

In der Xorg.0.log dazu:

Code:

[ 30425.667] Failed to switch from vt02 to vt01: Input/output error
[ 30426.097] Failed to switch from vt02 to vt03: Input/output error
[ 30426.393] Failed to switch from vt02 to vt04: Input/output error
[ 30426.783] Failed to switch from vt02 to vt05: Input/output error
[ 30427.366] Failed to switch from vt02 to vt06: Input/output error
[ 30427.834] Failed to switch from vt02 to vt07: Input/output error

Ich vermute jetzt, dass irgendwo eine Kleinigkeit fehlt? Weiss da jemand bescheit? Hat das was mit /etc/init.d/kbd zu tun?

Ich habe mal auch schon grob rumgeschaut. In der inittab scheint alles i.O. auch die dateien /etc/securetty /etc/ttytype schauen fehlerfrei aus.

Was kann das nur sein?

Gruß,

R

spoensche · 30 Sep. 2011

Was sagt den der Kernel beim Systemstart? Was sagen die Logfiles?

revealed · 1 Okt. 2011

Hi!

Vielen Dank für deine Hilfe. Was möchtest du genau wissen? Die ganze boot.msg? (blogd ist forciv an und dienste werden nicht parallel gestartet, sondern nach Abhängigkeit).

boot.msg (direkter start in vollen Mehrbenutzerbetrieb) (kein wechsel zu tty möglich). http://nopaste.info/ccae0622bc.html

Ein Beispiel aus /var/log/messages: (mit | grep tty):

Code:

Sep 30 23:41:12 wild-thing login[23012]: FAILED LOGIN SESSION FROM /dev/tty2 FOR UNKNOWN, Benutzer bei zu Grunde liegendem Authentifizierungsmodul nicht bekannt
Sep 30 23:41:25 wild-thing mingetty[23035]: mingetty: tty2: read: Inappropriate ioctl for device
Sep 30 23:43:38 wild-thing mingetty[4783]: mingetty: tty2: invalid character 0xba in login name
Oct  1 00:02:13 wild-thing mingetty[4761]: mingetty: tty2: invalid character 0x9c in login name
Oct  1 00:02:23 wild-thing mingetty[7221]: mingetty: tty2: invalid character 0x94 in login name
Oct  1 00:02:48 wild-thing mingetty[7234]: mingetty: tty2: invalid character 0x95 in login name

Gruß,

R

revealed · 1 Okt. 2011

Ich hab die Locale einstellungen zum Test nochmal auf UTF-8 zurückgestellt. Ich schätze von daher mal, da es so auch nicht geht, dass es nicht an der Locale liegt.

Irgendwie hab ich das gefühl, dass dem Xserver nicht mitgeteilt wird dass TTY switch erlaubt ist. Kann ich irgendwie in der /etc/X11/xorg.conf.d struktur festlegen, dass TTY switch an ist?

Gruß,

R

revealed · 1 Okt. 2011

Ich werd mal damit versuchen:

Code:

Option "VTSysReq" "boolean"
    enables the SYSV-style VT switch sequence for non-SYSV systems which support VT switching. This sequence is Alt-SysRq followed by a function key (Fn). This prevents the Xorg server trapping the keys used for the default VT switch sequence, which means that clients can access them. Default: off.

true?

Code:

Option "DontVTSwitch" "boolean"
    This disallows the use of the Ctrl+Alt+Fn sequence (where Fn refers to one of the numbered function keys). That sequence is normally used to switch to another "virtual terminal" on operating systems that have this feature. When this option is enabled, that key sequence has no special meaning and is passed to clients. Default: off.

false?

Gruß,

R

spoensche · 1 Okt. 2011

Dein Problem hat nichts mit dem X-Server zu tun.

Code:

<6>[    2.470984] [drm] radeon defaulting to kernel modesetting.
<6>[    2.478806] [drm] radeon kernel modesetting enabled.
<7>[    2.485928] checking generic (c0000000 1000000) vs hw (c0000000 10000000)
<3>[    2.485930] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver

Verwende mal den Bootparameter

Code:

radeon.modeset=0

bzw. erstelle unter /etc/modprobe.d eine Datei mit folgendem Inhalt:

Code:

optios radeon modeset=0

Der Bootparameter bzw. die Option schaltet KMS (Kernel Mode Sets) ab.

revealed · 3 Okt. 2011

Hallo!

Du hast recht! (Ich musste das garnicht probieren). Ich hab glaube ein ganz anderes Problem. KDM wollte nach einem Upgrade mal nicht mehr starten, dann hab ich die kdmrc entfernt, weil ich davon davon ausgegangen bin, dass diese automatisch neu angelegt wird. Jedenfalls, wird sie das teilweise auch. Der Login funktionierte dann wieder. Mit teilweise meine ich: Nicht so, wie wenn man gen-kdmrc ausführt. Und das ist der Grund, warum die TTY nicht gingen. KDM wusste von den dingern nichts wegen der unvollständigen kdmrc.

Wenn ich gen-kdmrc ausführe, oder dies durch ein rpm getriggert wird, funktioniert mein Anmeldemanager nicht mehr. Der Grund dafür ist, dass in der KDMRC foglendes automatisch eingetragen wird:

Code:

GreeterUID=kdm

Wenn ich das auskommentiere, so dass es "default is empty und dann root" dann startet mein KDM wieder.

Jetzt bin ich gerade am Forschen. Das hat glaube was mit xauth usw zu zu tun. Weisst du da bescheid?

Wärst du bitte so nett und würdest mir sagen, wie bei dir:

Code:

GreeterUID=

in deiner KDM gesetzt ist?

Angenommen das wäre bei mir falsch, dann müsste ich herausfinden warum das so automatisch gesetzt wird.

Vielen Dank!

Gruß,

R

PS.: Oh --> Da war mal was... da hatte ich vor längerer Zeit mal ein Problem... http://lists4.suse.de/opensuse-bugs/2011-05/msg02581.html

revealed · 3 Okt. 2011

https://bugzilla.novell.com/show_bug.cgi?id=625765

Ja da war mal was... hier seh ich auch, dass ich eine Gruppe und einen User nach dem Vorschlag im bugzilla erstellt habe. Aber jetzt startet KDM so garnichtmehr. Jetzt muss ich herausfinden, warum (Ich vermute) das mit den Berechtigungen nicht hinhaut.

Gruß,

R

josef-wien · 3 Okt. 2011

Standardmäßig wird GreeterUID=kdm eingetragen. Das führt bei mir dazu, daß "Aktuelle Sitzung beenden" auf Grund des nicht vorhandenen Benutzers kdm nicht funktioniert, daher habe ich damals diese Zeile einfach auskommentiert. Das Problem gibt es erst seit 11.4, offenbar ist diese Neuerung mit dem Benutzer kdm noch nicht wirklich ausgereift.

revealed · 3 Okt. 2011

Hallo!

Ich habe in diversen bugtrackern (auch von anderen distris) inzwischen gefunden, dass man scheints gewisse auth files selber anlegen müsse (betreffend) Xauthority. Das müsste aber bedeuten, dass im Home kein .xauthority file angelegt werden könne, wo es standardmäßig angelegt werden würde. Was wiederum bedeuten würde, dass der Benutzer auf sein homeverzeichnis keinen Zugriff hat, oder?

Unter Umständen. Bin am Überlegen, ob ich das versuchen soll. Zunächst werde ich versuchen den User und die Gruppe neu anzulegen. Vielleicht ist da irgendwas durcheinander. Fall es das nicht sein sollte. Werde ich mal nochmal irgendwie checken müssen, wie die Pfade von einer standard kdmrc sind, so wie sie autogeneriert werden von null weg (auf meinem System).

Ich lese folgendes in der von genkdmconf (ohne Fehlermeldung) bereitgestellten Version der kdmrc auf meiner Kiste (bei der aber offensichtlich einiges durcheinander sein Könnte):
http://nopaste.info/40fb2e0c7d.html

Bei den Beschreibungen stehen einige Infos drin. Sobald ich einmal mit dem Systemsettings tool drübergehe, werden die ganzen Kommentare entfernt. Die wären jetzt aber sinnvoll zum lesen, schätz ich mal.

Ah, und bevor ich es vergesse kde4-config --version:

Code:

Qt: 4.7.4
KDE: 4.7.1 (4.7.1) "release 8"
kde4-config: 1.0

Das wird bei mir automatisch gesetzt:

Code:

# The user the greeter should run as. Empty results in root.
# Consider the impact on LogSource when setting it.
# Default is ""
GreeterUID=kdm

Und hier was interessantes:

Code:

# The user the X-server should run as. Empty results in root.
# Default is ""

(aus meiner kdmrc).

Das heisst dass es als User root gruppe kdm ausgeführt wird? müsste aber sein, kdm kdm? *wirr*
Sollte doch kein Problem sein?

Es wäre sinnfrei, wenn ich kdm zu root mache . --> Selbst wenn ich kdm in gruppe kdm und root stopfe, startet er nicht. Da stimmt irgendwas mit dem Mechanismus nicht schätze ich mal. Bin ich der Einzige mit diesem Problem bei der Version?

Code:

disk@wild-thing:~> rpm -qa | egrep "kdm|greet"
kdm-branding-openSUSE-11.4-3.2.x86_64
kde4-kgreeter-plugins-4.7.1-5.3.x86_64
kdm-4.7.1-5.3.x86_64

Irgendwie komm ich nicht dahinter... was ich noch nicht versucht habe, einen Start ohne die bereits erstellten user und KDM KDM. Werd mal löschen und genkdmrc ausführen. Dann schauen.

Ich glaube das könnte funktionieren als workaround:
wenn ich genkdmrc ausführe, dann sieht es so aus:

Code:

# The user the greeter should run as. Empty results in root.
# Consider the impact on LogSource when setting it.
# Default is ""
#GreeterUID=kdm

Allerdings erscheint in der Ausgabe wieder die Meldung:

Code:

Warning: Do not know how to create missing GreeterUID user kdm

Kann ich nix machen.

Ich glaube aber ich werde die leute in dem Bugzilla noch informieren, dass ich jetzt nach dem Upgrade auf SuSE 11.4 mit dem Workaround aus dem bugzilla probleme bekomme habe und es rückgängig gemacht habe.

Und vielen Dank für die Hilfe nochmal!

Gruß,

R

PS.: Dies habe ich jetzt hier versucht zusammenzufassen:
https://bugzilla.novell.com/show_bug.cgi?id=625765#c17

PPS.: Einfach auskommentieren ist bei mir leider nicht so einfach, da das kdm Paket bei mir irgendwie öfter aktualisiert wird durch meine repo auswahl. Das bedeutet auch, dass jedes mal genkdmrc ausgelöst wird. Was mein Problem verursacht. Dann müsste ich jedes mal explizit nur wegs einer Warnung die kdmrc manuell editieren. Da ich dafür momentan zu faul bin...

denke ich ist das damit gelöst. Diese "Warnung" ignoriert man glaube ich in dem Fall besser.