General troubleshooting (Français)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Cet article ou section a besoin d'être traduit(e).

Notes: Cet article ne respecte pas la structure de sa version anglophone, merci de le réécrire en conséquence. Vous pouvez aussi ajouter à la version anglophone les informations à-jour et dignes d’intérêt qui ne seraient portées que par la version francophone. Voir ArchWiki:Translation Team (Français) (Discuss in Talk:General troubleshooting (Français)#)

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édure générale

Attention aux détails

Afin de résoudre votre problème, il est «absolument crucial» que vos connaissances du sous-système qui vous intéresse soient solides. Comment cela fonctionne t'il? Qu'est ce qu'il devrait se passer s'il n'y avait cette erreur? Si vous avez du mal à répondre à ces deux questions, vous devriez probablement revoir vos connaissances sur le sujet.

Questions / checklist

Voici une liste de question que vous devriez vous poser chaque fois que vous êtes face à un système qui fonctionne mal. Sous chaque question se trouvent des notes expliquant comment vous devriez tenter de répondre, suivis d'exemples de façon de collecter des données, et des outils pour accéder aux journaux des opérations.

Quel est le problème?
Soyez aussi précis que possible. Cela vous aidera à ne pas être submergé ou distrait lors de la recherche d'une information spécifique.
Quels sont les messages d'erreur? (s'il y en a)

Copier et coller la sortie complète qui contient les messages d'erreur dans un fichier à part tel $HOME/issue.log. Par exemple, pour récupérer la sortie de la commande mkinitcpio vers le fichier $HOME/issue.log:

$ mkinitcpio -p linux >> $HOME/issue.log
Pouvez-vous reproduire le problème?
Si oui, établissez la liste exacte des instructions/commandes nécessaires pour le reproduire. En ligne de commande, vous pouvez commencer par enregistrer vos commandes accompagnées de leurs sorties. Voir à ce propos script, une commande fournie par le paquet util-linux. Pour vous débarrasser des caractères de contrôle, et/ou non-imprimables du fichier typescript résultant, utilisez tr. Les séquences d’échappement ANSI sont plus difficiles à gérer (car plus complexes). Pour l'utilisation de sed à ce propos visitez https://stackpointer.io/unix/unix-linux-remove-ansi-escape-sequences/464/.
Quand avez-vous rencontré ce problème pour la première fois? Quand le système a t'il été fonctionnel pour la dernière fois? Qu'est ce qui a changé entre temps?

Si cela survient après une mise à jour, listez tous les paquet mis à jour, ainsi que leur numéro de version. Examinez /var/log/pacman.log. Pensez aux éventuels services requis pour le bon fonctionnement du système.

$ systemctl status dhcpcd@eth0.service >> $HOME/issue.log

Approche

Plutôt que d'approcher un problème en constatant

L'application X ne fonctionne pas.

il est plus utile de de formuler le problème dans le contexte de son environnement.

L'application X produit l'erreur Y lors de l’exécution de la tâche Z dans les conditions A et B.

Besoin d'aide?

Après toutes ces étapes, vous devriez certaine idée de ce qu'il se passe sur le système et devriez pouvoir commencer à travailler à une solution.

Si vous avez besoin d'aide, celle-ci peut être trouvée sur https://forums.archlinux.fr/, le forum de la communauté Archlinux francophone. N'oubliez pas que la nétiquette vous recommande d'avoir lu:

L'art de poser de bonnes questions si vous n'avez jamais posté sur un forum,
règles du forum si vous n'avez jamais posté sur le forum ArchLinuxFR.

Note: Le document en version anglophone de ce document précise que le soutien n'est fournis que pour Archlinux uniquement et aucune des distributions dérivées. La communauté francophone est probablement plus coulante la dessus. Mais de grâce si vous utilisez une distribution dérivée, mentionnez-le! (NdT)

Si l'on vous demande les sorties de commandes ou de journaux, postez ceux-ci dans leur intégralité, ne les tronquez pas aux seules sections que vous jugez utiles.

Problèmes de démarrage

Le diagnostique des problèmes de démarrage impliquent de pouvoir changer les paramètres passés au noyau. Cela suppose de pouvoir interagir avec le bootloader. Si cela n'est même pas possible, démarrez depuis une iso live et utilisez arch-chroot.

Astuce: La suite de cette section suppose que vous sachiez modifier les paramètres que votre bootloader passe au noyau. Si besoin, consultez la documentation de votre chargeur d'amorçage. L'iso d'installation utilise Grub.

Messages sur la console

A la fin du processus de démarrage, l'écran est entièrement vidé, et le login (ou un gestionnaire de connexion) apparaît. Ceci laisse l'utilisateur incapable de lire les éventuels messages d'erreur. Ce comportement pour être modifié par chacune des méthodes exposées dans les suivantes sous-sections. Voir Getty (Français)#Garder les messages du démarrage sur tty1 pour désactiver ceci de façon permanente.

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 logs 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. Si le processus de démarrage semble bloqué, vérifiez que la console n'est pas «en pause».

Sortie verbeuse

La majorité des messages que le noyau produit lors du démarrage ne sont pas affichés. Vous pouvez rendre le noyau plus bavard en plus passant des paramètres tels:

debug active l'affichage des messages de débogage pour systemd et le noyau.
ignore_loglevel force l'affichage de tous les messages du noyau

Dans certaines situations vous pouvez également être intéressés par les paramètres suivants:

earlyprintk=vga,keep pour afficher les messages du «early boot». Utilisez cette option si le noyau crashe sans avoir eu le temps d'afficher quoi que ce soit. Remplacez vga par efi pour les systèmes en UEFI.
log_buf_len=16M alloue un grand tampon pour les messages du noyau (16 MiB), dans le cas d'une sortie très verbeuse, cela peut éviter un écrasement des données par manque de place dans le tampon.

Le noyau Linux reconnaît de nombreux paramètres pour le deboguage de sous-composants (par exemple: bootmem_debug, sched_debug. Voir la documentation du noyau pour des informations complémentaires.

netconsole

netconsole est un module qui envoi tous les messages de log du kernel à travers le réseau. Ceci peut vous sauver la mise dans le cas d'un serveur «headless»...

Shell de secours

Lancer un shell de secours avant la fin du démarrage est souvent la façon la plus simple de mettre le doigt sur ce qui cause le problème. Dans ce cas, différents paramètres peuvent être passés au noyau.

rescue lance un shell immédiatement après que le noyau monte la racine en é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, ceci lance un shell avec les droits root. Alors que les deux points du dessus 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 active un shell (root) sur la neuvième console virtuelle (Ctrl+Alt+F9). Ceci peut être activé au moyen du service debug-shell.service ou en passant le paramètre systemd.debug_shell au noyau.

Attention: Ne pas oublier de désactiver le shell de débogage! Un shell avec des droits root à chaque démarrage serait une grosse faille de sécurité.

Écran noir et Carte graphique Intel

Il s'agit probablement d'un problème avec KMS. Voyez KMS#Désactiver_KMS. Si cela ne suffit pas, consultez ce paragraphe (en).

Plantage lors du chargement du noyau

Désactivez la gestion de l'ACPI avec le paramètre acpi=off.

Déboguer les modules du noyau

Il est possible passer au noyau un paramètre tel module.option=val ceci commandera comment linux devra charger ou ne pas charger un module.

cf. la page modules.

Kernel panics

Un kernel panic est ce qu'il arrive quand le noyau linux plante et se retrouve dans un état dont il n'est pas pas capable de se sortir. Cet état est généralement causé par un pilote bogué qui rend la machine inerte, et incapable de répondre. Il est alors nécessaire de forcer le redémarrage de la machine.

Juste avant le blocage, un message de diagnostic est généré. Celui-ci contient:

l'état de la machine quand le défaut est apparu
la liste des appels de fonction qui ont conduit à la fonction qui a causé le kernel panic
et la liste des modules chargés.

Heureusement, le noyau linux est stable, et les kernel panics ne se produisent pas souvent lors de l'utilisation des kernels «mainstream» tels que ceux qui sont fournis dans les dépots officiels. Toutefois, quand cela arrive, il est important de savoir comment réagir.

Panic et Oops

On utilise parfois le terme de «Oops» ou de «kernel oops» à la place de kernel panic. Si les deux mots se rapportent au résultat d'une défaillance du noyau, un oops est quelque chose de plus général qu'un panic dans le sens qu'un oops ne résulte pas nécessairement à une défaillance complète de la machine. (deadlock machine NdT.)

Le noyau peut parfois se délivrer d'un oops en tuant les processus/tâches incriminés avant de reprendre son exécution normale.

Astuce: Passez au noyau le paramètre oops=panic lors du démarrage, ou utilisez cat 1 > /proc/sys/kernel/panic_on_oops une fois le noyau lancé pour forcer le noyau à considérer un oops comme un panic. Ceci est recommandé pour une sécurité maximale. En effet, dans certains cas rares l'apparition d'un oops pourrait causer divers problèmes futurs... Problèmes dont la cause deviendrait ainsi plus difficile à diagnostiquer.

Examiner le message d'un kernel panic

Si un panic apparaît lors du early boot (lors du chargement du noyau), vous devriez voir un message «Kernel panic - not syncing:». Cependant, une fois Systemd démarré, les messages du noyau vont être capturés et redirigés vers les journaux systèmes. Aussi, quand un panic se produit, le message de débogage ne sera pratiquement jamais écrit au journal... Le système est «gelé» avant que system-journald n'ait la possibilité de le faire. Aussi, la manière la plus simple d’examiner le panic message est de la visualiser sur la console dès qu'il se produit. (une autre solution étant de mettre en place kdump).

Pour rediriger les messages vers une console (ici tty1), il suffit de démarrer avec les paramètres suivants:

systemd.journald.forward_to_console=1 console=tty1

Astuce: Dans le cas ou les messages de panic défilent trop rapidement vous pouvez mettre en pause le système avec le paramètre pause_on_oops=seconds

Voyez le wiki anglophone pour un exemple de panic message.

Gestion des paquets

Voir les pages:

Réparer un système cassé

Si vous avez quand même effectué une mise à jour partielle, et que le système est cassé au point que vous ne puissiez plus exécuter pacman, démarrer à l'aide d'une ISO Arch mensuelle à 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 à chacune d'elles, c'est-à-dire:

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

Essayez d'utiliser le "pacman" de votre système:

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

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

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

Si cela échoue, essayez :

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

Permissions de session

Note: Vous devez utiliser systemd comme système init pour que les sessions locales fonctionnent. [1] 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 [2])

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#Authentication agents pour plus d'informations à ce sujet.