# kdm startet Enlightenment nicht mehr [solved]

## musv

Hi, 

nach längerer updateloser Zeit hab ich mein Notebook mal wieder aktualisiert. Dabei waren unter anderem die ganzen KDE-Pakete von 4.1.85 auf 4.2.0. Als Windowmanager ist bei mir Enlightenment e16 installiert. Der wird auch in der Auswahl der Sitzungen angeboten. Da steht: 

```
Default

e16 (vorherige)

e16 (KDE)

e16 (Gnome)

Failsafe
```

Egal, welchen ich von den e16 nehme, ich bekomme nach dem Einloggen oben links in der Ecke nur eine rahmenlose Konsole angezeigt (xterm). Wenn ich dagegen e16 über startx starte, funktioniert alles problemlos. 

Wie krieg ich den kdm dazu, wieder meinen Enlightenment zu starten? 

Und 2. Frage (unwichtiger): Wo kann ich die Einträge für e16 (KDE) und e16 (Gnome) aus der Liste rausschmeißen? Die Dinger sind nicht wirklich sinnvoll.Last edited by musv on Wed Apr 01, 2009 9:11 am; edited 1 time in total

----------

## disi

Also ich hatte ein aehnliches Problem und ein re- bzw emerge von xorg-x11 hat es bei mir geloest (das Rahmenlose). Ansonsten die variable XSESSION ueberpruefen. Verfuegbare Sessions siehst du in /etc/X11/Sessions.

----------

## musv

Das mit dem remerge von xorg werd ich heut abend mal testen, da ich zur Zeit keine Portage da hab.  :Smile: 

```
echo $XSESSION

```

und

```
ls /etc/X11/Sessions/

Xsession
```

Wäre jetzt noch interessant, wo die bereits in der KDM-Liste stehenden Sessions gespeichert sind.

----------

## disi

Also ich habe bei baselayout2 (frisch installiert heute von der Arbeit und noch nicht getestet):

```
disi-desktop ~ # ls /etc/X11/Sessions/

kde-4.2  Xsession

```

und 

```
disi-desktop ~ # cat /etc/env.d/90xsession

XSESSION="kde-4.2"

```

----------

## musv

So, hab xorg-server neu gebaut, das "e16" vom anderen Rechner nach /etc/X11/Sessions rüberkopiert, die Variable gesetzt und Enlightenment neu gebaut. 

Ergebnis: Keine Veränderung. KDM lädt nur ein rahmenloses xterm, aber keinen Enlightenment.

----------

## disi

Hast du emerge xorg-server oder xorg-x11 gemacht? Das sind zwei verschiedene Pakete.

----------

## musv

Bei mir ist nur der xorg-server installiert. Das ganze xorg-Paket braucht man im Normalfall nicht. 

Ok, ich hab jetzt sowohl das Notebook als auch meinen Desktoprechner auf kde-4.2.1 geupdated. Beim großen Rechner startet der kdm wie gewohnt den e16, beim Notebook kommt ebenso wie gewohnt nach Einloggen das rahmenlose xterm. 

Ich bin jetzt aber schon mal einen halben Schritt weiter mit den Nachforschungen. 

1. /etc/X11

Da gibt's einen Ordner Sessions. Darin befand sich ein Script namens Xsession, was zum Einlesen von Xmodmap, Xresources, Xkbmap usw. zuständig ist. Ich vermute, dass das beim normalen startx ausgelesen wird. In diesen Ordner Sessions hab ich noch das Startsscript e16 reinkopiert. Änderungen wie bereits oben geschrieben: keine.

2. /usr/kde/4.2

Seit ich kde auf -prefix umgestellt hab (braucht man für kde3 und kde4 nicht, wenn man keine Minor-Versions parallel installiert), steht da kaum noch was drin. Ich vermute, dass der derzeitige Inhalt dieses Verzeichnisses nur Restemüll ist, der nicht ordnungsgemäß gelöscht wurde. Löschen will ich's auf Basis einer Vermutung trotzdem lieber nicht. 

3. /usr/share/config/kdm

Da stehen jetzt die Config-Dateien drin. U.a. auch die kdmrc. 

4. /usr/share/apps/kdm/sessions

Hier findet man einen Haufen an $windowmanager.desktop-Dateien. Hier gibt's auch eine e16.desktop. Ich vermute, dass dieses Verzeichnis nur als Ablage für Default-Configs gedacht ist. 

5. /usr/share/xsessions/e16.desktop

Hier befanden sich 3 Links: e16.desktop, e16-gnome.desktop und e16-kde.desktop. Letztere beiden hab ich rausgelöscht. Seitdem sind auch die Einträge für e16-KDE und e16-Gnome im kdm-Sitzungsmenü verschwunden. Demzufolge wird dieses Verzeichnis tatsächlich von kdm gescannt. Der Link e16.desktop zeigt auf /usr/share/xsessions/e16.desktop

6. /usr/share/xsessions

In diesem Verzeichnis befindet sich auch wieder ein Link e16.desktop, der auf /usr/share/e16/misc/e16.desktop zeigt. Ist der einzige Eintrag in diesem Verzeichnis

7. /usr/share/e16/misc/

```
drwxr-xr-x 2 root root   13  1. Mär 23:21 .

drwxr-xr-x 8 root root    8 23. Jan 17:42 ..

-rwxr-xr-x 1 root root  125  1. Mär 23:21 e16-dbus-cmd

-rw-r--r-- 1 root root  188  1. Mär 23:21 e16.desktop

-rw-r--r-- 1 root root  211  1. Mär 23:21 e16-gnome.desktop

-rw-r--r-- 1 root root  205  1. Mär 23:21 e16-kde.desktop

-rw-r--r-- 1 root root 1524  1. Mär 23:21 e16.png

-rwxr-xr-x 1 root root  185  1. Mär 23:21 starte16

lrwxrwxrwx 1 root root    8  1. Mär 23:21 starte16-gnome -> starte16

lrwxrwxrwx 1 root root    8  1. Mär 23:21 starte16-kde -> starte16

-rwxr-xr-x 1 root root   30  1. Mär 23:21 Xclients.e16-gnome.sh

-rwxr-xr-x 1 root root   28  1. Mär 23:21 Xclients.e16-kde.sh

-rwxr-xr-x 1 root root   19  1. Mär 23:21 Xclients.e16.sh
```

e16.desktop enthält:

```
[Desktop Entry]

Encoding=UTF-8

Type=XSession

Name=E16

Comment=This session starts the Enlightenment (e16) window manager

Exec=/usr/share/e16/misc/starte16

Icon=/usr/share/e16/misc/e16.png
```

und starte16 führt nach Übergabeparameterprüfung nur /usr/bin/e16 aus. Das wiederum steht auch in meiner .xinitrc, mit der ich über startx den e16 ohne kdm starten kann. 

Das Lustige daran ist jetzt, dass die ganzen o.g. Links und Dateien auf beiden Rechnern vorhanden sind. Nur funktioniert's halt auf einem, auf dem anderen aber nicht. Rechte sind auch gleich. Inhalt der Skripte ist ebenfalls identisch.

Und nochwas: Wenn kdm das rahmenlose xterm startet, hat das xterm immerhin das Design meiner .Xdefaults-Einstellungen (schwarzer Hintergund, grüne Schrift) und meiner .bashrc. Immerhin scheint kdm in seiner Ignoranz wenigstens noch die Design-Eigenschaften aus meinem Nutzerverzeichnis zu lesen.

PS: In /var/log/kdm.log steht natürlich nur drin, dass kdm es geschafft hat, den X-Server zu starten. Über irgendwelche Login- oder Sessionprobleme wird darin kein Wort verloren.

Nachtrag2: Nach Einloggen über kdm ins rahmenlose xterm, zeigt mir 

```
echo $DESKTOP_SESSION

e16
```

richtigerweise an.

----------

## musv

Lösung:

```
chmod 755 /usr/share/config
```

Die Rechte waren hier auf 700 gesetzt.

----------

