[Xorg] Bloque depuis 'pacman -Syu' (résolu)

[LuX]

Bonjour,

je viens de mettre a jour mon Arch Linux pour la premiere fois depuis que je l'ai installee il y a quelques mois. J'ai eu une longue liste de message pendant la mise a jour, mais apparemment rien d'anormal. Sauf qu'apres extinction et redemarrage : plus de Xorg !

Le fichier /var/log/slim.conf se termine par la ligne :
f000:36ab: 01 ILLEGAL EXTENDED X86 OPCODE!

Google ne m'apprend pas grand chose sur le sujet. Je suis un peu depasse. Mon portable est un Toshiba Portege avec une carte graphique Trident Microsystems Cyberblade XPAi1.

Si quelqu'un a une suggestion a me faire... merci d'avance,
LuX.

[urcadox]

"je viens de mettre a jour mon Arch Linux pour la premiere fois depuis que je l'ai installee il y a quelques mois"

C'est là qu'est ton erreur, ArchLinux ça se met à jour au moins une fois par semaine (y'a des mises à jour tous les jours (ou presque)).


Cela étant dit, quelle est ta carte graphique et quel pilote utilises-tu ?

Pour avoir plus d'infos sur ton problème, fais :

Code : Tout sélectionner

cat /var/log/Xorg.0.log | grep EE

[oktoberfest]

C'est là qu'est ton erreur, ArchLinux ça se met à jour au moins une fois par semaine (y'a des mises à jour tous les jours (ou presque)).

C'est pas parce Archlinux est une rolling release qu'il faut suivre le rythme des mises à jour. A chacun de choisir son rythme. Si le système fonctionne, pourquoi le mettre à jour... Adage utilisé dans la plupart des entreprises.

Cela étant dit je suis d'accord aussi pour regarder /var/log/Xorg.0.log

[urcadox]

C'est mieux de suivre le rythme pour éviter le genre de problèmes de l'OP justement, après chacun son choix c'est sûr. Mais faire souvent les mises à jour évite de cumuler les problèmes.

Personnellement je suis en testing, je fais très souvent les mises à jour et j'ai jamais eu de problèmes de ce genre. J'ai même pour ainsi dire jamais de problèmes (à part consolekit en ce moment que j'ai tout simplement remis dans sa version "non-testing").


Enfin bref, restons dans le sujet ! °°

[LuX]

Bonjour,

merci pour les réponses. Pour l'instant je bloque toujours. Je pense que mon problème vient de ce que xorg utilise maintenant udev pour détecter le matériel, au lieu de hal antérieurement. J'ai bien sûr fureté sur le wiki francophone et anglophone, mais je n'ai rien vu qui me débloque sur Xorg, et je n'ai jamais assez compris le fonctionnement de udev pour en tirer quelque chose alors...

Ma carte graphique est comme je le disais une carte Trident Cyberblade :

Code : Tout sélectionner

$ lspci | grep VGA
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82)

Elle nécessite le driver xf86-video-trident, qui était installé. À tout hasard je l'ai éliminé et ré-installé. Pas de changement.

Mon fichier /etc/X11/xorg.conf précisait cela, et uniquement ce qui concernait le moniteur. Le reste (le clavier et mon système de bascule fr/us) était indiqué dans /mnt/hda1/etc/hal/fdi/policy/10-keymap.fdi qui existe toujours. À tout hasard, j'ai déplacé le xorg.conf en /etc/X11/xorg.conf.d/11-moniteur.conf sans changement. Voici ces deux fichiers :

Code : Tout sélectionner

# Fichier cree a la main d'apres les infos de Arch :
# http://wiki.archlinux.fr/howto/indispensable/xorg


Section "Device"
	Identifier	"Trident Microsystems CyberBlade XPAi1"
	Driver		"trident"
	BusID		"PCI:1:0:0"
EndSection

Section "Monitor"
	Identifier	"Écran générique"
	Option		"DPMS"
	HorizSync	28-51
	VertRefresh	43-60
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Device		"Trident Microsystems CyberBlade XPAi1"
	Monitor		"Écran générique"
	DefaultDepth	24
	SubSection "Display"
		Depth		1
		Modes		"1024x768"
	EndSubSection
	SubSection "Display"
		Depth		4
		Modes		"1024x768"
	EndSubSection
	SubSection "Display"
		Depth		8
		Modes		"1024x768"
	EndSubSection
	SubSection "Display"
		Depth		15
		Modes		"1024x768"
	EndSubSection
	SubSection "Display"
		Depth		16
		Modes		"1024x768"
	EndSubSection
	SubSection "Display"
		Depth		24
		Modes		"1024x768"
	EndSubSection
EndSection

Code : Tout sélectionner

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>

    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">xorg</merge>

      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>

      <merge key="input.xkb.layout" type="string">fr,us</merge>
      <merge key="input.xkb.variant" type="string">oss</merge>
      <merge key="input.xkb.options" type="string">grp:lwin_toggle,terminate:ct
rl_alt_bksp</merge>
   </match>
  </device>
</deviceinfo>

Dans ce répertoire /etc/X11/xorg.conf.d je n'ai rien d'autre, à part les fichiers placés là d'office auxquels je n'ai pas osé touché : 10-evdev.conf et 10-quirks.conf .

À l'instant où j'écris, donc après avoir quitté Arch (sur hda1) et redémarré avec Slitaz (sur hda9), puis monté hda1 au point /mnt/hda1 je lis ceci :

Code : Tout sélectionner

$ cat /mnt/hda1/var/log/Xorg.0.log | grep EE
[    30.717] Current Operating System: Linux mercure 2.6.36-ARCH #1 SMP PREEMPT Wed Nov 24 06:44:11 UTC 2010 i686
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    31.112] (II) Loading extension MIT-SCREEN-SAVER

Autrement dit : rien ! Plus globalement, voici la fin du contenu de ce fichier :

Code : Tout sélectionner

[    33.055] (II) No input driver/identifier specified (ignoring)
[    33.056] (II) config/udev: Adding input device PC Speaker (/dev/input/event
3)
[    33.056] (II) No input driver/identifier specified (ignoring)
[    33.061] (II) config/udev: Adding input device Toshiba input device (/dev/i
nput/event5)
[    33.061] (**) Toshiba input device: Applying InputClass "evdev keyboard cat
chall"
[    33.061] (**) Toshiba input device: always reports core events
[    33.061] (**) Toshiba input device: Device: "/dev/input/event5"
[    33.061] (--) Toshiba input device: Found keys
[    33.061] (II) Toshiba input device: Configuring as keyboard
[    33.061] (II) XINPUT: Adding extended input device "Toshiba input device" (
type: KEYBOARD)
[    33.061] (**) Option "xkb_rules" "evdev"
[    33.061] (**) Option "xkb_model" "evdev"
[    33.061] (**) Option "xkb_layout" "us"
[   207.618] (II) TRIDENT(0): Overriding Horizontal timings.
[   207.619] (II) TRIDENT(0): Shadow off
[   207.619] (II) TRIDENT(0): H-timing shadow registers: 0xa3           0x00 0x
84 0x94
[   207.619] (II) TRIDENT(0): H-timing registers:        0xa3 0x7f 0x7f 0x00 0x
84 0x94
[   207.619] (II) TRIDENT(0): V-timing shadow registers: 0x24 0xf5 0x03 0x09   
        0x24 (0x08)
[   207.619] (II) TRIDENT(0): V-timing registers:        0x24 0xf5 0x03 0x09 0x
ff 0x00 0x24
[   207.619] (II) TRIDENT(0): Setting BIOS Mode Regs: 31 63 for: 1024x768
[   207.622] (II) TRIDENT(0): Found Clock  65.00 n=219 m=23 k=1
[   220.006] (II) Toshiba input device: Close
[   220.007] (II) UnloadModule: "evdev"
[   220.007] (II) ImPS/2 Logitech Wheel Mouse: Close
[   220.007] (II) UnloadModule: "evdev"
[   220.007] (II) AT Translated Set 2 keyboard: Close
[   220.007] (II) UnloadModule: "evdev"
[   220.007] (II) Video Bus: Close
[   220.007] (II) UnloadModule: "evdev"
[   220.007] (II) Power Button: Close
[   220.007] (II) UnloadModule: "evdev"

Et là, je pose la question :

Bizarrement, au bout d'un temps long que je n'ai pas réussi à cerner (peut-être 15mn, sans doute plus) le démarrage de la session graphique finit quand même par se faire, mais mon clavier azerty est reconnu comme qwerty.

Je me suis aussi demandé si mon rc.conf ne contenait pas quelque chose qui perturbe udev et/ou Xorg. Je n'en ai aucune idée mais voici le diff correspondant, si ça vous inspire :

Code : Tout sélectionner

$ diff /mnt/hda1/etc/rc.conf /mnt/hda1/etc/rc.conf.pacnew 
--- /mnt/hda1/etc/rc.conf       Tue Nov 16 23:44:27 2010
+++ /mnt/hda1/etc/rc.conf.pacnew        Sat Nov 20 12:27:27 2010
@@ -15,11 +15,11 @@
 # CONSOLEMAP: found in /usr/share/kbd/consoletrans
 # USECOLOR: use ANSI color sequences in startup messages
 #
-LOCALE="fr_FR.UTF-8"
+LOCALE="en_US.UTF-8"
 HARDWARECLOCK="localtime"
-TIMEZONE="Europe/Paris"
-KEYMAP="fr-pc"
-CONSOLEFONT="lat9w-16"
+TIMEZONE="Canada/Pacific"
+KEYMAP="us"
+CONSOLEFONT=
 CONSOLEMAP=
 USECOLOR="yes"
 
@@ -46,7 +46,7 @@
 #
 # HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
 #
-HOSTNAME="mercure"
+HOSTNAME="myhost"
 
 # Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
 #
@@ -69,8 +69,12 @@
 #   - prefix an entry in ROUTES with a ! to disable it
 #
 gateway="default gw 192.168.0.1"
-ROUTES=(gateway)
+ROUTES=(!gateway)
  
+# Setting this to "yes" will skip network shutdown.
+# This is required if your root device is on NFS.
+NETWORK_PERSIST="no"
+
 # Enable these network profiles at boot-up.  These are only useful
 # if you happen to need multiple network configurations (ie, laptop users)
 #   - set to 'menu' to present a menu during boot-up (dialog package required)
@@ -90,4 +94,4 @@
 #   - prefix a daemon with a ! to disable it
 #   - prefix a daemon with a @ to start it up in the background
 #
-DAEMONS=(syslog-ng @network iptables !netfs @crond !gpm !sshd @alsa !cpudyn dbus hal @slim @atd)
+DAEMONS=(syslog-ng network netfs crond)

Conclusion : je suis aussi bloqué que mon écran !

Cordialement,
LuX.

[Emericn6k]

Il y a eu de nombreux changements coté utilisation de hal ces derniers mois...
Avec de nombreuses interfaces graphiques on peut maintenant s'en passer complètement. Pour slim cela dit, je ne sais pas...

Et coté X, on peut théoriquement se passer totalement de xorg.conf.

Essaie éventuellement de :
- retirer hal de tes daemons dans rc.conf
- tenter de démarrer X avec aucun fichier de conf (ni xorg.conf ni fichier dans /etc/X11/xorg.conf.d

Du coup ton /mnt/hda1/etc/hal/fdi/policy/10-keymap.fdi ne devrait plus être utilisé.

[LuX]

Bonjour,

Essaie éventuellement de :
- retirer hal de tes daemons dans rc.conf
- tenter de démarrer X avec aucun fichier de conf (ni xorg.conf ni fichier dans /etc/X11/xorg.conf.d

J'ai d'abord retiré hal, puis slim, et c'est pire : je retombe sur le même écran noir, mais je n'ai plus les consoles tty sur lesquelles je me rabattais avec Alt-F[1-6]. J'ai essayé de reconfigurer Xorg à la main par "Xorg -configure", mais le démarrage avec "Xorg -config /root/xorg.conf.new" donne la même chose, même après remplacement de "vesa" par "trident" sur la ligne ad hoc.

En outre les fichiers de log contiennent maintenant des caractères non textuels en masse. Par exemple pour Xorg.0.log :

Code : Tout sélectionner

                                                                         �   �X
Y       Y       Y)Y.YGYZY3zY6�Y5�5ZOZiZ}Z0�Z�/���Z[[
[ #[D[I[*a[�[)�[-�[C,\5\$G\l\�\*�\�&�d]w]�]�]   �]9�^/^
                                                       E^,R^) ^3�^u�)S_}_%�_�5��
                                                                               `dFd$Zda8^aa%�a+�        bb&)b2Pb�b&�b2�%�? c:`cq�c8
�f�f&�f�*�J"g+mgw�gh%0hDVh��f92f�h"�h�
                                      ��JiPi/`i �i�i�i��j,j,Aj)nj9�j5�k3Ekyk�k��ki�l
m2m6m/Gm,wm&�m&�,�n##nGnOn Unvn�n�nS�n
                                      o+o?oVomo�o�o�o��/�:)pp#�p-�p��Y�pYqrq�qqq�/�r+6r,brE�r/�7sC=s)�s"�s6�+t91tdkt&��H

À un moment, je ne sais plus si c'était dans slim.log ou Xorg.0.log, j'ai lu des messages du type :

"Failed to load module evdev: module does not exist"

Je ne sais pas trop ce que ça veut dire, mais en tout cas xf86-input-evdev est installé.

Ah oui, j'oublais : j'ai aussi tenté une commande "startx" qui m'a amené sur trois hideuses fenêtres de terminal aux bordures vertes, totalement gelées ainsi que la souris. J'ai plusieurs gestionnaires de fenêtres installés (wmii, xfce, lxde...) mais je n'avais jamais vu ce machin-là.

J'comprends rien...

LuX.

[tazzon]

Tu n'as tout simplement pas de .xinitrc dans ton home.

[FoolEcho]

Ah oui, j'oublais : j'ai aussi tenté une commande "startx" qui m'a amené sur trois hideuses fenêtres de terminal aux bordures vertes, totalement gelées ainsi que la souris. J'ai plusieurs gestionnaires de fenêtres installés (wmii, xfce, lxde...) mais je n'avais jamais vu ce machin-là.

Probablement twm avec les 3 xterms indiqué dans le xinitrc de base (fournit par le paquet xorg-xinit) (moi j'adore pourtant, quand tu as ça, tu te dis "*ouf* l'interface graphique marche, un bon truc de fait" ) EDIT: car comme l'indique tazzon, tu n'as probablement pas de .xinitrc dans ton home, mais il en existe un par défaut avec xorg-xinit
Le fait que tout soit "gelé" est lié au non chargement du module evdev par X, c'est ce module qui gère les pilotes claviers/souris. En supprimant les fichiers de xorg.conf.d, tu as privé X d'un certain nombre de configurations spécifiques...

Mais le résultat est fascinant ... jamais vu un log pareil...

Je te conseillerai de repartir en init 3, puis réinstaller et reconfigurer xorg.

[LuX]

Bonjour,

bien vu pour le .xinitirc : j'en avais bien un dans mon home, mais pas dans celui de root quand j'ai tenté startx et compagnie.

Pas besoin de reconfigurer Xorg cela dit car finalement le problème vient de slim. Une fois remis la config antérieure de Xorg (j'ai quand même remplacé le xorg.conf par un xorg.conf.d/20-perso.fr), que je mette ou non hal au démarrage le résultat est le même : slim ne démarre plus (écran noir) alors que lxdm par exemple démarre sans problème.

J'utilise donc lxdm pour le moment, mais je regrette la simplicité de slim. C'est quand même bizarre qu'il ne marche plus. Maintenant que j'ai de nouveau une Arch qui marche, je vais creuser un peu cette question-là dans le forum.

Merci beaucoup pour votre aide

LuX.