[mise à jour] hors de portée au démarrage (résolu !)

[mimile]

Bonjour,

Je viens de faire une mise à jour complète au cours de laquelle le noyau est passé de 3.6... à 3.7...

Il y a avait aussi deux autres mises à jour (liwebkit et un autre programme dont je n'ai pas noté le nom).

Au démarrage suivant d'Arch, j'ai à peine le temps de lire la 1ère ligne puis l'écran devient noir avec comme message "hors de portée".

J'en déduis que les réglages d'affichage ont été modifiés en augmentant au-delà de la limite la fréquence de rafraichissement ou quelque chose comme ça.

Je ne trouve pas le fichier où les réglages de l'image sont indiqués.

Pouvez-vous m'aider ?

Merci d'avance.

PS : les autres distro Linux démarrent sans problème (j'écris actuellement sous Manjaro mais je peux avoir accès aux fichiers d'Arch sans problème).

[tuxce]

Salut, commence par désactiver X s'il démarre en auto, et ensuite, c'est comme d'habitude, si en désactivant X, tu as accès au système, lance X manuellement, regarde/poste les logs, etc... il n'y a pas de magie

Il y a avait aussi deux autres mises à jour (liwebkit et un autre programme dont je n'ai pas noté le nom).

Tout est dans /var/log/pacman.log, vu que t'as accès aux fichier d'Arch, c'est dommage de pas y jeter un coup d'oeil. (il y a aussi les logs de X, mais bon, faut déjà s'assurer que le souci vient de là)

[mimile]

Bonjour

Voici le var/log/pacman.log après quoi j'ai rencontré mon problème : http://pastebin.archlinux.fr/455637

Pour le surplus, je suis en full systemd et j'utilise gnome restreint.

Je crois qu'il est lancé par gdm.service.

J'ai à peine le temps de lire la première ligne (udev quelque chose) que l'écran s'éteint et affiche "hors de portée" (le témoin lumineux passe du vert à l'orange comme quand on allume l'écran sans que le PC soit en marche)

pourrais-tu me dire comment, en pratique, désactiver X depuis un autre OS ? (là, j'utilise Manjaro).

Merci d'avance pour ton aide.

[FoolEcho]

pourrais-tu me dire comment, en pratique, désactiver X depuis un autre OS ? (là, j'utilise Manjaro).

Voir démarrer dans le mode graphique (tu n'as pas besoin de passer par l'autre OS, juste d'éditer le menu au démarrage): http://wiki.archlinux.fr/Grub#Options_temporaires (ou voir syslinux ou autre selon le chargeur utilisé).

[benjarobin]

Je pense que le problème vienne de KMS, donc désactiver X risque de ne pas résoudre le souci, essaye avec l'option nomodeset, mais tu ne pourras pas utiliser X

[mimile]

Bonjour,

Merci de me répondre mais je ne vois pas trop comment faire.

Voici à quoi ressemble la partie de mon grub.cfg (créé par Debian Squeeze) concernant le démarrage d'Arch :

Code : Tout sélectionner

menuentry "Arch Linux" {
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
	linux /boot/vmlinuz-linux root=/dev/sda5 ro
	initrd /boot/initramfs-linux.img
}

@ Foolecho : selon ton lien, à l'affichage du menu grub, il faut enfoncer la lettre e pour afficher ce qui précède ; les paramètres à ajouter sont

Code : Tout sélectionner

setparams 'Arch Linux'
  set root=(hd0,1)
  linux /vmlinuz-linux root=/dev/sda3 ro systemd.unit=multi-user.target
  initrd /initramfs-linux.img

Plutôt que d'utiliser la méthode ci-dessus j'ai édité directement grub.cfg qui ressemble maintenant à ceci :

menuentry "Arch Linux" {
insmod part_msdos
insmod ext2
setparams 'Arch Linux'
set root='(hd0,msdos5)'
# search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
linux /boot/vmlinuz-linux root=/dev/sda5 ro systemd.unit=multi-user.target
initrd /boot/initramfs-linux.img

Malheureusement, ça ne change rien.

@ Benjarobin : j'ai ajouté nomodeset à la fin de la ligne

linux /boot/vmlinuz-linux root=/dev/sda5 ro nomodeset

sans plus de résultat.

Le message "hors de portée" indique probablement que la fréquence de résolution est supérieure à celle que mon écran supporte.

N'y a-t'il pas un fichier à créer dans /etc/X11 (qui imposerait des données correctes (1024x768 60) ?

EDIT : Quand je lance normalement Arch (sans paramètres supplémentaires), j'ai le temps de lire la première ligne :

Code : Tout sélectionner

Running early hooks [udev] 

puis l'écran devient noir (hors de portée) mais j'entends à l'agitation de mes disques que le boot se poursuit ; à l'aveugle, je tape mon mot de passe mais rien ne se produit ce qui ne m'étonne pas vu que les témoins lumineux de mon clavier sont tous éteints (alors qu'en principe, j'ai configuré l'activation du pavé numérique et que le témoin n° 1 devrait être allumé).

[tuxce]

Tu as quoi comme carte graphique ?

[mimile]

VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1)

Une vieille carte intégrée à ma carte-mère (32 Mo) mais qui fonctionne correctement avec mes autres distributions (sans effets 3D évidemment) Driver : nouveau.

Mon écran : 1024x768 - fréquence 60 Mhz

A tout hasard, j'ai créé un fichier 10-monitor.conf dans /etc/X11/xorg.d en indiquant ces valeurs, sans résultat.

J'ai même chrooté depuis Manjaro pour relancer le mkinitcpio en me disant que peut-être, quelque chose s'était mal passé lors de la mise à jour, sans résultat.

En désespoir de cause, j'ai voulu restaurer le noyau précédent 3.6.11-1 mais je ne dispose plus de son paquet dans pkg et je ne sais trop où chercher sur le site Konicchi.

Ma carte graphique serait-elle devenue trop vieille pour ne plus être reconnue ?

EDIT : J'ai installé le noyau 3.7 sur Manjaro et j'obtiens le même résultat (hors de portée).

Je crains fort que ma carte graphique soit définitivement trop vieille pour ce nouveau noyau.

[tuxce]

Il semble que la solution en fin du ticket FD#58776 fonctionne.
Sinon, chroot sur arch et installe le noyau linux-lts, ça te donnera un peu de répit :p

[mimile]

Merci pour ton message.

Je dois honteusement avouer que je ne vois pas bien comment faire concernant la solution mentionnée dans ton lien.

Si j'ai bien compris, il y a un problème avec le driver nouveau.

Pourrais-tu m'expliquer ?

[tuxce]

De la même façon que tu as rajouté nomodeset ou systemd.unit, tu rajoutes nouveau.config=NvPCIE=0 et tu redémarres pour voir.

[mimile]

Bonjour,

J'ai ajouté nouveau.config=NvPCIE=0 successivement à la fin de la ligne "linux /boot ..." puis de la ligne "initrd /boot ..."

menuentry "Arch Linux" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
linux /boot/vmlinuz-linux root=/dev/sda5 ro nouveau.config=NvPCIE=0
initrd /boot/initramfs-linux.img nouveau.config=NvPCIE=0
}

hélas sans résultat

Est-ce bien comme ça qu'il fallait ajouter nouveau.config=NvPCIE=0 ?

[FoolEcho]

L'option sur la ligne initrd n'a aucun sens (et vu que tu dis qu'aucune manipulation ne produit d'effet, y compris le démarrage en mode console, je me demande même si tu édites le bon fichier ... mais bon c'est possible après tout -- c'était quand même plus simple d'éditer les options au démarrage...).

Pour le linux-lts: http://wiki.archlinux.fr/Enhancing_Arch ... _noyau_LTS.

Ceci étant, le noyau a eu une révision (3.7.4) pendant le sujet, donc chroote Arch, met à jour et vois si ça change quelque chose.

[mimile]

Bonjour,

Si j'ai mis nouveau.config=NvPCIE=0 sur la ligne initrd, c'est parce que ça ne donnait rien sur la ligne linux /boot ...

Pour le surplus, j'accède aisément à mon fichier grub.conf (sur Squeeze) depuis un autre de mes OS linux.

Mais tu as raison : c'est plus simple de modifier en éditant le menu grub au démarrage ; on obtient le résultat tout de suite.

Si j'ai ajouté les lignes dans le fichier lui-même, c'est juste pour montrer ce que j'avais fait.

Pour le surplus, il ne fait pas de doute que j'édite le "bon" fichier quand je le compare au menu grub qui s'affiche au démarrage.

Je vais installer le nouveau noyau en croisant les doigts pour que ça résolve le problème (que je ne suis pas seul à rencontrer vu le nombre de sites faisant état de ce problème).

Je ferai retour dès que possible.

EDIT :

J'ai installé le nouveau noyau en chrootant depuis manjaro (pacman -Syu).

Il y a eu quelque message d'erreur au départ de l'installation des paquets téléchargés (impossible de récupérer ...) puis l'installation s'est déroulée normalement.

Hélas, le nouveau noyau n'a pas réglé mon problème.

Je vais donc installer le noyau lts pour voir.

EDIT-BIS : Alleluia !!! avec le noyau lts, j'ai enfin pu booter ma Arch !!!

Bien que ce ne soit pas une solution entièrement satisfaisante (retomber du noyau 3.7.4-11 au 3.6.0 est un peu frustrant et ne pas savoir pourquoi le noyau 3.7.4 est en conflit avec le driver nouveau l'est tout autant), je suis quand même rudement content.

Cela dit, j'ai modifié à la mano mon grub.cfg pour ajouter lts dans les lignes Linux /boot et initrd car, ayant oublié de le faire, un update-grub a pris en compte le noyau 3.7.4 qui reste présent dans /boot.

Comment faire pour le supprimer en douceur ?

En tout cas, (Mi)mille mercis pour ton aide.

[mimile]

Bonjour,

Je reviens sur ce sujet.

Pour mémoire et pour vous éviter de relire tout ce qui précède, le passage du noyau 3.6.11-1 au 3.7.4 empêchait mon PC de booter car, dès la première ligne, l'écran passait au noir avec le message "hors de portée" ; mais manifestement, le boot se poursuivait (activité des disques audible pendant la durée d'un boot normal).

Cela dit, aucune possibilité d'agir : clavier et souris au point mort.

Finalement, sur le Conseil de Foolecho, j'ai installé le le noyau lts (3.6.0) et j'ai ainsi pu booter Arch.

Je continué mes recherches car cette solution ne me plaisait qu'à moitié, notamment parce que le PC ne s'arrête pas complètement (l'écran reste allumé avec en dernier ligne "power down" et le PC continue d'émettre un ronronnement trahissant le fonctionnement du ventilo).

J'ai donc visité le site arm.konnichi.com où j'ai récupéré le paquet du noyau 3.6.11.1 et j'ai downgradé le noyau en cours (3.7.5) vers le 3.6.11.1 ; j'ai indiqué linux dans l'option IgnorePkg de pacman.conf.

Je fonctionne actuellement sans problème avec ce noyau 3.6.11-1.

Question : y-a-t'il un inconvénient/risque à ce que je continue à l'utiliser ?

A noter que la version fallback tourne avec le noyau lts et qu'en cas de malheur, je pourrais toujours me réfugier sur elle.

Merci d'avance pour vos avis éclairé.

Cordialement,

[FoolEcho]

le noyau lts (3.6.0)

3.0.quelquechose, pas 3.6.

Je fonctionne actuellement sans problème avec ce noyau 3.6.11-1.

Question : y-a-t'il un inconvénient/risque à ce que je continue à l'utiliser ?

Tant qu'il n'y a pas de problèmes de dépendances, aucun (ça finira par venir sur mkinitcpio, je pense).

Maintenant le hic est qu'on n'a pas identifié le problème et donc tu/on ne peux/peut pas trop faire remonter la régression pour la résoudre (faut souhaiter que ça soit le bug relevé précédemment par tuxce ... y a de grosses chances quand même ).

[mimile]

Ben oui, la solution suggérée par Tuxce concerne un problème similaire à celui que je rencontre.

Il s'agit de booter avec l'option "nouveau.config=NvPCIE=0"

Je l'avais ajouté à la fin de la ligne "linux ..." dans grub.cfg sans résultat.

Ne faudrait-il pas plutôt le mentionner au niveau des modules dans pacman.conf ? (mon pacman.conf mentionne simplement : MODULES="nouveau")

La, il se fait tard.

J'essayerai demain et ferai retour

Bonne nuit

[tuxce]

pacman.conf ne gère pas les modules !
Tu voulais, je pense, parler de mkinitcpio.conf, mais ce dernier ne gère pas les options de modules.

Par contre tu peux rajouter :

Code : Tout sélectionner

options nouveau config=NvPCIE=0

dans /etc/modprobe.d/nouveau.conf sans oublier de refaire l'initramfs en ayant vérifier que t'as bien le hook modinfo dans /etc/mkinitcpio.conf :

Code : Tout sélectionner

mkinitcpio -p linux

[mimile]

Bonjour,

Effectivement, confusion de ma part entre pacman.conf et mkinitcpio.conf dans mon message précédent.

Dans mkinitcpio.conf, il y a ceci :

Code : Tout sélectionner

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options
# like so:
#    FILES="/etc/modprobe.d/modprobe.conf"
FILES="/etc/modprobe.d/modprobe.conf"

Ce fichier contenait :

Code : Tout sélectionner

options nouveau modeset=1

que j'ai remplacé par

Code : Tout sélectionner

options nouveau NvPCIE=0

J'ai réinstallé le noyau 3.7.5.1 après avoir ajouté "modinfo" dans les HOOKS de mkinitcpio.conf

J'ai rebooté et à la 2ème ligne du boot, j'ai vu apparaître le message

Code : Tout sélectionner

nouveau: invalid paramater NvPCIE

Puis le boot s'est poursuivi jusqu'à la dernière ligne

Code : Tout sélectionner

reaching graphical target interface

Malheureusement, à ce stade stand-by complet.

J'ai ouvert une console TTY et essayé startx en simple utilisateur et en root en n'ayant d'autre résultat qu'une longue liste trop longue à transcrire.

J'ai ré-essayé avec options nouveau nomodeset puis avec modeset=0 puis avec modeset=1 avec le même résultat.

Seul point positif, je n'ai plus de message "hors de portée" au démarrage et je vois défiler la liste des opérations habituelles.

Une idée ?

Merci d'avance

[tuxce]

Je me suis trompé en postant le message, il faut mettre :

Code : Tout sélectionner

options nouveau config=NvPCIE=0

et non

Code : Tout sélectionner

options nouveau NvPCIE=0