General troubleshooting (Français)

É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
Reporting bug guidelines
Step-by-step debugging guide
Debugging/Getting traces
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.
Exécutez l'application dans un terminal afin de pouvoir inspecter la sortie.
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.
Parfois, ce paramètre n'existe pas et doit être spécifié en tant que directive dans le fichier de configuration des applications.
Une application peut également utiliser des fichiers journaux, qui sont généralement situés dans
/var/log
,
$HOME/.cache
ou
$HOME/.local
.
S'il n'y a aucun moyen d'augmenter la verbosité, il est toujours possible d'exécuter
strace
et des opérations similaires.
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.
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.
journalctl
a plus d'options de filtrage que
dmesg
et utilise par défaut des horodatages lisibles humainement.
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.
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.
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.
Firmware (UEFI ou BIOS)
Ne dispose généralement que d'outils très basiques pour le débogage.
Assurez-vous que
Secure Boot
est désactivé.
Chargeur d'amorçage
L'une des situations les plus courantes ici est la modification des paramètres du noyau.
initramfs
Fournit généralement un shell d'urgence.
Selon les «hooks» choisis, soit le dmesg, soit le journal est disponible dans celui-ci.
Le système réel
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]
Faites-le au démarrage, en ajoutant le
paramètre du noyau
dyndbg="
query
"
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
Vous pouvez afficher des informations de débogage supplémentaires sur votre matériel en suivant
Udev (Français)#Sortie de débogage
.
Assurez-vous que les mises à jour du
Microcode
sont appliquées sur votre système.
Pour tester la RAM, voir
Stress testing#Memtest86+
.
Pour voir si votre système surchauffe, utilisez
lm_sensors
.
Pour vérifier la santé de votre stockage, consultez
S.M.A.R.T.
.
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
Un guide de dépannage pour les nouveaux arrivants
.
Liste d'outils pour l'UBCD
- Outils de test de mémoire à ajouter à grub.cfg sur UltimateBootCD.com
Wikipedia:BIOS boot partition
REISUB
Journaux de débogage sur une console série
sur Freedesktop.org
How to Isolate Linux ACPI Issues
sur Archive.org