Le 02/10/2013 18:18, *Herve Autret* a écrit fort à propos :
Je peux me logger dans les consoles virtuelles : mon mdp est donc Ok. Je l'ai même fait changer par root pour tester : pas mieux !
root peut se loguer via l'interface graphique, le clavier est donc Ok
Quelqu'un aurait des pistes ?
As tu essayé la combinaison de touches (du genre Fn + NumLock) qui change l'affectation de certaines touches de la partie centrale du clavier ? J'ai eu le cas sur mon eeepc sous Mageia avant d'adopter un noyau spécial netbook...
Le 02/10/2013 18:18, *Herve Autret* a écrit fort à propos :
Je peux me logger dans les consoles virtuelles : mon mdp est donc Ok. Je
l'ai même fait changer par root pour tester : pas mieux !
root peut se loguer via l'interface graphique, le clavier est donc Ok
Quelqu'un aurait des pistes ?
As tu essayé la combinaison de touches (du genre Fn + NumLock) qui change
l'affectation de certaines touches de la partie centrale du clavier ? J'ai
eu le cas sur mon eeepc sous Mageia avant d'adopter un noyau spécial netbook...
Le 02/10/2013 18:18, *Herve Autret* a écrit fort à propos :
Je peux me logger dans les consoles virtuelles : mon mdp est donc Ok. Je l'ai même fait changer par root pour tester : pas mieux !
root peut se loguer via l'interface graphique, le clavier est donc Ok
Quelqu'un aurait des pistes ?
As tu essayé la combinaison de touches (du genre Fn + NumLock) qui change l'affectation de certaines touches de la partie centrale du clavier ? J'ai eu le cas sur mon eeepc sous Mageia avant d'adopter un noyau spécial netbook...
Herve Autret
Bonjour,
jp willm :
Le /home/utilisateur est importé d'un autre sytème ? Si oui, les droits de /home/utilisateur correspondent-ils à cet utilisateur ?
Le répertoire de l'instal précédente a bien été réutilisé et son propriétaire semblait correct, i.e moi:users. Selon les distros, c'est moi:users ou moi:moi mais je ne sais pas si ça a une importance pour le fonctionnement d'Xorg. Ça fait toujours des choses à essayer, note.
Mais ce que je n'ai pas vérifié, c'était si le contenu de $HOME avait également changé de propriétaire ; si le chown avait été récursif, quoi... Bon, je réinstalle pour voir.
@Lucas et @Géo : oui, j'avais testé tout ça.
à + -- Hervé
Bonjour,
jp willm :
Le /home/utilisateur est importé d'un autre sytème ?
Si oui, les droits de /home/utilisateur correspondent-ils à cet
utilisateur ?
Le répertoire de l'instal précédente a bien été réutilisé et son
propriétaire semblait correct, i.e moi:users. Selon les distros, c'est
moi:users ou moi:moi mais je ne sais pas si ça a une importance pour le
fonctionnement d'Xorg. Ça fait toujours des choses à essayer, note.
Mais ce que je n'ai pas vérifié, c'était si le contenu de $HOME avait
également changé de propriétaire ; si le chown avait été récursif, quoi...
Bon, je réinstalle pour voir.
Le /home/utilisateur est importé d'un autre sytème ? Si oui, les droits de /home/utilisateur correspondent-ils à cet utilisateur ?
Le répertoire de l'instal précédente a bien été réutilisé et son propriétaire semblait correct, i.e moi:users. Selon les distros, c'est moi:users ou moi:moi mais je ne sais pas si ça a une importance pour le fonctionnement d'Xorg. Ça fait toujours des choses à essayer, note.
Mais ce que je n'ai pas vérifié, c'était si le contenu de $HOME avait également changé de propriétaire ; si le chown avait été récursif, quoi... Bon, je réinstalle pour voir.
@Lucas et @Géo : oui, j'avais testé tout ça.
à + -- Hervé
Fred
On 10/02/2013 06:18 PM, Herve Autret wrote:
Bonjour fcolc,
Salut
Quelqu'un aurait des pistes ?
à +
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
On 10/02/2013 06:18 PM, Herve Autret wrote:
Bonjour fcolc,
Salut
Quelqu'un aurait des pistes ?
à +
Le clavier qui passe en querty pour le mot de passe?
J'ai ça sur une slackware.
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
Herve Autret
Bonjour,
Je disais :
Bon, je réinstalle pour voir.
Réinstallation : Ouf ! ça recommence...
J'ai fini par trouver l'origine du pb. Le fichier .xsession.errors contenait des références à xfsettingsd et à fluxbox, commandes qui figuraient dans mon .xinitrc mais absentes du système (sinon je me serais demandé pourquoi c'est fluxbox qui tourne alors que je voulais essayer LXDE, notez). Un renommage a fait tomber l'interface en marche.
Dans les jours passés j'ai installé Debian-7, CentOS-6 et Fermi-chose en réutilisant mon $HOME sans problème d'ouverture de session. C'est en fait la première fois que je vois un gestionnaire de session graphique s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
PS :pour info, un chown récursif moi:users n'avait rien changé et par ailleurs c'est une openSUSE-12.3, pas une SUSE.
à + -- Hervé
Bonjour,
Je disais :
Bon, je réinstalle pour voir.
Réinstallation : Ouf ! ça recommence...
J'ai fini par trouver l'origine du pb. Le fichier .xsession.errors
contenait des références à xfsettingsd et à fluxbox, commandes qui
figuraient dans mon .xinitrc mais absentes du système (sinon je me serais
demandé pourquoi c'est fluxbox qui tourne alors que je voulais essayer
LXDE, notez). Un renommage a fait tomber l'interface en marche.
Dans les jours passés j'ai installé Debian-7, CentOS-6 et Fermi-chose en
réutilisant mon $HOME sans problème d'ouverture de session. C'est en fait
la première fois que je vois un gestionnaire de session graphique
s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
PS :pour info, un chown récursif moi:users n'avait rien changé et par
ailleurs c'est une openSUSE-12.3, pas une SUSE.
J'ai fini par trouver l'origine du pb. Le fichier .xsession.errors contenait des références à xfsettingsd et à fluxbox, commandes qui figuraient dans mon .xinitrc mais absentes du système (sinon je me serais demandé pourquoi c'est fluxbox qui tourne alors que je voulais essayer LXDE, notez). Un renommage a fait tomber l'interface en marche.
Dans les jours passés j'ai installé Debian-7, CentOS-6 et Fermi-chose en réutilisant mon $HOME sans problème d'ouverture de session. C'est en fait la première fois que je vois un gestionnaire de session graphique s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
PS :pour info, un chown récursif moi:users n'avait rien changé et par ailleurs c'est une openSUSE-12.3, pas une SUSE.
à + -- Hervé
Herve Autret
Bonjour,
Fred :
Quelqu'un aurait des pistes ?
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
J'avais testé, merci. Depuis les Slack-13 et 14 (avant je ne sais pas) le verr-num n'as pas d'effet pour le login sur console : activé ou non, les touches du pavé de droite sont en numérique.
Ça simplifie la vie à la maison.
à + -- Hervé
Bonjour,
Fred :
Quelqu'un aurait des pistes ?
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une
slackware.
J'avais testé, merci. Depuis les Slack-13 et 14 (avant je ne sais pas)
le verr-num n'as pas d'effet pour le login sur console : activé ou non,
les touches du pavé de droite sont en numérique.
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
J'avais testé, merci. Depuis les Slack-13 et 14 (avant je ne sais pas) le verr-num n'as pas d'effet pour le login sur console : activé ou non, les touches du pavé de droite sont en numérique.
Ça simplifie la vie à la maison.
à + -- Hervé
Herve Autret
(re)bonjour
Fred :
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
Juste pour savoir : quelle version et quel matériel ?
Ça me revient maintenant : j'ai eu un truc similaire il y a 3-4 ans avec une Slack raccordée à un KVM : lors de la première connexion, le clavier était en français ; lors des connexions suivantes, il était en anglais. Sur l'autre port du KVM il y avait une CentOS qui restait toujours en français.
J'avais dû poster ici mais ne crois pas me souvenir qu'on ait trouvé une solution.
à + -- Hervé
(re)bonjour
Fred :
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une
slackware.
Juste pour savoir : quelle version et quel matériel ?
Ça me revient maintenant : j'ai eu un truc similaire il y a 3-4 ans avec
une Slack raccordée à un KVM : lors de la première connexion, le clavier
était en français ; lors des connexions suivantes, il était en anglais.
Sur l'autre port du KVM il y avait une CentOS qui restait toujours en
français.
J'avais dû poster ici mais ne crois pas me souvenir qu'on ait trouvé une
solution.
Le clavier qui passe en querty pour le mot de passe? J'ai ça sur une slackware.
Juste pour savoir : quelle version et quel matériel ?
Ça me revient maintenant : j'ai eu un truc similaire il y a 3-4 ans avec une Slack raccordée à un KVM : lors de la première connexion, le clavier était en français ; lors des connexions suivantes, il était en anglais. Sur l'autre port du KVM il y avait une CentOS qui restait toujours en français.
J'avais dû poster ici mais ne crois pas me souvenir qu'on ait trouvé une solution.
à + -- Hervé
Lucas Levrel
Le 3 octobre 2013, Herve Autret a écrit :
la première fois que je vois un gestionnaire de session graphique s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
Ça doit dépendre du DM. Par exemple dans /etc/X11/xdm/Xsession (suse 11.2) je lis :
# Some common user and system files # session=$HOME/.xsession xinitrc=$HOME/.xinitrc sysinit=$XINITDIR/xinitrc syssess=$XDMDIR/sys.xsession
# User login X session # If the user doesn't have their own xsession, then run # system xsession or xinitrc script if they exist
if test -f $session ; then test -x $session && exec_login "$session" exec_login "/bin/bash $session" elif test -f $xinitrc ; then test -x $xinitrc && exec_login "$xinitrc" exec_login "/bin/bash $xinitrc" elif test -f $syssess; then test -x $syssess && exec_login "$syssess" exec_login "/bin/bash $syssess" elif test -f $sysinit ; then test -x $sysinit && exec_login "$sysinit" exec_login "/bin/bash $sysinit" (...)
Donc xdm devrait prendre .xsession en priorité.
par ailleurs c'est une openSUSE-12.3, pas une SUSE.
« Suse » n'existe plus, c'est soit Opensuse, soit SLED (Suse Linux Enterprise Distribution ?), version payante.
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Le 3 octobre 2013, Herve Autret a écrit :
la première fois que je vois un gestionnaire de session graphique
s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
Ça doit dépendre du DM. Par exemple dans /etc/X11/xdm/Xsession (suse 11.2)
je lis :
# Some common user and system files
#
session=$HOME/.xsession
xinitrc=$HOME/.xinitrc
sysinit=$XINITDIR/xinitrc
syssess=$XDMDIR/sys.xsession
# User login X session
# If the user doesn't have their own xsession, then run
# system xsession or xinitrc script if they exist
if test -f $session ; then
test -x $session && exec_login "$session"
exec_login "/bin/bash $session"
elif test -f $xinitrc ; then
test -x $xinitrc && exec_login "$xinitrc"
exec_login "/bin/bash $xinitrc"
elif test -f $syssess; then
test -x $syssess && exec_login "$syssess"
exec_login "/bin/bash $syssess"
elif test -f $sysinit ; then
test -x $sysinit && exec_login "$sysinit"
exec_login "/bin/bash $sysinit"
(...)
Donc xdm devrait prendre .xsession en priorité.
par ailleurs c'est une openSUSE-12.3, pas une SUSE.
« Suse » n'existe plus, c'est soit Opensuse, soit SLED (Suse Linux
Enterprise Distribution ?), version payante.
la première fois que je vois un gestionnaire de session graphique s'intéresser au .xinitrc plutôt qu'au .xsession s'il en trouve un.
J'espère qu'il n'y a pas trop d'astuces du même tonneau dans cet OS...
Ça doit dépendre du DM. Par exemple dans /etc/X11/xdm/Xsession (suse 11.2) je lis :
# Some common user and system files # session=$HOME/.xsession xinitrc=$HOME/.xinitrc sysinit=$XINITDIR/xinitrc syssess=$XDMDIR/sys.xsession
# User login X session # If the user doesn't have their own xsession, then run # system xsession or xinitrc script if they exist
if test -f $session ; then test -x $session && exec_login "$session" exec_login "/bin/bash $session" elif test -f $xinitrc ; then test -x $xinitrc && exec_login "$xinitrc" exec_login "/bin/bash $xinitrc" elif test -f $syssess; then test -x $syssess && exec_login "$syssess" exec_login "/bin/bash $syssess" elif test -f $sysinit ; then test -x $sysinit && exec_login "$sysinit" exec_login "/bin/bash $sysinit" (...)
Donc xdm devrait prendre .xsession en priorité.
par ailleurs c'est une openSUSE-12.3, pas une SUSE.
« Suse » n'existe plus, c'est soit Opensuse, soit SLED (Suse Linux Enterprise Distribution ?), version payante.
