[boot] plus d'affichage graphique après mises à jour (résolu

[mimile]

Bonjour,

Je viens de faire une mise à jour système (voir ce poste http://forums.archlinux.fr/topic10343.html).

A priori, rien de bien particulier mais problème : au reboot, après affichage des lignes de démarrage qui semblent normales, habituellement, l'écran passait brièvement au noir en me demandant mon login et mot de passe pour afficher quasi immédiatement l'écran d'accueil graphique (un genre de papier peint bleu à bandes verticales) avec demande du choix de l'utilisateur et son mot de passe.

Or, maintenant, au lieu d'afficher l'écran d'accueil, l'écran passe au noir total avec un prompt inerte dans le coin supérieur gauche de l'écran.

Tout est complètement freezé et je n'ai pas d'autre choix que d'arrêter le PC à l'arraché.

Je précise aussi que les lignes qui défilent au démarrage sont affichées dans une police de caractère beaucoup plus grande que d'habitude.

Je peux sans problème accéder aux partitions Archlinux depuis une autre distro (actuellement, je suis sous Squeeze) et espère qu'une des grosses têtes du forum pourra me sauver la mise car je viens de me rendre compte que ma sauvegarde sur un DD externe était foireuse.

A toutes fins, voici les lignes de pacman.log concernant la mise à jour de ce matin :

Code : Tout sélectionner

[2012-02-13 09:29] Running 'pacman -Sy'
[2012-02-13 09:29] synchronizing package lists
[2012-02-13 09:29] Running 'pacman -S --ignore smplayer -u'
[2012-02-13 09:29] starting full system upgrade
[2012-02-13 09:30] upgraded kmod (4-2 -> 5-2)
[2012-02-13 09:30] ATTENTION UDEV:
[2012-02-13 09:30] ----------
[2012-02-13 09:30] udev-compat has been removed, and should be uninstalled.
[2012-02-13 09:30]  --
[2012-02-13 09:30] Framebuffers are no longer blacklisted by default.
[2012-02-13 09:30]  --
[2012-02-13 09:30] binaries moved from /sbin to /usr/bin
[2012-02-13 09:30] ---------------
[2012-02-13 09:30] upgraded udev (180-1 -> 181-2)
[2012-02-13 09:30] upgraded initscripts (2012.01.3-1 -> 2012.02.1-1)
[2012-02-13 09:30] upgraded mkinitcpio (0.8.2-1 -> 0.8.2-2)
[2012-02-13 09:31] upgraded thunderbird (10.0-2 -> 10.0.1-1)
[2012-02-13 09:31] upgraded thunderbird-i18n-fr (10.0-1 -> 10.0.1-1)
[2012-02-13 09:31] upgraded twisted (11.1.0-1 -> 12.0.0-1)

Merci pour votre aide.

Amialement,

[onyx67]

au reboot, après affichage des lignes de démarrage qui semblent normales, habituellement, l'écran passait brièvement au noir en me demandant mon login et mot de passe pour afficher quasi immédiatement l'écran d'accueil graphique (un genre de papier peint bleu à bandes verticales) avec demande du choix de l'utilisateur et son mot de passe

D'après ton descriptif, je suppose que tu as un environnement Gnome.
Faudrait voir du côté de ~/.xsession-errors
J'ai eu un problème similaire y a pas longtemps après une mise à jour. Une simple mise à jour de dbus à suffit pour que tout rentre dans l'ordre.
A tenter...

[mimile]

Merci pour ta réponse.

Effectivement, mon interface est Gnome (restreint).

Voici les lignes contenues dans ~/.sessions-errors (du moins, celle qui sont apparues au reboot après les mises à jour (les autres erreurs sont sans intérêts - en fait, elle rapportent des problèmes liés à mon thème Superkaramba).

Cela dit, n'étant pas en mesure d'utiliser pastebin, je me vois obligé d'afficher ces lignes ici :

Code : Tout sélectionner

(gnome-settings-daemon:878): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
[1329121497,000,xklavier.c:xkl_engine_start_listen/] 	The backend does not require manual layout management - but it is provided by the application
** (gnome-fallback-mount-helper:938): DEBUG: ConsoleKit session is active 0

(polkit-gnome-authentication-agent-1:928): Gdk-WARNING **: polkit-gnome-authentication-agent-1: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.


(notification-daemon:933): Gdk-WARNING **: notification-daemon: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.


(nm-applet:937): Gdk-WARNING **: nm-applet: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.


(gnome-fallback-mount-helper:938): Gdk-WARNING **: gnome-fallback-mount-helper: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.


(gnome-screensaver:940): Gdk-WARNING **: gnome-screensaver: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.


(bluetooth-applet:935): Gdk-WARNING **: bluetooth-applet: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.

kdeinit4: Fatal IO error: client killed
klauncher: Exiting on signal 15

(evolution-alarm-notify:929): Gdk-WARNING **: evolution-alarm-notify: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.

kdeinit4: kded4 [kdeinit]: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.0.

(gnome-sound-applet:936): Gdk-WARNING **: gnome-sound-applet: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.

g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

Received signal:15->'Complété'
g_dbus_connection_real_closed: Remote peer vanished with error: Error receiving message: Connection reset by peer (g-io-error-quark, 0). Exiting.
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

Received signal:15->'Complété'
Received signal:15
Tracker-Message: Closed sqlite3 database:'/home/okapi/.cache/tracker/meta.db'

OK

nautilus: xcb_io.c :528 : _XAllocID:  L'assertion « ret != inval_id » a échoué.

(tracker-miner-fs:930): GLib-GIO-CRITICAL **: Error while sending AddMatch() message: La connexion est fermée

(tracker-miner-fs:930): GLib-GIO-CRITICAL **: Error while sending AddMatch() message: La connexion est fermée

(tracker-miner-fs:930): GLib-GIO-CRITICAL **: Error while sending AddMatch() message: La connexion est fermée

(tracker-miner-fs:930): GVFS-RemoteVolumeMonitor-WARNING **: cannot remove match rule 'type='signal',interface='org.gtk.Private.RemoteVolumeMonitor',sender='org.gtk.Private.AfcVolumeMonitor',': org.freedesktop.DBus.Error.Disconnected: Connection was disconnected before a reply was received

(tracker-miner-fs:930): GVFS-RemoteVolumeMonitor-WARNING **: cannot remove match rule 'type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.gtk.Private.AfcVolumeMonitor'': org.freedesktop.DBus.Error.Disconnected: Connection is closed

OK

Cela dit, quand tu écris :

J'ai eu un problème similaire y a pas longtemps après une mise à jour. Une simple mise à jour de dbus à suffit pour que tout rentre dans l'ordre.

Je suis dubitatif car en ce qui me concerne, je n'ai plus du tout d'accès fut-ce en ligne de commande à Arch de sorte que je vois mal comment je pourrais faire une mise à jour.

En fait, je soupçonnais plutôt kmod passé de la version 4-2 ) la 5-2 ou udev passé de la version 180-1 à la version 180-2 et un simple pacman -U pourrait peut-être résoudre la question mais comment faire ????

[Debaru]

un simple pacman -U pourrait peut-être résoudre la question mais comment faire ????

Tu peux démarrer sur un live CD, tu modifies ton inittab pour ne pas démarrer sur GDM, et là tu devrait être en mesure de lancer ton pacman et vérifié en lançant startx à la mimine si ça fonctionne.

[FoolEcho]

Tu peux démarrer sur un live CD, tu modifies ton inittab pour ne pas démarrer sur GDM

Pas besoin. Il suffit de passer "3" au démarrage du menu de ton chargeur de démarrage (grub ou autre) sur la ligne du kernel (si tu démarres gdm par ton inittab, sinon faut passer 1 et démarrer les services à la main). Si même dans ce mode, ça ne passe pas, il te faudrait faire un chroot (et là, effectivement, livecd ou autre distribution déjà présente s'impose).

C'est accessoire, mais bon:

Cela dit, n'étant pas en mesure d'utiliser pastebin

Pastebin fonctionne en ligne de commande... tant que tu as du réseau, ça doit passer.

[mimile]

Voici les nouvelles du front :

En neutralisant mon inittab (via Squeeze), j'ai effectivement pu rester en ligne de commande.

J'ai ainsi pu neutraliser mes mises à jour (voir le pacman.log plus haut) excepté twisted (pkg ne contenant pas ou plus la version 11) ni thunderbird qui ne joue certainement aucun rôle dans l'affaire.

J'ai ensuite rétabli inittab comme il l'était (démarrage avec gdm) puis j'ai rebooté.

Affichage des lignes redevenu petit comme auparavant, passage en tty1 puis écran noir et au bout de quelques instants ceci :

http://i.imgur.com/VL2U8.jpg

A tout hasard, voici la 1ère ligne du texte (qu'on ne voit pas sur la photo) :
X.org X Series 1.11.4

Pouvez-vous en tirer quelque chose ?

EDIT : un mystère informatique de plus ...
Je me dis : je vais envoyer (avec pastebin) mon var/log/Xorg/xorg.0.log.
donc je boot Arch en m'attendant comme les 3 ou 4 fois précédentes à me retrouver en ligne de commande.

Que nenni ! démarrage normal de Gnome et problème a priori résolu (je me méfie quand même, que ce serait un coup de chance ... )

Quoi qu'il en soit, je voudrais bien savoir laquelle de ces mises à jour a provoqué mon problème : udev, kmod, initscripts, mkinitcpio ???

Inituitivement, j'inculperais udev car j'ai déjà lu à plusieurs reprises des postes un similaire où udev était le coupable.

[FoolEcho]

Inituitivement, j'inculperais udev car j'ai déjà lu à plusieurs reprises des postes un similaire où udev était le coupable.

Je dirai ça aussi.
Facile à vérifier.

[mimile]

Oui, en réinstallant sa mise à jour pour constater que le problème surgit à nouveau, ce qui, de toute façon ne fournira aucune indication sur le pourquoi du comment.

Mais c'est plutôt fastidieux de rétablir la situation et je dois dire que, pour l'instant, je me contente de savourer le plaisir d'avoir retrouver ma petite Arch intacte.

Amicalement,



Cela dit,

[FoolEcho]

... isoler le problème permet de le faire remonter (un certain nombre de sujets récents ont l'air d'impliquer la même chose).

[mimile]

RE-

Bon, je me suis dit qu'il fallait quand même bien essayer de trouver le responsable.

J'ai donc fait une mise à jour complète du système en excluant udev, partant du principe que si tout se passait bien, on tenait le coupable.

Et bien, non !

Après la fin des mises à jour, reboot du PC et même plantage qu'hier.

Problème réglé beaucoup plus vite puisque je savais ce que j'avais à faire.

Les deux seuls points communs entre les mise à jour d'hier et celles d'aujourd'hui concernait kmod (passé de la version 4-2 à la version 5-2) et mkinitcpio (passé de 0.8.2-1 à 0.8.2-2).

J'ai restauré leurs anciennes versions et j'ai pu reprendre la main.

Je vais essayé de faire une mise à jour de udev pour l'écarter définitivement de la liste des suspects.

Je reviens tout de suite.

Me revoilà et rien ne tourne comme prévu.

J'ai fait une mise à jour en excluant kmod (uniquement) et bardaf, plantage du PC remis en route en restaurant l'ancienne version.

En résumé, j'ai fait des mises à jour Syu en excluant successivement

- udev --> plantage
- kmod --> plantage
- mkinitcpio --> plantage

A noter que initscripts est modifié par udev et qu'il faut restaurer sa version antérieure pour retrouver un système fonctionnel.

Peut-être que mon PC devient trop vieux ...

Ca va commencer à devenir pénible si, à chaque mise à jour, je dois exclure tous ces paquets de la liste (en plus de smplayer).

En fait, je crois que udev, initscrpits, mkinitcpio et kmod sont d'une manière ou d'une autre interdépendants et qu'il suffit que l'un d'eux (et a fortiori tous les quatre) soient mis à jour pour planter mon PC.

Les 4 coupables :



A noter que je me demande pourquoi yaourt ne me propose pas la mise à jour du nouveau noyau ...

[tuxce]

A noter que je me demande pourquoi yaourt ne me propose pas la mise à jour du nouveau noyau ...

Comment tu sais que tu as un noyau à mettre à jour ?

Sinon, je vois pas trop comment vous en êtes arrivé à parler d'udev / mkinitcpio / etc., d'après ce que j'ai lu (mais j'ai du rater un truc), ton souci, c'est X, et il ne démarre pas parce qu'il ne trouve pas un module (pourquoi, ça c'est une autre histoire)

EDIT: le truc que j'ai raté, c'est peut être la mise à jour d'udev qui a supprimé le blacklist des framebuffer, ajoutes un fichier /etc/modprobe.d/fb.conf avec:

Code : Tout sélectionner

blacklist nvidiafb

[mimile]

Salut Tuxce

Désolé, mais j'ai zappé ta réponse précédente car hier soir, je me suis mis au lit assez tôt vu que depuis deux jours, j'ai une grippe ou autre saloperie qui maintient ma température au-dessus de 38,5° et qui me met à plat.

Bref, j'ai fait comme tu l'as indiqué : j'ai créé un fichier db.conf dans le répertoire /etc/modprobe.d, fichier dans lequel j'ai écrit : blacklist nvidiafb

Puis, j'ai fait un installation complète qui a donc procédé à la mise à jour de udev, kmod, mkinitcpio et initscripts après quoi, patatras, nouveau plantage au reboot.

Bon, je commence à avoir l'habitude de tout remettre en état mais je crains qu'un de ces quatre, les anciens fichiers qui permettent la récupération du système disparaissent ; à tout hasard, je vais en transférer des copies dans un autre dossier.

Cela dit, ça ne fait pas avancer le schmilblick ...

Amicalement,

PS : pour éviter des méprises et confusions, et si tu le veux bien, je te suggère de ne plus intervenir que sur ce poste et je vais mentionner l'autre comme étant clôturé.

PS-bis : pour ce qui concerne le nouveau noyau, il apparaissait dans la liste des nouveautés de la page d'accueil d'hier. Vérification faite, il n'était disponible que dans le dépôt "testing" que je n'utilise pas.

PS-ter :

Code : Tout sélectionner

Sinon, je vois pas trop comment vous en êtes arrivé à parler d'udev / mkinitcpio / etc., d'après ce que j'ai lu (mais j'ai du rater un truc), ton souci, c'est X, et il ne démarre pas parce qu'il ne trouve pas un module (pourquoi, ça c'est une autre histoire)

On en est venu à cette conclusion pour la simple raison que mon PC plante quand je mets ces 4 logiciels à jour (et à mon avis, ils interfèrent entre eux car j'ai passé mon temps à faire des mises à jour un logiciel suspect à la fois et tous les 4 séparément ont le même impact négatif

D'après la photo que j'ai faite (voir ici : http://i.imgur.com/VL2U8.jpg, apparemment, le plantage provient du fait qu'il n'arrive pas à charger le pilote nvidia (et pour cause, il n'y en a pas d'adapté à ma carte et en principe c'est "nouveau" qui doit être chargé.

[tuxce]

La tentative de chargement du pilote "nvidia" est normal, son échec aussi, ce qui l'est moins, c'est de ne pas pouvoir trouver le fichier .so fourni par nouveau-dri.
Il nous faudrait le log de X (/var/log/Xorg.0.log), la liste des modules chargé (tu peux d'ailleurs vérifier que nvidiafb ne se charge pas), ainsi que l'état du paquet nouveau-dri. Tu peux faire ça depuis la console:

Code : Tout sélectionner

pastebin /var/log/Xorg.0.log
lsmod | pastebin
ls -l /usr/lib/xorg/modules/dri/nouveau_* | pastebin

Pour ce qui est de remettre les mise à jour, tu peux temporairement te passer de nouveau et démarrer en vesa, c'est pas idéal, mais ça t'évite de redémarrer / réinstaller / ... à chaque fois

Pour le fichier /etc/modprobe.d/fb.conf que je t'ai demandé de créer, udev sur [testing] ajoutera le sien et d'ailleurs il blackliste aussi rivafb, tu peux donc l'ajouter à /etc/modprobe.d/fb.conf pour voir ce que ça donne.

Code : Tout sélectionner

blacklist nvidiafb
blacklist rivafb

[mimile]

Je vais exécuter ce que tu me dis mais pour éviter toute confusion, je précise ceci :

Pour l'instant, j'utilise les anciennes versions des 4 paquets suspects et Arch tourne correctement.

Les résultats des commandes ci-dessous correspondent donc à un état où Arch tourne correctement :

pastebin /var/log/Xorg.0.log : http://pastebin.archlinux.fr/438226
lsmod | pastebin : http://pastebin.archlinux.fr/438227
ls -l /usr/lib/xorg/modules/dri/nouveau_* | pastebin
ls: impossible d'accéder à /usr/lib/xorg/modules/dri/nouveau_*: Aucun fichier ou dossier de ce type

Pour ta gouverne, voici ce que contient /usr/lib/xorg/modules/dri :



Bon, je vais blacklister rivafb puis me mettre en panne (en installant les paquets foireux et t'envoyer les mêmes résultats

A ton prochain message, pourrais-tu m'expliquer comment faire pour faire en sorte d'utiliser vesa plutôt que nouveau ?

EDIT : me revoici avec le rouge de la honte aux joues ...

Quand tu m'a suggéré de créer un fichier fb.conf dans /etc/modprobe.d pour y blacklister nvidia, j'ai fait une faute de frappe et j'ai en fait créé un fichier fg.conf (faute d'inattention due sans doute à mon état grippal).

Puis, dans de ton dernier message, tu m'as suggéré d'y ajouter rivafb et c'est alors que je me suis rendu compte de mon erreur - immédiatement rectifiée.

Installation Syu sans exclusion (sauf smplayer qui continue de me poser problème) et redémarrage normal.

Problème enfin résolu !!!

Reçois toute mon admiration pour l'étendue de tes connaissances, et la patience dont tu as fait preuve à mon égard.

Encore mille mercis

[tuxce]

Préfère toujours du texte à une image ... une image, on peut rien y faire, pas de copie / coller, ça prend de la place sur un petit écran et ça n'apporte pas grand chose voire même, ça ne donne pas toutes les infos. Pour le répertoire, tu pouvais faire un:

Code : Tout sélectionner

ls -l /usr/lib/xorg/modules/dri/ | pastebin

ou juste copier la sortie vu que t'avais accès à l'interface graphique.
Ceci dit, j'ai pas compris comment tu as résolu le problème ...

Je vois que tu n'as pas le fichier /usr/lib/xorg/modules/dri/nouveau_vieux_dri.so et donc à priori, tu devrais installer nouveau-dri.
Par contre, je viens de me rendre compte d'un truc, X ne plante même pas, tu as une erreur mais X continue son démarrage.

Content que ça fonctionne mais si tu peux en dire plus (le nom du fichier .conf n'a pas d'importance, tout fichier /etc/modprobe.d/*.conf est pris en compte )

[mimile]

La capture d'écran me semblait le moyen le plus rapide pour montrer ce que contenait /dri.

Voici son équivalent pastebin après installation des programmes suspects : http://pastebin.archlinux.fr/438228

Pour le surplus, si je t'ai bien compris, que je me sois trompé dans le nom du fichier *.conf de /etc/modprobe.d n'avait aucune importance ?

Alors, c'est peut-être le fait d'y avoir ajouter (blacklister) rivafb qui a réglé le problème (il était d'ailleurs blacklister dans /lib/modprobe.d/framebuffer_blacklist.conf

En ce qui concerne nouveau-dri, je viens de l'installer et voici ce que ça donne maintenant au niveau des modules/dri : http://pastebin.archlinux.fr/438229

Il y est maintenant.

Ne me reste qu'à tenter un reboot en croisant les doigts car ici pas d'ancienne version à restaurer au cas où ...

EDIT : me revoici après reboot : pas de problème mais pas de différence de comportement.

J'espérais une amélioration au niveau de mon accélération graphique mais glxgaers ne fonctionne plus (ce petit programme qui affiche des roues dentées rotatives en indiquant le nombre de frames par seconde.

Code : Tout sélectionner

[okapi@Archie ~]$ glxgears
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  28
  Current serial number in output stream:  30

Serait-ce dû au blacklistage de nvidiafb ou de rivafb ?