Bonjour,
J’ai installé récemment Buster en dual boot UEFI avec Windows 8.1. La racine est sur un SSD et le Home sur un disque dur.
L’installation plante régulièrement sans raison apparente : au lancement d’une application, au survol d’une icône… La seule façon de récupérer le système est de faire un hard reset.
Je ne sais pas comment diagnostiquer cette panne. Pourriez-vous m’aider ?
Sylvain
déjà regardes les messages d’erreur du démarrage
dmesg|egrep -i "error|warning|Reason"
tu connais aussi reisub ? http://www.dindoun.lautre.net/spip.php?article17
et puis donne un peu d’indications
Bonjour,
La commande me renvoie :
« dmesg: échec de lecture du tampon de noyau: Opération non permise »
Quant à donner plus d’indication j’aimerais bien… Le plantage bloque toutes les commandes, je ne peux rien faire. La souris ne bouge plus. Je ne peux pas changer de console. Le clavier ne réagit plus. Bref, le système est gelé. Et cela peut arriver n’importe quand : après 5 minutes ou une heure.
Le problème est que je ne sais pas où regarder pour donner plus d’indications.
Sylvain
il faudrait que tu redémarres sur une clé, que tu accèdes au disque dur et que tu regardes les fichiers dmesg.log dans le dossier /var/log/
J’ai tenté la manipulation après un plantage Buster. J’ai booté à partir d’une clé et ouvert le répertoire /var/log de Buster sans trouver le fichier dmesg.log. Impossible par ailleurs d’ouvrir les autres fichiers de /var/log faute de droit.
normal
il faut le faire en sudo
et puis j’ai fait une erreur : le ficheir s’appelle dmesg san le .log
et puis il faut aussi regarder les dmesg.0 voir les dmesg.#.gz
J’aurais du penser au SUDO… merci.
Mais je confirme qu’il n’y a pas de fichier dmesg dans le /var/log… c’est symptomatique ?
dmesg n’est pas le nom d’un quelconque journal qui serait dans le répertoire /var/log. C’est le nom d’une commande 
Extrait de
man dmesg
NOM
dmesg - Afficher et contrôler le tampon circulaire du noyau
..
DESCRIPTION
dmesg est utilisé pour examiner ou contrôler le tampon circulaire du noyau.
L'action par défaut est d’afficher tous les messages du tampon circulaire du
noyau.
Dans /var/log on trouve un certain nombre de journaux comme /var/log/messages qui ont l’avantage d’être plus lisibles : j’y vois tout de suite que j’ai fait sortir la machine de l’hibernation à 9h30m 14 sec alors que l’horodatage dans la sortie de dmesg est un nombre de secondes depuis un zéro qui correspond au dernier démarrage du système du genre 102371.459474.
De plus il faut taper
sudo /bin/dmesg
pour des problèmes de droits, alors que
less /var/log/messages
fonctionne pour peu que vous fassiez partie du groupe adm
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
Pour avoir la date/heure complète,
on peut utiliser l’option T de la commande dmesg
root@debT450:~# dmesg -T | tail
[mer. juin 17 19:39:13 2020] Bluetooth: hci0: command 0xfc8e tx timeout
[mer. juin 17 19:39:14 2020] fuse init (API version 7.27)
[mer. juin 17 19:39:16 2020] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[mer. juin 17 19:39:16 2020] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready
[mer. juin 17 19:39:22 2020] Bluetooth: hci0: sending Intel patch command (0xfc8e) failed (-110)
[mer. juin 17 19:39:22 2020] Bluetooth: hci0: sending frame failed (-19)
[mer. juin 17 19:39:24 2020] Bluetooth: hci0: Exiting manufacturer mode failed (-110)
[mer. juin 17 19:39:24 2020] Bluetooth: hci0: command 0xfc11 tx timeout
[mer. juin 17 19:44:58 2020] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[mer. juin 17 19:50:11 2020] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
root@debT450:~#
tout à fait.
les messages sont écrits légèrement différemment
ils sont plus nombreux dans messages.
n’oublie de vérifier que tu appartiens au groupe adm ( groups )
A la lecture des dernières lignes des journaux après plantage, il semble que le plantage soit dû au pilote « nouveau ». Je vais tenter d’installer les pilotes nvidia.
Depuis le passage en init par systemd , on peut utiliser la commande journalctl
https://www.freedesktop.org/software/systemd/man/journalctl.html
Exemple
journalctl -p err
journalctl -f
Bon, il semblerait que le problème soit résolu : plus de deux jours sans plantage…
Le problème viendrait bien du pilote graphique Nouveau. J’ai installé le pilote NVidia et le paquet firmware-misc-nonfree car les logs m’indiquaient qu’il manquait des firmwares pour Nouveau.
Donc je me retrouve avec deux pilotes graphiques. Cela ne semble pas poser soucis à l’utilisation mais je n’aime pas trop ça…
En tout cas, a priori, problème résolu… merci pour votre aide !