Partager via

Résoudre les problèmes courants dans les outils de gestion des packages yum et dnf pour Linux

S’applique à : ✔️ Machines virtuelles Linux

Cet article décrit et résout les problèmes courants que vous pouvez rencontrer lorsque vous utilisez et que vous utilisez yum des dnf outils de gestion de package pour installer ou mettre à jour des applications sur des machines virtuelles Microsoft Azure.

Attention

Cet article fait référence à CentOS, une distribution Linux qui a atteint sa fin de vie de support (EOL). Tenez compte de votre utilisation et de votre planification en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.

Aperçu

L’outil de gestion des packages de ligne de commande yum est utilisé dans les distributions Linux qui utilisent le rpm Gestionnaire de package. Le nom de l’outil est un acronyme de « Yellowdog Updater Modified » et a été initialement développé pour Yellow Dog Linux. L’outil yum a acquis une utilisation généralisée, en particulier dans les distributions rpm telles que Red Hat Enterprise Linux (RHEL), CentOS, Oracle Linux, Mariner et Fedora.

L’outil de gestion des packages en ligne de commande dnf ou « Dandified Yum » est un outil de gestionnaire de package modernisé et amélioré pour les distributions Linux basées sur RPM.

Scénario 1 : Problème d’accès au référentiel

Vous rencontrez des erreurs qui s’appliquent aux certificats ou à la connectivité réseau.

Exécuter un script de validation

Azure fournit le script de vérification du référentiel Red Hat Update Infrastructure (RHUI) sur GitHub. Ce script Python inclut les fonctionnalités suivantes :

  • Valide le certificat client RHUI.
  • Valide la cohérence rpm RHUI.
  • Vérifie la cohérence entre la prise en charge des mises à jour étendues (EUS) et les configurations de référentiel non-EUS et leurs exigences.
  • Valide la connectivité aux référentiels RHUI.
  • Signale la réussite de la connectivité du référentiel si aucune erreur n’est détectée.
  • Vérifie la connectivité SSL aux référentiels RHUI.
  • Se concentre exclusivement sur les dépôts RHUI.
  • Vérifie une erreur trouvée à l’aide des conditions définies et fournit des recommandations pour un correctif.

Images Red Hat prises en charge

Cette version du script de vérification prend actuellement en charge uniquement les machines virtuelles Red Hat suivantes déployées à partir de l’image Place de marché Azure :

  • Machines virtuelles RHEL 7.x PAYG
  • Machines virtuelles RHEL 8.x PAYG
  • Machines virtuelles RHEL 9.x PAYG
  • RHEL 10. x machines virtuelles PAYG

Comment exécuter le script de vérification RHUI

Pour exécuter le script de vérification, entrez les commandes shell suivantes sur une machine virtuelle Red Hat :

  1. Si la machine virtuelle dispose d’un accès Internet, exécutez le script directement à partir de la machine virtuelle à l’aide de la commande suivante :

    curl -sL https://raw.githubusercontent.com/Azure/azure-support-scripts/refs/heads/master/Linux_scripts/rhui-check/rhui-check.py | sudo python2 -

  2. Si la machine virtuelle n’a pas d’accès Internet direct, téléchargez le script à partir de l’URL suivante : script de vérification RHUI, transférez le script vers la machine virtuelle, puis exécutez la commande suivante :

    sudo python2 ./rhui-check.py

  3. Le script génère un rapport qui inclut tous les problèmes détectés. La sortie du script est également enregistrée /var/log/rhuicheck.log après l’avoir exécutée.

Solution 1

Pour un système RHEL, consultez Résoudre les problèmes de certificat RHUI Red Hat dans Azure ou Résoudre les problèmes de connectivité Red Hat RHUI dans Azure.

Pour les autres distributions Linux, assurez-vous que la communication avec le référentiel correspondant est autorisée via le port 443. En outre, assurez-vous que le système d’exploitation utilise un certificat valide si un certificat valide est requis.

Scénario 2 : Problème de dépendance

Vous pouvez rencontrer plusieurs erreurs lorsque vous rencontrez un conflit de dépendance lors d’une mise à jour. Les sous-sections suivantes affichent les symptômes de sortie des erreurs de dépendance classiques.

Symptôme 2a

Error: 
 Problem: package leapp-0.16.0-2.el8.noarch requires python3-leapp = 0.16.0-2.el8, but none of the providers can be installed
  - package python2-leapp-0.16.0-1.el7_9.noarch conflicts with python3-leapp provided by python3-leapp-0.16.0-2.el8.noarch
  - package python3-leapp-0.16.0-2.el8.noarch conflicts with python2-leapp provided by python2-leapp-0.16.0-1.el7_9.noarch
  - cannot install the best update candidate for package leapp-0.16.0-1.el7_9.noarch
  - problem with installed package python2-leapp-0.16.0-1.el7_9.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Symptôme 2b

Error: 
 Problem 1: package systemd-udev-239-78.el8.x86_64 requires systemd(x86-64) = 239-78.el8, but none of the providers can be installed
  - cannot install the best update candidate for package systemd-udev-239-74.el8_8.5.x86_64
  - package systemd-239-78.el8.x86_64 is filtered out by exclude filtering
 Problem 2: package systemd-container-239-78.el8.x86_64 requires systemd(x86-64) = 239-78.el8, but none of the providers can be installed
  - cannot install the best update candidate for package systemd-container-239-74.el8_8.5.x86_64
  - package systemd-239-78.el8.x86_64 is filtered out by exclude filtering
 Problem 3: package systemd-pam-239-78.el8.x86_64 requires systemd = 239-78.el8, but none of the providers can be installed
  - cannot install the best update candidate for package systemd-pam-239-74.el8_8.5.x86_64
  - package systemd-239-78.el8.i686 is filtered out by exclude filtering
  - package systemd-239-78.el8.x86_64 is filtered out by exclude filtering
 Problem 4: systemd-libs-239-74.el8_8.5.i686 has inferior architecture
  - package systemd-239-74.el8_8.5.x86_64 requires systemd-libs = 239-74.el8_8.5, but none of the providers can be installed
  - cannot install both systemd-libs-239-78.el8.x86_64 and systemd-libs-239-74.el8_8.5.x86_64
  - cannot install the best update candidate for package systemd-libs-239-74.el8_8.5.x86_64
  - problem with installed package systemd-239-74.el8_8.5.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Solution 2

Lorsque vous rencontrez un problème de dépendance, commencez par identifier la combinaison spécifique de package et de version manquante ou incompatible. Le yum message d’erreur indique généralement la combinaison de versions de package requise, mais n’est pas disponible.

Solution pour le symptôme 2a : Supprimer l’ancien package

Pour Symptôme 2a, yum rejette une transaction et retourne un message d’erreur. L’erreur est due à l’incompatibilité nn entre le python2-leapp package d’une version antérieure et la dernière version.

Pour corriger cette erreur, vous devez supprimer l’ancien package qui provoque le conflit (dans ce cas, python2-leapp-0.16.0-1.el7_9.noarch) en exécutant la commande suivante yum remove :

sudo yum remove python2-leapp-0.16.0-1.el7_9.noarch

Ensuite, vous pouvez continuer la mise à jour ou l’installation du package requis.

Solution pour le symptôme 2b : supprimer l’exclusion du package du fichier de configuration

Pour le symptôme 2b, yum rejette une transaction et retourne un message d’erreur. Un filtre d’exclusion provoque l’erreur.

Pour corriger cette erreur afin de pouvoir reprendre la mise à jour ou l’installation du package requis, vérifiez que le systemd package n’est pas exclu dans le fichier de configuration /etc/yum.conf ou /etc/dnf.conf . Pour vérifier si l’exclusion de systemd package se produit, exécutez une commande telle que la combinaison suivantecat/grep :

sudo cat /etc/yum.conf | grep -i exclude

Si le systemd package est exclu, la sortie suivante s’affiche :

exclude=systemd

Pour mettre fin à cette exclusion de package, utilisez un éditeur de texte (par viexemple, ou vimnano) pour supprimer ou commenter l’entrée de la ligne « exclude » dans le fichier /etc/yum.conf ou /etc/dnf.conf.

Scénario 3 : Version incorrecte de Python

Les yumoutils et dnf les rpmoutils sont écrits en Python et dépendent de l’interpréteur Python pour fonctionner correctement. Plus précisément, ils s’appuient sur certaines fonctionnalités et bibliothèques fournies par l’interpréteur Python pour exécuter leur code et interagir avec le système. La modification de la version par défaut de Python installée sur le système peut entraîner des problèmes au sein yum ou dnf en raison d’une dépendance à des versions et configurations Python spécifiques.

Par exemple, vous pouvez rencontrer l’une des erreurs suivantes si vous n’avez pas installé la version correcte de Python :

  • « Syntaxe non valide »

    yum list all
  File "/usr/bin/yum", line 30
    except KeyboardInterrupt, e:
                            ^
SyntaxError: invalid syntax

  • « Aucun module nommé yum »

    yum repolist
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named yum

  • « Interpréteur incorrect : Aucun fichier ou répertoire de ce type »

    bash: /usr/bin/yum: /usr/bin/pythonX.X: bad interpreter: No such file or directory

Solution 3

En consultant la documentation officielle de votre distribution Linux, vous pouvez vérifier en toute confiance la version python par défaut et la comparer à la version installée sur votre système. Ce processus permet de garantir la cohérence et la compatibilité entre les dépendances logicielles et les configurations système.

Après avoir identifié la version par défaut de Python pour votre distribution Linux, vous pouvez déterminer la version actuellement installée en exécutant l’une des commandes suivantes :

sudo ls -al `which python`

sudo ls -lrth /usr/bin/python*

sudo rpm -V python

Si vous vérifiez qu’une version non prise en charge de Python est en cours d’utilisation, vous avez plusieurs options pour résoudre ce problème.

Supprimez le lien symbolique vers la version non prise en charge de Python et créez un lien symbolique vers la version prise en charge de Python en exécutant les commandes suivantes :

sudo cd /usr/bin
sudo unlink python
sudo ln -s python2.7 python  # Modify if necessary.

Solution 3b : Réinstaller Python à l’aide de RPM

Réinstallez le package Python en exécutant la commande suivante rpm :

sudo rpm -ivh python-<release>.<arch>.rpm --replacepkgs --replacefiles

Solution 3c : Réinstaller Python à partir d’une machine virtuelle de secours

Réinstallez le package Python à partir d’une machine virtuelle de secours. Pour obtenir des instructions, consultez Les bibliothèques et packages principaux système manquants.

Scénario 4 : Packages en double

Si une interruption se produit lors yum de la mise à jour, yum peut conserver les anciennes versions de package en même temps que les nouveaux packages qu’il installe. Les packages en double peuvent entraîner une confusion dans les opérations système lors de l’utilisation ultérieure de l’outil et éventuellement provoquer des erreurs « multilib protégées » ou des problèmes de dépendance trompeurs.

Les scénarios suivants sont typiques :

  • Exécution yum update sur Secure Shell (SSH) et interruptions de connectivité pendant le processus de mise à jour

  • Envoi d’un SIGINT signal et d’un kill -2 signal au yum processus, ou sélection de Ctrl+C pour arrêter le yum processus pendant son exécution active

  • L’expérience d’un redémarrage du système au milieu du processus de mise à jour

Solution 4

Il existe deux solutions possibles : essayez de terminer la transaction ou supprimez manuellement les packages dupliqués. Les étapes permettant d’effectuer ces approches diffèrent en fonction de la distribution et de la version de votre installation Linux.

Solution 4a : Essayez de terminer la transaction

  1. Essayez de terminer la transaction en exécutant la commande yum-complete-transaction suivante :

    sudo yum-complete-transaction

    Si l’opération réussit sans quitter d’autres doublons, passez à l’étape 2.

  2. Si des doublons sont présents, résolvez cette transaction en spécifiant le --cleanup-only paramètre dans la yum-complete-transaction commande :

    sudo yum-complete-transaction --cleanup-only

Solution 4b : Supprimer manuellement les doublons

  1. Supprimez manuellement les packages dupliqués en exécutant les commandes suivantes. La yum check commande peut nécessiter beaucoup de temps, mais l’obtention de sa sortie est essentielle pour procéder à ces étapes :

    sudo tar -cjf /tmp/rpm_dbbkp.tar.bz2 /var/lib/{rpm,yum}
sudo yum check &> /tmp/yumcheck
grep "duplicate" /tmp/yumcheck | awk '{ print $NF }' | egrep -v "\:" > /tmp/duplicaterpms
grep "duplicate" /tmp/yumcheck | awk '{ print $NF }' | egrep ":" | awk -F':' '{ print $NF }' >> /tmp/duplicaterpms
for i in $(cat /tmp/duplicaterpms); do sudo rpm -e --justdb --nodeps $i; done
sudo yum update

  2. Une fois les doublons supprimés, si un nouveau noyau a été inclus dans la transaction ayant échoué, réinstallez le noyau pour vous assurer que la génération correcte des entrées GRAND Unified Bootloader (GRUB), le disque RAM initial (initrd) et le système de fichiers RAM initial (initramfs) sont installés.

    sudo yum remove kernel-<newversion>-<release>.<arch>
sudo yum install kernel-<newversion>-<release>.<arch>

Scénario 5 : Yum ne fonctionne pas et affiche une erreur « 404 Introuvable »

Un message d’erreur « 404 Introuvable » dans la yum sortie indique qu’il yum n’a pas pu trouver le package ou la ressource sur le serveur. Ce problème se produit généralement si yum vous tentez de télécharger ou d’accéder à un package à partir d’un référentiel, mais le fichier de package ou les métadonnées associés à celui-ci sont manquants ou indisponibles sur le serveur. Ce scénario a diverses causes, notamment les suivantes :

  • Le package ou la ressource a été supprimé du référentiel.

  • L’URL ou la configuration du référentiel est incorrecte.

  • Les problèmes réseau empêchent yum l’accès au serveur de référentiel.

  • Il y a eu un temps d’arrêt ou une maintenance temporaires du serveur.

Des exemples de cette erreur sont présentés dans l’exemple de sortie pour différentes distributions Linux.

Red Hat Enterprise Linux 9 for x86_64 - Supplem  46  B/s |  14  B     00:00    
Errors during downloading metadata for repository 'rhel-9-for-x86_64-supplementary-rhui-rpms':
  - Status code: 404 for https://rhui4-1.microsoft.com/pulp/repos/content/dist/rhel9/rhui/9.1/x86_64/supplementary/os/repodata/repomd.xml (IP: 52.142.4.99)
Error: Failed to download metadata for repo 'rhel-9-for-x86_64-

Solution 5

Les solutions possibles suivantes s’appliquent à différentes distributions Linux.

Veillez à suivre le processus approprié lorsque vous basculez entre les référentiels de cycle de vie EUS (Extended Update Support) et les référentiels non-EUS, ou de non-EUS à EUS. Pour plus d’informations, consultez comportement de mise à jour d’image.

Si l’erreur se produit généralement parce qu’une valeur incorrecte est utilisée pour /etc/yum/vars/releasever et /etc/dnf/vars/releasever, ou parce que la valeur doit être absente (pour les référentiels non EUS), procédez comme suit :

  1. Vérifiez si votre système utilise des référentiels EUS ou non-EUS. Pour ce faire, exécutez la combinaison de commandes suivante rpm/grep :

    sudo rpm -qa | grep -i rhui

    Le format de nom de fichier généré par la commande dépend du type de référentiel, comme indiqué dans le tableau suivant.

    Type de dépôt Format du nom de fichier
    UES rhui-azure-rhelX-eus-new-version-release.noarch<><>
    non-UES rhui-azure-rhelX-new-version-release.noarch<><>

  2. Déterminez la valeur actuelle de la version de mise en production en exécutant la commande suivante cat .

    Version de RHEL Commande
    RHEL 7 sudo cat /etc/yum/vars/releasever
    RHEL 8 et 9 sudo cat /etc/dnf/vars/releasever

  3. Modifiez et utilisez la valeur correcte pour la version de mise en production :

    • Si votre système utilise des référentiels EUS, vérifiez que le verrou de version approprié est appliqué. Dans l’exemple suivant, le verrou de version est ajouté pour RHEL 9.2, car RHUI EUS les référentiels sont utilisés :

      sudo sh -c 'echo 9.2 > /etc/dnf/vars/releasever'

      Remarque

      Le support pour RHEL7 EUS a pris fin le 30 août 2021. Nous vous recommandons de ne plus utiliser de référentiels EUS dans RHEL7.

      RHEL 8.Les versions x pour EUS sont disponibles. Ces versions incluent RHEL 8.8, 8.6, 8.4, 8.2 et 8.1.

      RHEL 9.Les versions x pour EUS sont disponibles. Actuellement, ces versions incluent RHEL 9.2 et 9.0.

      Pour plus d’informations sur la disponibilité des versions, consultez Red Hat Enterprise Linux Life Cycle.

    • Si votre système utilise des référentiels non-EUS, veillez à supprimer le verrou de version pour le fichier /etc/yum/vars/releasever ou /etc/dnf/vars/releasever en exécutant la commande suivante.

      Version de RHEL Commande
      RHEL 7 sudo echo "" > /etc/yum/vars/releasever
      RHEL 8 et 9 sudo echo "" > /etc/dnf/vars/releasever

Scénario 6 : Problème de base de données RPM

Les erreurs suivantes s’affichent si vous exécutez le rpm, , up2dateyumou dnftdnf la commande :

error: rpmdb: BDB0113 Thread/process 24669/140693557245760 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 - (-30973)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

Ces erreurs peuvent se produire pour l’une des raisons suivantes :

  • Bases de données RPM rompues
  • Une autre application utilisant la base de données
  • Espace insuffisant dans le répertoire /var/lib/rpm

Solution 6

Régénérez la base de données RPM en procédant comme suit :

Important

Avant d’effectuer ces étapes, assurez-vous que suffisamment d’espace disque libre est disponible.

  1. Créez une sauvegarde du répertoire /var/lib/rpm en exécutant la tar commande :

    sudo tar zcvf /var/lib/rpm-backup.tar.gz /var/lib/rpm

  2. Pour éviter les verrous obsolètes, supprimez les fichiers __db* et vérifiez l’intégrité du fichier Packages :

    sudo cd /var/lib/rpm
sudo rm -f __db.*
sudo /usr/lib/rpm/rpmdb_verify Packages

  3. Régénérez la base de données RPM en exécutant la rpm commande :

    sudo rpm -vv --rebuilddb

Scénario 7 : Échec de la commande Yum et retourne « [Errno 14] Erreur HTTPS 403 --Forbidden »

Les erreurs suivantes s’affichent si vous exécutez la yum commande sur un Red Hat 7.x machine virtuelle connectée à RHUI.

https://rhui4-1.microsoft.com/pulp/repos/content/dist/rhel/rhui/server/7/7Server/x86_64/rh-common/os/repodata/repomd.xml: [Errno 14] HTTPS Error 403 - Forbidden

Solution 7

  1. Vérifiez si un package curl tiers est installé sur votre machine virtuelle :

    sudo rpm -qa | grep -i curl

    rpm -q --queryformat '%{VENDOR}\n' curl libcurl

    curl-7.73.0-2.0.cf.rhel7.x86_64 
libcurl-7.73.0-2.0.cf.rhel7.x86_64
libcurl-devel-7.73.0-2.0.cf.rhel7.x86_64 

    city-fan.org repo http://www.city-fan.org/ftp/contrib/

    Si un package tiers est installé, accédez à l’étape 2.

    Important

    Les packages curl provenant de sources tierces sont fournis avec leurs propres fichiers binaires et certificats qui ne sont pas reconnus par Red Hat. Cette incompatibilité entraîne l’expérience des problèmes d’yum.

  2. Utilisez l’une des méthodes suivantes pour dowloader la dernière version du curl, libcurlet libcurl-devel les packages fournis pour RHEL 7.9 :

    • Téléchargez les packages manuellement en vous connectant à Red Hat Download, puis chargez les fichiers rpms sur la machine virtuelle affectée.

    • Connectez-vous à une machine virtuelle (PAYGO)RHEL 7.9 opérationnelle, téléchargez les packages requis à l’aide de la yumdownloader commande, puis copiez les fichiers rpms sur la machine virtuelle affectée :

      sudo yumdownloader curl.x86_64 libcurl.x86_64 libcurl-devel.x86_64

  3. Rétrogradez les packages curl à l’aide des fichiers rpms de l’étape 2 :

    sudo cd /path/location/of/rpms/downloaded
sudo yum downgrade curl-X.XX.0-XX.el7_9.X.x86_64.rpm libcurl-X.XX.X-XX.el7_9.X.x86_64.rpm libcurl-devel-X.XX.X-XX.el7_9.X.x86_64.rpm --disablerepo=*

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.