General troubleshooting (Français)

From ArchWiki
État de la traduction: Cet article est la version francophone de General troubleshooting. Date de la dernière traduction: 2022-10-03. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Related articles

Cet article donne une méthode générale de dépannage. Pour des problèmes spécifiques à une application qui possède une page dans le wiki, veuillez vous y référer.

Procédures générales

Il est crucial de toujours lire les messages d'erreur qui apparaissent. Parfois, il peut être difficile, par exemple avec les applications graphiques, d'obtenir un message d'erreur correct.

  1. Exécutez l'application dans un terminal afin de pouvoir inspecter la sortie.
    1. Augmentez la verbosité (généralement --verbose/-v/-V ou --debug/-d) s'il n'y a toujours pas assez d'informations pour déboguer.
    2. Parfois, ce paramètre n'existe pas et doit être spécifié en tant que directive dans le fichier de configuration des applications.
    3. Une application peut également utiliser des fichiers journaux, qui sont généralement situés dans /var/log, $HOME/.cache ou $HOME/.local.
    4. S'il n'y a aucun moyen d'augmenter la verbosité, il est toujours possible d'exécuter strace et des opérations similaires.
    5. Vérifiez le journal de systemd. Il est possible qu'une erreur laisse également des traces dans le journal, surtout si elle dépend d'autres applications.
    6. dmesg lit dans le tampon du noyau. C'est utile si le disque est pour une raison quelconque inaccessible, mais cela peut aussi donner lieu à des journaux incomplets car le tampon du noyau n'est pas de taille infinie. Utilisez journalctl si possible.
    7. journalctl a plus d'options de filtrage que dmesg et utilise par défaut des horodatages lisibles humainement.
  2. Il est toujours recommandé de vérifier les traqueurs de bogues pertinents pour voir s'il existe des problèmes connus avec des solutions déjà existantes.
    1. Selon les choix en amonts, il y a généralement un gestionnaire de problèmes et parfois aussi un forum ou même, par exemple, un canal IRC.
    2. Il y a le Arch Linux bugtracker, qui devrait être utilisé principalement pour les bogues d'empaquetage.

Aide supplémentaire

Si vous avez besoin d'une aide supplémentaire, vous pouvez la demander sur le forum francophone ou sur le canal IRC francophone.

Note: L'aide est fourni pour Arch Linux SEULEMENT et non pour les distributions basées sur Arch.

Lorsque vous demandez de l'aide, postez la sortie/les journaux complets, pas seulement ce que vous pensez être les sections importantes. Les sources d'information incluent :

  • La sortie complète de toute commande impliquée - ne sélectionnez pas seulement ce que vous pensez être pertinent.
  • Le journal de systemd.
    • Pour une sortie plus étendue, utilisez le paramètre de démarrage systemd.log_level=debug. Cela produira une quantité énorme de sortie, donc ne l'activez que si c'est vraiment nécessaire.
    • N'utilisez pas le paramètre -x car il encombre inutilement la sortie et la rend plus difficile à lire.
    • Utilisez -b sauf si vous avez besoin des journaux d'un démarrage précédent. Si vous ne spécifiez pas ce paramètre, vous risquez d'obtenir des pâtes extrêmement volumineuses, voire trop volumineuses pour les pastebins.
  • Fichiers de configuration pertinents
  • Pilotes impliqués
  • Versions des paquets concernés
  • Noyau : journalctl -k ou dmesg. (les deux avec les privilèges root).
  • Xorg : selon la configuration, le gestionnaire d'affichage utilisé est également pertinent ici.
    • Xorg.log peut se trouver à plusieurs endroits : le journal du système, /var/log/ ou $HOME/.local/share/xorg/.
    • Certains gestionnaires d'affichage comme LightDM peuvent également placer le Xorg.log dans leur propre répertoire de journal.
  • Pacman : Si une mise à jour récente a cassé quelque chose, regardez dans /var/log/pacman.log.
    • Il peut être utile d'utiliser le paramètre --debug de pacman.

L'une des meilleures façons d'afficher ces informations est d'utiliser un pastebin.

Un lien sera alors généré que vous pourrez coller sur le forum ou sur IRC.

De plus, vous pouvez consulter comment expliquer correctement un problème avant de poser votre question.

Problèmes de démarrage

Lors du diagnostic des problèmes de démarrage, il est très important de savoir à quel stade le démarrage échoue.

  1. Firmware (UEFI ou BIOS)
    1. Ne dispose généralement que d'outils très basiques pour le débogage.
    2. Assurez-vous que Secure Boot est désactivé.
  2. Chargeur d'amorçage
    1. L'une des situations les plus courantes ici est la modification des paramètres du noyau.
  3. initramfs
    1. Fournit généralement un shell d'urgence.
    2. Selon les «hooks» choisis, soit le dmesg, soit le journal est disponible dans celui-ci.
  4. Le système réel
    1. En fonction de la gravité de la panne, une simple invocation de l'interpréteur de commandes de débogage peut suffire ici.

Malheureusement, les outils de débogage fournis par une étape peuvent ne pas être suffisants pour réparer le composant cassé. L'archiso peut être utilisé pour récupérer dans ce cas.

Messages sur la console

À la fin du processus de démarrage, l'écran est entièrement effacé et l'invite de connexion apparaît, laissant les utilisateurs incapables de lire la sortie d'init et les messages d'erreur. Ce comportement pour être modifié avec les méthodes exposées dans les sous-sections suivantes.

N'oubliez pas que quelle que soit l'option choisie, les messages du noyau peuvent être visualisés après démarrage avec la commande journalctl -k ou dmesg. Pour afficher tous les journaux depuis le derniers démarrage utilisez journalctl -b.

Contrôle du flux

Ce système rudimentaire de gestion du flux de la console s'applique à la plupart des émulateurs de terminaux incluant les consoles virtuelles.

  • Utilisez Ctrl+s pour mettre en pause l'affichage
  • Et Ctrl+q pour reprendre.

Cela ne met pas seulement l'affichage «en pause», cela gèle tout le programme qui tente d'afficher sur le terminal, car il se bloquera sur les appels write() tant que la sortie sera en pause. Si le processus de démarrage semble bloqué, vérifiez que la console n'est pas «en pause».

Pour voir les messages d'erreur qui sont déjà affichés, consultez Getty (Français)#Garder les messages de démarrage sur tty1.

Impression d'autres messages du noyau

La plupart des messages du noyau sont cachés pendant le démarrage. Vous pouvez voir plus de ces messages en ajoutant différents paramètres du noyau. Les plus simples sont :

  • debug, qui a les effets suivants :
    • Le noyau augmente le niveau de journalisation de la console [1] de sorte que tous les messages contenus dans le tampon de journalisation du noyau sont imprimés sur la console. [2]
    • systemd augmentera son niveau de journalisation de telle sorte qu'il enregistrera les messages de débogage qui autrement ne seraient produits nulle part. [3]
  • ignore_loglevel, qui a le même effet sur le noyau que debug ou loglevel=8. (puisque les messages de débogage sont à 7), mais empêche le niveau du journal d'être augmenté plus tard dans le démarrage.

D'autres paramètres que vous pouvez ajouter et qui peuvent être utiles dans certaines situations sont :

  • earlyprintk=vga,keep imprime les messages du noyau très tôt dans le processus de démarrage, au cas où le noyau se bloquerait avant que la sortie ne soit affichée. Vous devez remplacer vga par efi pour les systèmes EFI.
  • log_buf_len=16M alloue un tampon de messages du noyau plus grand (16 MiB), pour s'assurer que la sortie de débogage n'est pas dépassée.

Produire des messages de débogage du noyau

#Impression d'autres messages du noyau indique comment imprimer le tampon du journal du noyau sur la console, mais ce tampon lui-même ne contiendra aucun message qu'il ne contenait pas déjà (à part la sortie systemd de débogage). Cette rubrique traite des méthodes permettant d'obtenir des informations plus détaillées à partir du journal du noyau.

Débogage dynamique

Les messages imprimés à l'aide de pr_debug ou de fonctions connexes telles que dev_dbg(), drm_dbg() et bt_dev_dbg() ne seront pas générés à moins que vous n'ayez

  • Modifiez les sources du noyau pour définir DEBUG là où vous le souhaitez.
  • Utilisez la fonction dynamic debug du noyau pour activer les messages de débogage.

Cette section traite de l'utilisation du débogage dynamique, qui est utile si vous avez déjà regardé le journal de votre noyau avec tout jusqu'aux journaux d'information, et que vous souhaitez obtenir encore plus d'informations de débogage à partir d'un emplacement particulier.

Tout d'abord, vous devez exécuter un noyau qui a été compilé avec l'option de configuration du noyau CONFIG_DYNAMIC_DEBUG définie. C'est déjà le cas pour linux, donc aucune action n'est nécessaire si vous utilisez ce noyau.

Ensuite, vous devez savoir d'où vous voulez voir les messages de débogage. Il existe plusieurs options :

  • Aller avec le nom du module du noyau, si le problème semble être isolé à un module. Par exemple, pour dépanner Intel graphics, vous pouvez vous intéresser au module i915. DRM module du noyau.
  • Aller avec un répertoire dans le noyau qui correspond à la fonctionnalité qui vous intéresse. Vous voudrez consulter (ou naviguer en ligne) le code source du noyau pour comprendre la structure. Par exemple, pour inspecter les messages de débogage de tous les modules du noyau DRM, vous pouvez choisir le chemin drivers/gpu/drm.

En utilisant cette "source" de messages, vous devez créer une requête de débogage dynamique qui indique les messages de débogage à activer, au format : 

match_type match_parameter flags.

Où :

  • match_type est le type de correspondance à effectuer. Correspondant aux deux options données précédemment, cela peut être module ou file.
  • match_parameter est le module ou le chemin du fichier à surveiller. Dans ce dernier cas, l'utilisation d'astérisques comme caractères de remplacement est autorisée.
  • flags indique ce qu'il faut faire avec la correspondance. Cela peut être +p pour commencer à imprimer ses messages, ou -p pour annuler cela.

Voici quelques exemples de requêtes :

  • module i915 +p pour imprimer les messages de débogage du module noyau i915.
  • file drivers/gpu/drm/* +p pour imprimer les messages de débogage des pilotes DRM.
  • file * +p pour imprimer les messages de débogage.

Enfin, pour exécuter la requête, vous pouvez soit.. :

  • Le faire pendant l'exécution, en exécutant :
# echo "query" > /sys/kernel/debug/dynamic_debug/control
Ceci suppose que debugfs est monté sur /sys/kernel/debug/, ce que vous pouvez vérifier en utilisant mount . [4]

Il s'agit d'un aperçu très simplifié des capacités du débogage dynamique ; consultez la documentation pour plus de détails.

netconsole

netconsole est un module du noyau qui envoie tous les messages de journal du noyau (i.e. dmesg) sur le réseau à un autre ordinateur, sans impliquer l'espace utilisateur (e.g. syslogd). Le nom "netconsole" est mal choisi car il ne s'agit pas vraiment d'une "console", mais plutôt d'un service de journalisation à distance.

Il peut être utilisé soit intégré, soit en tant que module. Le netconsole intégré s'initialise immédiatement après les cartes NIC et fera apparaître l'interface spécifiée dès que possible. Le module est principalement utilisé pour capturer la sortie de panique du noyau d'une machine «headless», ou dans d'autres situations où l'espace utilisateur n'est plus fonctionnel.

Shell de secours

Lancer un shell interactif durant le processus de démarrage peut vous aider à déterminer exactement où et pourquoi quelque chose échoue. Il existe plusieurs paramètres du noyau pour ce faire, mais ils lancent tous un shell normal que vous pouvez exit pour laisser le noyau reprendre ce qu'il faisait :

  • rescue lance un shell peu après que le noyau monte la racine en lecture/écriture.
  • emergency lance un shell plus tôt encore, (avant que la plupart des partitions ne soit montées)
  • init=/bin/sh (en dernier recours) définit que le programme d'init est un shell avec les droits root. rescue et emergency font tout deux appel à systemd, ce dernier paramètre devrait fonctionner même si systemd est «cassé».

Une autre option et d'utiliser le «shell de débogage» de systemd. Ce dernier ajoute un shell root sur tty9 (accessible avec Ctrl+Alt+F9). Ajoutez systemd.debug_shell aux paramètres du noyau ou activez debug-shell.service.

Attention: N'oubliez pas de désactiver le service une fois terminé pour éviter le risque de sécurité de laisser un shell root ouvert à chaque démarrage.

Débogage des modules du noyau

Consultez Kernel module (Français)#Obtenir des informations.

Débogage du matériel

Déboguer les blocages

Malheureusement, les blocages («freeze») sont généralement difficiles à déboguer et certains d'entre eux prennent beaucoup de temps à reproduire. Il y a certains types de blocages qui sont plus faciles à déboguer que d'autres :

  • Le son est toujours présent ? Si c'est le cas, seul l'affichage peut être gelé. Il peut s'agir d'un problème avec le pilote vidéo.
  • La machine répond-elle toujours ? Essayez SSH si le passage à un autre TTY ne fonctionne pas.
  • Le voyant d'activité du disque (s'il est présent) indique-t-il que beaucoup de données sont écrites sur le disque ? Un swapping important peut geler temporairement le système. Consultez cette réponse sur StackExchange pour obtenir des informations sur les blocages lors d'écritures importantes.

Si rien d'autre ne vous aide, essayez un arrêt propre. Appuyer sur le bouton d'alimentation une fois peut débloquer le système et afficher l'"écran d'arrêt" classique qui affiche toutes les unités qui s'arrêtent. Vous pouvez également utiliser les touches magiques SysRq pour obtenir un arrêt propre. Ceci est très important car le journal de systemd peut contenir des indices sur la raison pour laquelle la machine s'est figée. Le journal peut ne pas être écrit sur le disque lors d'un arrêt non propre. Les gels durs dans lesquels toute la machine ne réponds plus sont plus difficiles à déboguer car les journaux ne peuvent pas être écrits sur le disque à temps.

La journalisation à distance peut être utile si le gel ne permet pas d'écrire quoi que ce soit sur le disque. Une solution rudimentaire de journalisation à distance, qui doit être invoquée depuis un autre périphérique, peut être utilisée pour un débogage de base : 

$ ssh freezing_host journalctl -f

De nombreux blocages fatals dans lesquels le système entier ne répond plus et nécessite un arrêt forcé peuvent être liés à un firmware, des pilotes ou du matériel bogué. Essayer un autre noyau (consultez Kernel (Français)#Déboguer les régressions) ou même une autre distribution Linux ou un autre système d'exploitation, mettre à jour le microprogramme et exécuter des diagnostics matériels peuvent aider à trouver le problème.

Astuce: Il est recommandé d'essayer de mettre à jour le microprogramme du périphérique, car ces mises à jour peuvent résoudre des problèmes étranges.

Si un blocage ne permet pas de recueillir des journaux ou d'autres informations nécessaires au débogage, essayez de reproduire le blocage dans un environnement «live». Si un environnement graphique est nécessaire pour reproduire le blocage ou si le blocage peut être reproduit sur l'archiso, utilisez l'environnement «live» d'une distribution différente, qui n'est de préférence pas basée sur Arch Linux pour éliminer la possibilité que le gel soit lié à la version ou aux correctifs du noyau. Si le gel se produit toujours dans un environnement «live», il y a de fortes chances que ce soit lié au matériel. Si cela ne se produit plus, il faut être conscient des différences entre les deux systèmes. Des configurations différentes, des différences dans les versions et les paramètres du noyau et d'autres changements similaires peuvent avoir résolu le blocage.

Cependant, un voyant clignotant de verrouillage des majuscules peut indiquer une panique du noyau. Certaines configurations peuvent ne pas afficher le TTY lorsqu'une panique du noyau se produit, ce qui peut prêter à confusion et être interprété comme un autre type de blocage.

Débogage des régressions

Attention: Ce scénario tend à provoquer des mises à jour partielles, qui sont un mal nécessaire dans ce cas précis. Procédez avec prudence et préparez un méthode de récupération de votre système, juste au cas où ce scénario empêcherait un démarrage normal.

Si une mise à jour provoque un problème mais que rétrograder le paquet spécifique le résout, il s'agit probablement d'une régression. Si cela s'est produit après une mise à jour complète normale du système, vérifiez votre pacman.log pour déterminer quel(s) paquet(s) peut (peuvent) avoir causé le problème. La partie la plus importante du débogage des régressions est de vérifier si le problème a déjà été corrigé, car cela peut faire gagner beaucoup de temps. Pour ce faire, assurez-vous d'abord que l'application est entièrement mise à jour (par exemple, assurez-vous que l'application est la même version que dans les dépôts officiels). Si elle l'est déjà ou si sa mise à jour ne résout pas le problème, essayez d'utiliser la dernière version actuelle, généralement une version -git, qui peut déjà être empaquetée dans le AUR. Si cela résout le problème et que la version avec les corrections n'est pas encore dans les dépôts officiels, attendez que la nouvelle version y arrive et revenez-y.

Si le problème persiste, déboguez le problème et/ou bisectez l'application et signalez le bogue sur le bugtracker en amont afin qu'il soit corrigé.

Note: Le noyau nécessite une approche légèrement différente lors du débogage des régressions.

Impossible d'utiliser certains périphériques après la mise à jour du noyau

Cela se manifeste généralement (mais probablement pas uniquement) par :

  • des périphériques de stockage USB nouvellement branchés apparaissant avec dmesg mais pas dans /dev/,
  • des systèmes de fichiers ne peuvent pas être montés s'ils n'étaient pas déjà utilisés avant la mise à jour du noyau,
  • l'impossibilité d'utiliser une connexion filaire/sans fil sur un ordinateur portable si elle n'était pas déjà utilisée avant la mise à jour du noyau,
  • FATAL : Module module not found in directory /lib/module/kernelversion lors de l'utilisation de modprobe pour charger un module qui n'était pas déjà utilisé avant la mise à jour du paquet du noyau.

Comme partiellement couvert dans System maintenance (Français)#Redémarrage après une mise à jour, le noyau n'est pas mis à jour lorsque vous mettez à jour le paquet mais seulement lorsque vous redémarrez ensuite. Pendant ce temps, les modules du noyau, situés dans /usr/lib/module/kernelversion/ sont supprimés par pacman lors de l'installation du nouveau noyau. Comme expliqué dans FS#16702, cette approche évite de laisser des fichiers sur le système qui ne sont pas gérés par le gestionnaire de paquets mais conduit aux symptômes susmentionnés. Pour les corriger, il faut redémarrer systématiquement après la mise à jour du noyau. L'évolution à long terme, qui doit encore être mise en œuvre, consistera à utiliser des paquets de noyau versionnés : le principal problème est de savoir comment gérer la suppression des versions précédentes du noyau lorsqu'elles ne sont plus nécessaires.

Une autre solution est disponible sous la forme kernel-modules-hook, où deux hooks pacman utilisent rsync pour garder les modules du noyau sur le système de fichiers après la mise à jour du noyau et un service systemd supprime les anciens modules quatre semaines après.

Gestion des paquets

Consultez Pacman (Français)#Dépannage pour les sujets généraux, et Pacman (Français)/Package signing (Français)#Dépannage pour les problèmes avec les clés PGP.

Réparer un système cassé

Si des mises à jour partielles ont été effectuées, essayez de mettre à jour l'ensemble de votre système. Un redémarrage peut être nécessaire. 

# pacman -Syu

Si vous démarrez habituellement dans une interface graphique et que celle-ci ne fonctionne pas, vous pouvez peut-être appuyer sur Ctrl+Alt+F1 à Ctrl+Alt+F6 et accéder à un tty fonctionnel pour exécuter pacman.

Si le système est suffisamment endommagé pour que vous ne puissiez pas exécuter pacman, démarrez en utilisant un ISO Arch mensuel à partir d'une clé USB, d'un disque optique ou d'un réseau avec PXE. (Ne suivez pas le reste du guide d'installation).

Montez votre système de fichiers racine : 

[ISO] # mount /dev/rootFileSystemDevice /mnt

Montez toutes les autres partitions que vous avez créées séparément, en ajoutant le préfixe /mnt à chacune d'entre elles, par exemple : 

[ISO] # mount /dev/bootDevice /mnt/boot

Essayez d'utiliser pacman de votre système : 

[ISO] # arch-chroot /mnt
[chroot] # pacman -Syu

Si cela échoue, quittez le chroot, et essayez : 

[ISO] # pacman -Syu --sysroot /mnt

Si cela échoue, essayez : 

[ISO] # pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg

fuser

fuser est un utilitaire en ligne de commande permettant d'identifier les processus utilisant des ressources telles que les fichiers, les systèmes de fichiers et les ports TCP/UDP.

fuser est fourni par le paquet psmisc, qui doit être déjà installé en tant que dépendance du métapaquet base. Voir fuser(1) pour plus de détails.

Permissions de session

Note: Vous devez utiliser systemd (Français) comme système init pour que les sessions locales fonctionnent. [5] Il est nécessaire pour les autorisations polkit et les ACL pour divers périphériques (consultez /usr/lib/udev/rules.d/70-uaccess.rules et [6])

Tout d'abord, vérifiez que vous avez une session locale valide dans X : 

$ loginctl show-session $XDG_SESSION_ID

Le résultat devrait contenir Remote=no et Active=yes. Si ce n'est pas le cas, assurez-vous que X s'exécute sur le même tty que celui où la connexion a eu lieu. Ceci est nécessaire afin de préserver la session logind.

Les actions de base de polkit ne nécessitent pas de configuration supplémentaire. Certaines actions de polkit nécessitent une authentification supplémentaire, même avec une session locale. Un agent d'authentification polkit doit être exécuté pour que cela fonctionne. Consultez Polkit (Français)#Agents d'authentification pour plus d'informations à ce sujet.

Message : "error while loading shared libraries"

Si, pendant l'utilisation d'un programme, vous obtenez une erreur similaire à : 

error while loading shared libraries : libusb-0.1.so.4 : cannot open shared object file : No such file or directory

Utilisez pacman ou pkgfile pour rechercher le paquet qui possède la bibliothèque manquante : 

$ pacman -F libusb-0.1.so.4
extra/libusb-compat 0.1.5-1
    usr/lib/libusb-0.1.so.4

Dans ce cas, le paquet libusb-compat doit être installé. Il se peut également que le programme qui demande la bibliothèque doive être reconstruit à la suite d'une soname bump.

L'erreur peut également signifier que le paquet que vous avez utilisé pour installer votre programme ne liste pas la bibliothèque comme une dépendance dans son PKGBUILD : s'il s'agit d'un paquet officiel, signalez un bogue ; s'il s'agit d'un paquet AUR, signalez-le au responsable en utilisant sa page sur le site Web AUR.

Voir aussi