Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

{Résolu] Pas de signal vers l'écran

Rafbor

Tu devrais tester l'ancienne alim, sans monter la CG comme décrit dans le post #13 de @ares.

Laadna

Avant de m'embarquer là-dedans, j'ai besoin de comprendre la logique derrière ce test. La manipulation sera longue, je vais encore risquer de casser des trucs. Le ventirad occupe beaucoup d'espace, à chaque manipulation je force dessus et donc sur les supports de la carte mère.

Cette alim a parfaitement fonctionné pendant deux semaines. Je peux booter et afficher l'os sur une distribution live si je débranche les disques durs et que l'écran est branché sur la carte graphique, mais pas si les disques durs restent branchés ou que l'écran est branché sur la carte mère (et ce, que la carte graphique soit débranchée ou pas). Autrement dit, même en soulageant l'alimentation de la carte graphique je perds l'affichage. Je peine vraiment à associer mon problème à une défaillance de l'alimentation.

ares

Laadna a écrit J'aimerais quand même comprendre ce qui vous fait suspecter la carte mère alors qu'une distribution live fonctionne correctement disque débranché, et que le dysfonctionnement a eu lieu juste après une mise à jour de l'os.

Question :
Peux-tu accéder au BIOS dans cette configuration ?
Si oui :
* brancher un des deux disques
* boot en live depuis la clé USB
* accèdes-tu aux dossiers d'un des deux DD branché ?

Zakhar

Si tu as une carte nVidia, ça peut venir de ça :

https://forum.ubuntu-fr.org/viewtopic.php?pid=22400671#p22400671

Solutions dans le post.

Laadna

Je ne peux pas afficher le bios. J'ignore si je suis en mesure d'y accéder, en tout cas dans cette configuration que tu cites la première chose qui s'affiche à l'écran c'est le boot de la distribution live : des lignes de commande automatiques pour gparted, le logo kubuntu pour kubuntu. Matraquer les touches f2 et suppr après la mise sous tension ne change rien.

J'ai essayé de changer l'alimentation et réessayé à peu près tout ce que j'avais déjà essayé (spontanément ou sur suggestion), là aussi sans aucun changement.

Ma carte graphique est une amd, comme je l'ai déjà indiqué.

Zakhar

Laadna a écritMa carte graphique est une amd, comme je l'ai déjà indiqué.

Ok... mais essaye quand même le noyau 5.4.59, ça mange pas de pain, ça prend 10 secondes !

Si c'est ça tu pourras rajouter à le liste des trucs "cassés"... sinon tu auras juste perdu 10 secondes de plus à tâcher de corriger.

Laadna

Comment est-ce que je peux faire ça sans affichage ? Sans disque dur j'imagine que ça n'a pas de sens. Mon problème étant que j'ai au choix, un ordinateur qui fonctionne avec ses disques durs débranchés, ou bien qui semble booter correctement mais n'affiche rien à l'écran (rien de rien, pas de signal hdmi, pas de grub, pas de bios).

Zakhar

Si tu n'as même pas l'affichage du Grub c'est difficile (pas impossible si tu as activé SSH serveur).

Tu peux toujours tenter de booter sur une clé USB avec un noyau 5.4, genre une 20.04.0 ou 20.04.1

Laadna

Je ne sais pas ce qu'est un ssh serveur donc je ne pense pas l'avoir activé. Mais en effet si cette mise à jour perturbe les pilotes graphiques ça pourrait être une piste (depuis le début je soupçonne cette mise à jour, c'était la dernière modification avant la panne et l'ensemble du matériel est quasi neuf et a servi deux semaines tout au plus). Maintenant, comment faire ?

Zakhar a écritTu peux toujours tenter de booter sur une clé USB avec un noyau 5.4, genre une 20.04.0 ou 20.04.1

J'arrive à booter sur une 20.10. Mais en débranchant les disques durs. Donc sans pouvoir intervenir dessus ensuite. Je vais essayer une 20.4 avec les disques durs branchés. Maintenant, j'imagine que gparted live n'est pas concerné par le problème que tu pointes et je n'arrive pas à booter sur gparted lorsque les disques durs sont branchés...

ares

Laadna a écritJe ne peux pas afficher le bios. (...)

Oups !
On sait tromper...

Asus a écritMaintenez la touche <Suppr.> du clavier enfoncée lors du démarrage et entrez dans le
BIOS pour saisir à nouveau les données.

Laadna

La distribution live 20.4.1 ne produit rien de nouveau : elle se charge et s'affiche seulement si les deux disques durs sont débranchés.

J'ai déjà essayé de matraquer les touches f2, f7, suppr au démarrage. Si le bios se charge, il ne s'affiche pas (et donc je n'ai aucun moyen de savoir ce qu'il en est).

ares

Au risque de me répéter...

Asus a écrit10. Cavalier d'effacement de mémoire CMOS (Clear CMOS)
Ce connecteur permet d'effacer la mémoire CMOS RTC des paramètres système
tels que la date, l'heure et les mots de passe.
Pour effacer la mémoire RTC :

1. Éteignez l'ordinateur et débranchez le cordon d'alimentation.
2. Utilisez un objet métallique tel qu'un tournevis pour court-circuiter les deux broches.
3. Branchez le cordon d'alimentation et démarrez l'ordinateur.

4. Maintenez la touche <Suppr.> du clavier enfoncée lors du démarrage et entrez dans le
BIOS pour saisir à nouveau les données.
Si les instructions ci-dessus ne permettent pas d'effacer la mémoire RTC, retirez la pile embarquée
et court-circuitez à nouveau les deux broches pour effacer les données de la RAM RTC CMOS. Puis,
réinstallez la pile.

C'est bien la procédure que tu suivis ?

Laadna

Je n'ai pas trouvé les deux broches à court-circuiter (c'est pas faute d'avoir donné la référence de la carte mère et une photo, visiblement il n'y a pas qu'à moi que cette étape pose problème : je ne comprends pas pourquoi Asus ne produit pas une notice spécifique pour chaque carte mère), mais j'ai bien retiré la pile durant une minute. Cf message #18

Je n'ai aucune idée de si ça a fonctionné, mais ça n'a en tout cas rien changé. Pour le maintient de la touche suppr (ou f2, ça dépend des versions du manuel...), idem je ne sais pas si ça produit quelque chose ou pas, mais rien ne s'affiche.

ares

Si tu n'as pas accédé au BIOS depuis sa mise à jour :

Asus a écritAccéder au BIOS au démarrage du système
Pour accéder au BIOS au démarrage du système, appuyez sur <Suppr.> ou <F2> lors du POST (Power-
On Self Test). Si vous n'appuyez pas sur <Suppr.> ni sur <F2>, le POST continue ses tests.
Accéder au BIOS après le POST
Pour accéder au BIOS après le POST, vous pouvez :
• Appuyer simultanément sur <Ctrl>+<Alt>+<Suppr.>.
• Appuyez sur le bouton de réinitialisation du châssis.
•
Appuyez sur le bouton d'alimentation pour éteindre puis rallumer le système. N'utilisez cette
méthode que si les deux méthodes précédentes ont échoué.
Une fois l'une de ces trois options utilisées, appuyez sur <Suppr.> pour accéder au BIOS.

ares

Laadna a écritJe n'ai pas trouvé les deux broches à court-circuiter (...)

Tu peux faire une photo de la zone des broches AAFP, CLRTC, COM, USB, etc

Laadna

Message #12 : https://www.zegucom.com.mx/productos/A520M-A%20PRO/img_2.jpg

Si j'arrivais à identifier les broches CLRTC, le problème n'existerait pas.

Ceci dit, je persiste à penser que la mise à jour du noyau est une piste qui en vaut plus la peine. Je n'ai effectué aucune intervention sur la carte mère, à part justement retirer cette pile. Et casser son loquet au passage. Raison pour laquelle j'aimerais vraiment limiter les manipulations.

Rafbor

Si tu as un problème de noyau, il ne peut se manifester que lorsque le système Linux se lance, donc après la phase d'init du bios.

Pour info, j'ai eu une fois un clavier qui n'était pas reconnu à l'init, seulement quand le système avait booté, d’où impossibilité d'accéder au bios. Je devais brancher un clavier PS/2 pour y accéder, mais c'était un vieux PC. Essaie de brancher le tien sur un autre port Usb.

Laadna

J'ai essayé deux claviers différents sur trois ports usb différents. Les claviers réagissent puisqu'ils déclenchent un reboot (avec ctrl+alt+suppr), s'allument et pilotent correctement les distributions live.

ares

Laadna a écrit Si j'arrivais à identifier les broches CLRTC, le problème n'existerait pas.(...)

Ne cherche pas !
Tu nous as donné le lien d'une notice Asus et une photo de CM MSI ayant presque la même référence !

Tu confirmes que c'est bien une CM MSI ?
Si oui :
Pour le "reset materiel", MSI donne la méthode et c'est ICI

Opération "reset materiel" (page 56 de la notice) :
* Ordi "off" et débranché
* placer le "jumper" sur le connecteur JBAT1
* temps 10 secondes
* enlever le "jumper" du connecteur JBAT1
Le connecteur JBAT1 est à côté de la pile CMOS

Opération "reset materiel" terminé :
* carte graphique débranchée et retiré du slot PCI de la CM !
* écran branché sur la sortie vidéo CM
Allumer le PC puis touche DEL ou "Suppr" pour accéder au "BIOS".

Laadna

En effet, c'était bien une msi. T'as l’œil et moi je suis une nouille.

Bon, pas de changement après reset de la carte mère. Carte graphique débranchée et disques durs débranchés je ne peux pas booter sur du live. Carte graphique rebranchée je peux booter, mais tant que je n'ai pas rebranché l'écran sur la carte graphique le branchement sur la carte mère n'affiche rien. J'ai aussi testé un boot sur la distribution live avec les deux écrans branchés : les deux sur la carte graphique c'est bon, par contre celui branché sur la carte mère est toujours éteint et n'est pas reconnu dans l'interface de gestion des écrans.

Je ne sais toujours pas si l'appui sur suppr produit quelque chose durant le boot. Pas plus que f11 (c'est la touche qui permet d'accéder au menu de boot, avec le bon manuel c'est plus pratique pour ce genre d'informations !).

J'en ai profité, là aussi avec le bon manuel, pour regarder quelle était cette diode qui s'allume brièvement (une dizaine de secondes) sur la carte mère : c'est justement un outil de diagnostic qui indique "GPU is not detected or fail". La diode finit par s'éteindre, avec ou sans boot sur la distribution live et au bout de la même durée. J'ai aussi branché le buzzer de la carte mère (maintenant que j'ai pu voir où le brancher) : il donne un bip long et deux courts au démarrage (même en bootant sur la clé). Mais je ne vois rien dans le manuel qui indique comment l'interpréter.

Ceci étant dit, je ne voudrais pas perdre de vue l'essentiel : le post, boot, grub ne s'affichait déjà pas lorsque l'ordinateur fonctionnait correctement (l'écran restait éteint et s'allumait pour afficher l'écran de chargement de kubuntu). En fait, jusqu'au chargement de kubuntu, je ne vois pas de différence avec l'avant-panne (même la diode s'allumait de la même façon). J'entends bien que ce sont de précieux outils de diagnostic et de résolution, mais ce n'est pas le but de la réparation. Il y a quelque chose à voir avec les disques durs et/ou l'os, ça me semble évident.

« Page précédente Page suivante »