Window manager ok sous root et pas ok pour user lambda

Support Debian
#1

Bonsoir,
faisant divers essais pour règler des pb de fontes j’ai fini par casser quelque chose:
X ne démarrait plus du tout
j’ai donc purgé ‘avec aptitude’ tout ce qui me semblait relever du graphique y compris kde gnome etc
j’ai réinstallé fluxbox (et X) + wdm
après le boot wdm démarre c’est donc mieux qu’avant et je suppose que donc ça va pour X
mais si je me logue normalement l’écran devient noir et je reviens rapidement à wdm
alors que si je me logue root tout va bien fluxbox apparait
je ne vois pas d’anomalie particulière dans XFree86.0.log
ni dans ~/.xsession-errors
dans quelle direction devrais-je chercher ?
de manière générale que fait wdm avant qu’on arrive au fichier ~/.xsession ?

( debian sid)

merci d’avance
Jacques

#2

tu as essayé d’arrèter wdm (/etc/init.d/wdm stop), de te loguer en user, de faire un “startx” pour voir si ca démarre, ou s’il y a des messages ?

#3

j’avais oublié, oui j’ai fait l’essai et startx s’arrête avec le message
/usr/bin/X11/startx ligne 150 permission non accordée

à la ligne 150 il y a
if command -v deallocvt > /dev/null 2>&1; then

comme je n’ai fait aucune modif de ce côté je ne comprends pas pourquoi il ne peut pas dé-allouer “kernel memory and data structures for all unused virtual terminals”

comme le système fonctionnait avant mes bidouilles avec les fontes et qu’il fonctionne toujours pour root, je suppose qu’il n’y a pas de problème matériel.

#4

non, c’est ce que ca sentait déja : un problème de droits sur un fichier.
Par exemple, quels sont les droits sur le ~/.xsession-errors de l’user normal ?
regardes bien dans le ~ de cet user s’il n’y a pas des fichiers ou des répertoires que root s’y serait approprié.

#5

j’ai failli crier BINGO en trouvant le .ICEauthority réservé à root mais hélas ça ne va pas mieux en changeant le propriétaire de ce fichier
par contre je viens de constater que le message d’erreur ne me dit pas qu’il ne peut pas dé-allouer mais plus exactement
/usr/bin/X11/startx :line 150 : /dev/null permission non accordée
or la fameuse ligne 150 dit exactement :
"if command -v deallocvt > /dev/null 2>&1; then"
et j’ai essayé
"test > /dev/null"
j’ai eu le même message d’erreur
donc apparemment je n’ai plus le droit d’envoyer dans le virtuel !

#6

installes udev, ou recrées /dev/null avec:
rm /dev/null
mknod -m 0666 /dev/null c 1 3

qui doit avoir les permissions:
crw-rw-rw- 1 root root 1, 3

#7

bonjour,
merci
en fait "udev est déjà la plus récente version disponible."
je me pencherai plus tard sur le man pour comprendre (peut-être) à quoi il sert.
/dev/null était root crw rw
je l’ai mis en crw rw rw

qu’il est long et semé d’embuches le chemin de la connaissance !
bon week end
Jacques

#8

désolé pour le triplé
j’ai un message d’erreur générale

#9

le triplé est corrigé

#10

merci pour le triplé

je n’ai plus de pb avec > /dev/null
mais je ne peux toujours pas lancé startx

voici ce que je trouve dans .xsession-errors
Xsession: X session started for jacques at sam avr 16 10:07:16 CEST 2005
PRNG is not seeded

et là je ne vois pas du tout de quoi on parle !

#11

apparemment celà concerne le PSEUDO RANDOM NUMBER GENERATOR (merci Google)
je continue à fouiller

#12

en fait il me semble bien que j’ai un gros problème
j’ai remplacé le /dev/null
puis je me suis rendu compte que j’avais un pb avec le PSEUDO RANDOM NUMBER GENERATOR
et j’ai trouvé que /dev/random était en crw rw alors qu’il devait être en crw r r
je l’ai donc remplacé
j’ai relancé startx et j’ai eu le pb du début c’est à dire
"/dev/null permission non accordé"
j’ai alors trouvé que /dev/null était revenu crw rw
au lieu d’être crw rw rw
j’ai donc l’impression de tourner en rond
et je ne sais plus dans quelle direction chercher

#13

normalement, udev crée lui même automatiquement tous les devices en fonction des éléments détectés par le ‘hotplug manager’.
Maintenant, c’est un peu nouveau, mais il commence à y avoir des ‘bugs list’. J’ai trouvé entre autres:

#14

ah, et si tu dois modifier /etc/udev/permissions.d/50-udev.permissions, pas besoin de redemarrer, normalement, pour constater les mises à jour.
un simple ‘/etc/init.d/udev restart’ devrait faire l’affaire.

#15

merci je ne risquais pas de trouver celà tout seul

la première vérification me semble bonne
j’ai bien obtenu (sauf que le fichier n’est pas 50-udev.permissions mais udev.permissions)

grep null /etc/udev/permissions.d/udev.permissions

null:root:root:0666

par contre il y a des différences pour la deuxième vérif

au lieu de :
You might also check that you’ve got /dev and its subfilesystems
mounted and /dev is a ramfs filesystems.

$ grep ./dev /proc/mounts
none /dev ramfs rw 0 0
none /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0

j’ai obtenu :

grep ./dev /proc/mounts

/dev2/root2 /dev/.static/dev ext3 rw 0 0
none /dev tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0

et je ne sais pas si je dois corriger pour avoir exactement ce que tu as trouvé ou si c’est différent avec Debian
et je ne sais pas si je risque de tomber encore plus bas en faisant la modif sans comprendre ce que je fais

#16

moi, ca marche, et j’ai la même chose que toi, chez moi, donc ce que tu as est bon, et le cas présenté doit correspondre à la gentoo.
As tu toujours /dev/null en 0660, malgré le

grep null /etc/udev/permissions.d/udev.permissions

null:root:root:0666
?
même aprés redémarrage de udev ?
c’était ce que tu avais à l’origine, dans udev.permissions ?

#17

j’ai bien toujours /dev/null = 660 malgré le redémarrage de udev et il y a bien 666 dans /etc/udev/permissions.d/udev.permissions
je n’ai fait aucune modif à ce niveau

j’ai remarqué quelque chose qui a peut-être un rapport
au boot et tout de suite après le montage des disques je vois passer une ligne qui me dit quelque chose comme
grep mauvaise expression régulière
mais je ne retrouve pas celà dans les logs (je ne sais pas très bien où chercher) et je ne sais pas ce qui tourne à ce stade du boot (un script sans doute mais lequel ?)

#18

dmesg te donne les messages du boot

#19

avec dmesg je ne vois pas cette partie de ce qui défile à l’écran au moment du boot
je viens de rebooter pour voir et il me semble que c’est après ce que montre dmesg

#20

bon, cherches le mot clé grep dans les logs:
grep grep /var/log/*.log
pour déterminer ou le message a pu tomber