Comment résoudre les échecs courants de gestion de paquets (APT/YUM)

Les échecs de gestionnaire de paquets surviennent généralement au pire moment : lors d'une mise à jour de sécurité, d'un déploiement, ou d'une session rapide "installe juste cet outil" sur un hôte que vous ne touchez pas habituellement. APT, YUM et DNF vous disent généralement ce qui ne va pas, mais la sortie peut être bruyante. Le travail consiste à ralentir, identifier quelle couche a échoué et éviter de forcer la base de données dans un état pire.

APT est courant sur les systèmes Debian et Ubuntu. YUM et DNF sont courants sur les systèmes de la famille Red Hat, DNF remplaçant YUM sur de nombreuses versions plus récentes. Les exemples ci-dessous se concentrent sur les échecs que les administrateurs rencontrent réellement : transactions interrompues, problèmes de métadonnées de dépôt, conflits de dépendances, verrous, erreurs GPG et problèmes de base de données de paquets.

Avant de modifier quoi que ce soit, capturez la commande exacte et l'erreur. S'il s'agit d'un serveur de production, vérifiez également si un autre processus de mise à jour est en cours. Deux gestionnaires de paquets se battant pour la même base de données peuvent transformer un petit problème en une longue réparation.

Échecs APT courants et dépannage

APT est réputé pour ses capacités complètes de résolution de dépendances. Cependant, des problèmes peuvent toujours survenir, souvent liés à des dépendances cassées, des téléchargements interrompus ou des problèmes de dépôt.

1. Paquets cassés ou dépendances non satisfaites

C'est peut-être l'erreur APT la plus courante. Elle se produit lorsqu'un paquet est installé, mais que ses dépendances sont manquantes, cassées ou incompatibles. Le message d'erreur ressemble souvent à ceci :

Erreur : dpkg a été interrompu, vous devrez peut-être exécuter 'sudo dpkg --configure -a' pour corriger le problème.

Dépaquetage ... (lecture de la base de données ... xxxx fichiers et répertoires actuellement installés.)

Préparation du dépaquetage de .../some-package_version_arch.deb ...

Dépaquetage de some-package (version) ...

dpkg : erreur de traitement de l'archive /var/cache/apt/archives/some-package_version_arch.deb (--unpack) :

 tentative d'écrasement de '/path/to/file', qui est également dans le paquet other-package:amd64

Des erreurs ont été rencontrées lors du traitement :

 some-package
 E : Sous-processus /usr/bin/dpkg a retourné un code d'erreur (1)

Étapes de dépannage :

• Configurer les paquets en attente : Si dpkg a été interrompu, la première étape consiste à essayer de le réparer :

  sudo dpkg --configure -a
  

  Cette commande tente de configurer tous les paquets dépaquetés mais pas encore configurés.

• Corriger les dépendances cassées : Si ce qui précède ne résout pas le problème, vous pouvez essayer de corriger les dépendances cassées :

  sudo apt --fix-broken install
  

  Cette commande tentera de télécharger et d'installer les dépendances manquantes ou de supprimer les paquets problématiques.

• Supprimer les paquets problématiques : Parfois, un paquet spécifique peut causer des problèmes persistants. Vous pouvez essayer de le supprimer :

  sudo apt remove <nom-du-paquet>
  

  Si le paquet ne peut pas être supprimé normalement, vous devrez peut-être forcer sa suppression (à utiliser avec prudence) :

  sudo dpkg --remove --force-remove-reinstreq <nom-du-paquet>
  

• Nettoyer le cache APT : Un cache corrompu peut également entraîner des erreurs :

  sudo apt clean
  sudo apt update
  

  apt clean supprime les fichiers de paquets téléchargés de /var/cache/apt/archives/, et apt update actualise la liste des paquets.

2. Problèmes de dépôt

Des erreurs peuvent survenir si les listes de paquets ne peuvent pas être récupérées depuis les dépôts configurés. Cela peut être dû à des problèmes réseau, une URL de dépôt invalide ou une indisponibilité temporaire du dépôt.

Exemples d'erreurs :

E : Échec de la récupération de http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Échec temporaire de la résolution de 'archive.ubuntu.com'
E : Certains fichiers d'index n'ont pas pu être téléchargés. Ils ont été ignorés, ou les anciens ont été utilisés à la place.

Étapes de dépannage :

• Vérifier le DNS et la connectivité réseau : Les échecs DNS sont courants sur les serveurs fraîchement construits et les chemins VPN cassés.

  getent hosts archive.ubuntu.com
  curl -I http://archive.ubuntu.com/ubuntu/
  

• Vérifier les sources du dépôt : Vérifiez le contenu de /etc/apt/sources.list et les fichiers dans /etc/apt/sources.list.d/. Assurez-vous que les URL sont correctes et accessibles.
  • Recherchez les fautes de frappe.
  • Commentez ou supprimez les entrées de dépôt suspectes.
• Essayer un miroir différent : Si un miroir spécifique est en panne, APT peut en essayer un autre automatiquement. Sinon, modifiez manuellement sources.list pour sélectionner un miroir différent.
• Mettre à jour les listes de paquets : Après avoir effectué des modifications, exécutez toujours :

  sudo apt update
  

Si apt update se plaint des signatures, ne désactivez pas la vérification des signatures comme raccourci. La signature du dépôt vous protège contre l'installation de paquets falsifiés. Vérifiez si le fournisseur du dépôt a changé sa clé, si le paquet keyring est obsolète, ou si un ancien dépôt tiers n'est plus maintenu.

3. Installations ou mises à niveau interrompues

Si un processus apt install ou apt upgrade est interrompu (par exemple, par une panne de courant ou un redémarrage du système), cela peut laisser le système dans un état incohérent.

Étapes de dépannage :

• Exécuter sudo dpkg --configure -a : Comme mentionné précédemment, c'est la première étape pour essayer de corriger les problèmes de configuration de dpkg.
• Exécuter sudo apt --fix-broken install : Cela peut résoudre les problèmes de dépendance découlant de l'interruption.
• Réexécuter la commande : Parfois, le simple fait de réexécuter la commande qui a échoué peut résoudre le problème s'il s'agissait d'un problème transitoire.

Échecs YUM/DNF courants et dépannage

YUM et DNF sont des outils puissants pour gérer les paquets dans les systèmes basés sur Red Hat. Comme pour APT, les échecs proviennent souvent de problèmes de dépendances, de problèmes de dépôt ou de cache corrompu.

1. Erreurs de dépendance

Les erreurs de dépendance dans YUM/DNF se produisent lorsqu'un paquet demandé nécessite un autre paquet qui n'est pas installé, qui est d'une version incompatible ou qui ne peut pas être trouvé dans les dépôts configurés.

Exemple d'erreur (YUM) :

Erreur : Paquet : some-package-1.0-1.el8.x86_64 (epel)

Nécessite : another-package >= 2.0

Vous pourriez essayer : rpm -e --nodeps some-package

Exemple d'erreur (DNF) :

Erreur : 
 Problème : impossible d'installer le meilleur candidat pour ce paquet (root signifie processus d'installation)
  - rien ne fournit la dépendance 'another-package >= 2.0' nécessaire par 'some-package-1.0-1.el8.x86_64'

Étapes de dépannage :

• Mettre à jour les informations sur les paquets : Assurez-vous que votre cache local de paquets est à jour :

  sudo yum makecache # Pour YUM
  sudo dnf makecache # Pour DNF
  

• Installer les dépendances manuellement : Si vous connaissez la dépendance requise, essayez de l'installer explicitement :

  sudo yum install another-package # Pour YUM
  sudo dnf install another-package # Pour DNF
  

• Utiliser les outils de nettoyage avec précaution : Ces utilitaires peuvent parfois aider à identifier les paquets en double ou obsolètes.

  sudo yum install yum-utils
  sudo package-cleanup --cleandupes # Nettoyer les paquets en double
  sudo package-cleanup --orphans # Supprimer les paquets orphelins
  
  sudo dnf install dnf-plugins-core
  sudo dnf clean all
  

• Éviter rpm -e --nodeps sauf si vous avez un plan de restauration : Cela peut supprimer un paquet tout en laissant les paquets dépendants installés, ce qui peut satisfaire la commande mais casser le système.

2. Problèmes de configuration du dépôt

Les problèmes avec les dépôts YUM/DNF peuvent empêcher la recherche ou l'installation de paquets.

Étapes de dépannage :

• Vérifier les fichiers de dépôt : Les définitions de dépôt se trouvent généralement dans /etc/yum.repos.d/. Examinez ces fichiers .repo pour :
  • Des entrées baseurl ou mirrorlist correctes.
  • Dépôts activés (enabled=1).
  • Problèmes de vérification de clé GPG (souvent indiqués par gpgcheck=1).
• Vérifier l'accès réseau : Comme pour APT, assurez-vous que votre système peut atteindre les serveurs de dépôt.

  ping <adresse-du-serveur-de-dépôt>
  

• Vérifier les clés GPG : Si vous voyez des erreurs liées aux clés GPG, vous devrez peut-être importer ou réimporter la clé publique du dépôt.

  # Exemple pour importer une clé
  sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-votre-depot
  

  Évitez de définir gpgcheck=0 sur les systèmes de production. Cela échange une tâche de réparation contre un risque pour la chaîne d'approvisionnement.
• Nettoyer le cache : Un cache corrompu peut causer des problèmes :

  sudo yum clean all
  sudo dnf clean all
  

  Ensuite, actualisez les métadonnées :

  sudo yum makecache
  sudo dnf makecache
  

3. Erreurs de transaction incomplète

Ces erreurs se produisent lorsqu'un processus d'installation, de mise à jour ou de suppression de paquet est interrompu.

Étapes de dépannage :

• Réexécuter la transaction : Souvent, le simple fait de réexécuter la commande (yum update, dnf install, etc.) peut résoudre le problème s'il s'agissait d'un problème temporaire.
• Nettoyer le cache : Comme ci-dessus, vider le cache peut aider :

  sudo yum clean all
  sudo dnf clean all
  

• Vérifier les paquets retenus : Bien que moins courant avec YUM/DNF qu'avec APT, certaines configurations peuvent empêcher la mise à jour des paquets. Cela est généralement géré par des configurations de plugins plutôt que par des commandes 'hold' directes.
• Examiner les journaux : Consultez /var/log/yum.log (pour YUM) ou /var/log/dnf.log (pour DNF) pour des messages d'erreur détaillés.

Verrous et processus de paquets bloqués

Les erreurs de verrou ne sont pas vraiment des erreurs de dépendance. Elles signifient généralement qu'un autre processus de paquet est en cours d'exécution ou est mort sans avoir nettoyé.

Sur Debian ou Ubuntu, vous pouvez voir des messages concernant /var/lib/dpkg/lock-frontend ou /var/lib/apt/lists/lock. Sur les systèmes de la famille Red Hat, vous pouvez voir un autre processus dnf ou yum détenant le verrou de la base de données RPM.

Tout d'abord, vérifiez s'il y a un processus actif :

ps aux | grep -E 'apt|dpkg|dnf|yum|rpm' | grep -v grep

Si des mises à niveau non surveillées ou cloud-init sont en cours d'exécution, attendez. Tuer une véritable transaction de paquet peut laisser des paquets à moitié configurés. Si vous êtes sûr que le processus a disparu et qu'il ne reste qu'un verrou obsolète, réparez alors la base de données de paquets avec les outils normaux :

sudo dpkg --configure -a
sudo apt --fix-broken install

Pour les systèmes basés sur RPM :

sudo dnf clean all
sudo rpm --rebuilddb

rpm --rebuilddb n'est pas une première réponse à chaque problème DNF. Utilisez-le lorsque la base de données RPM elle-même semble endommagée, pas lorsqu'une URL de dépôt est erronée.

Conflits de version provenant de dépôts tiers

De nombreux échecs de paquets graves proviennent de dépôts mélangés : un dépôt fournisseur, EPEL, un dépôt d'exécution de langage, un dépôt Kubernetes ou un miroir interne ancien. Le gestionnaire de paquets peut faire exactement ce qu'on lui a dit, mais les versions disponibles ne peuvent pas se satisfaire mutuellement.

Sur les systèmes APT, inspectez la politique :

apt-cache policy <nom-du-paquet>
apt-cache madison <nom-du-paquet>

Sur les systèmes DNF :

dnf repoquery --show-duplicates <nom-du-paquet>
dnf repolist --enabled

Si un dépôt tiers est le problème, désactivez-le temporairement et réessayez la transaction :

sudo dnf --disablerepo='nom-du-depot' update

Pour APT, commentez l'entrée suspecte dans /etc/apt/sources.list.d/, exécutez sudo apt update, et testez à nouveau. Ne laissez pas le système dans un état mystérieux ; documentez quel dépôt a été désactivé et pourquoi.

Lorsqu'une mise à niveau de version ou une mise à jour majeure échoue

Les mises à niveau majeures méritent plus de prudence qu'une installation de paquet normale. Avant de réessayer, assurez-vous de savoir si le système est entre deux versions, si les anciens dépôts sont toujours activés et si les invites de configuration ont été interrompues.

Sur Debian ou Ubuntu, vérifiez les fichiers de version et les paquets retenus :

cat /etc/os-release
apt-mark showhold
sudo dpkg --audit

Sur les systèmes basés sur DNF, vérifiez les dépôts activés et le comportement de synchronisation de distribution :

cat /etc/os-release
dnf repolist --enabled
sudo dnf distro-sync

distro-sync peut rétrograder ou remplacer des paquets pour correspondre aux dépôts activés, alors lisez la transaction proposée avant de l'accepter. Sur les systèmes importants, prenez d'abord un instantané ou une sauvegarde. Les gestionnaires de paquets sont bons en mathématiques de dépendances, mais ils ne peuvent pas savoir de quels fichiers de configuration locaux, modules du noyau ou agents fournisseurs votre entreprise dépend.

Conseils généraux de dépannage

Quel que soit le gestionnaire de paquets, quelques pratiques générales peuvent vous faire gagner du temps et éviter des maux de tête :

• Lire attentivement les messages d'erreur : La sortie de apt ou yum/dnf contient souvent des indices spécifiques sur le problème.
• Vérifier les journaux système : /var/log/apt/history.log et /var/log/apt/term.log pour APT, et /var/log/yum.log ou /var/log/dnf.log pour YUM/DNF, peuvent fournir un historique détaillé des transactions et des informations sur les erreurs.
• Mettre à jour régulièrement : Gardez votre système et vos listes de paquets à jour pour minimiser les risques de rencontrer des dépendances obsolètes ou des problèmes de dépôt.
• Utiliser sudo : Exécutez toujours les commandes de gestion de paquets avec les privilèges de superutilisateur.
• Sauvegarder les données critiques : Avant d'effectuer des mises à jour ou installations majeures du système, sauvegardez toutes les données critiques. C'est un filet de sécurité si quelque chose tourne mal.
• Isoler le problème : Si plusieurs paquets échouent, essayez de les mettre à jour ou de les installer un par un pour identifier le paquet spécifique à l'origine du problème.
• Lire la transaction proposée avant de taper oui : Les suppressions sont importantes. Si un gestionnaire de paquets veut supprimer un serveur de base de données, un paquet du noyau, un serveur SSH ou un environnement d'exécution de base, arrêtez-vous et comprenez pourquoi.
• Préférer les corrections de dépôt aux indicateurs de force : La plupart des échecs de paquets proviennent de l'état des métadonnées, des dépôts ou des dépendances. Les indicateurs de force peuvent cacher le symptôme tout en rendant le système plus difficile à maintenir.

L'ordre de dépannage le plus sûr est cohérent : vérifiez s'il y a un autre processus de paquet en cours d'exécution, actualisez les métadonnées, réparez les transactions interrompues, inspectez les dépôts, puis traitez les conflits de dépendances. Réservez les suppressions forcées et les contournements de signature pour les cas exceptionnels où vous comprenez le rayon d'explosion et disposez d'un chemin de restauration.