CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

Paquets cassés sous Debian : réparer un apt bloqué par « held broken packages »

une machine de bureau ouverte posee sur un etabli, cables ranges, tournevis pose a plat

apt refuse d’installer le moindre paquet dès qu’il affiche « E: Unable to correct problems, you have held broken packages. » : le résolveur d’APT n’a pas trouvé d’ensemble de versions cohérent avec l’état de la base dpkg, et cette phrase ne désigne pas un paquet mis en attente par apt-mark hold. La chaîne exacte se lit dans apt-pkg/algorithms.cc, aux fonctions pkgProblemResolver::Resolve et ResolveByKeep du dépôt officiel d’APT. Le diagnostic passe par dpkg --audit, qui classe les paquets hors état normal et propose la correction ; la réparation suit l’ordre écrit dans la référence Debian, apt --fix-broken install avant dpkg --configure -a. Les valeurs citées ici ont été relevées sous Debian 12 (bookworm), avec dpkg 1.21.22 et APT 2.6.1. Le reste des dépannages de ce genre se trouve dans la rubrique Debian.

Sommaire
  1. Deux messages sortent du même calcul, et le mot held n’annonce pas un paquet en attente
  2. L’audit tient en quatre commandes, chacune avec sa sortie
  3. La réparation suit l’ordre de la référence Debian : –fix-broken d’abord, –configure -a ensuite
  4. Le script fautif, puis la base abîmée : deux pannes que l’audit ne répare pas
  5. Le préfixe, le hold et le drapeau reinstreq décident des cas qui résistent
  6. Sources

Deux messages sortent du même calcul, et le mot held n’annonce pas un paquet en attente

La fonction pkgProblemResolver::Resolve du code d’APT écrit « Unable to correct problems, you have held broken packages. » quand son calcul se termine avec au moins un paquet cassé ; elle rend auparavant « Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. » quand le paquet fautif n’est pas protégé. Le commentaire « See if this is the result of a hold » précède ce test dans apt-pkg/algorithms.cc, et la fonction ResolveByKeep produit le même message final. Aucun paquet en attente n’est donc nécessaire pour déclencher l’erreur. La page apt-mark(8) définit showhold comme la liste des paquets dont l’installation, la mise à jour et le retrait automatiques sont bloqués, et sudo apt-mark unhold nom-du-paquet lève ce blocage. Le catalogue de traduction d’APT rend le mot held par « garder en l’état ».

E: Unable to correct problems, you have held broken packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Le préfixe E: de ces deux lignes est écrit en dur dans le fichier error.cc d’APT 2.6.1, la version livrée avec Debian 12. Un paquet resté à demi configuré, une suite mélangée dans les sources ou une dépendance absente du dépôt mènent à la même impasse. La référence Debian range le mélange de suites parmi les fautes qui cassent la cohérence des paquets, et les fichiers qui portent ces sources sont décrits avec les dépôts APT.

L’audit tient en quatre commandes, chacune avec sa sortie

dpkg --audit lit la base /var/lib/dpkg/status et rend, pour chaque paquet hors état normal, une phrase qui dit quoi faire. La page dpkg(1) livrée avec dpkg 1.21.22 décrit cette action comme un contrôle de cohérence et d’intégrité de la base : elle cherche les paquets partiellement installés, ceux dont les données de contrôle ou les fichiers manquent, puis dpkg suggère la correction. Quatre commandes font le tour de la question, dans cet ordre : l’audit global, le même audit limité à un paquet, l’inventaire des états en trois lettres, et la simulation de la réparation par APT. Aucune n’écrit dans la base. La dernière désactive même les verrous le temps du calcul, comme l’écrit la page apt-get(8). Une base saine rend une sortie vide, et c’est le seul cas où l’audit ne dit rien.

  1. Toute la base, d’un seul coup.

    dpkg --audit

    À l’écran : rien quand tout est en ordre, sinon des blocs introduits par une phrase du type :

    The following packages are in a mess due to serious problems during
installation.  They must be reinstalled for them (and any packages
that depend on them) to function properly:

    D’autres en-têtes annoncent les paquets unpacked but not yet configured, only half configured, only half installed, awaiting processing of triggers, ou ceux auxquels il manque le fichier de contrôle md5sums. Ces textes sont définis dans src/main/enquiry.c du code de dpkg, et le catalogue français les traduit, par exemple « Les paquets suivants sont à demi configurés ».

  2. Le même audit, limité à un paquet.

    dpkg --audit nom-du-paquet

    À l’écran : le bloc qui concerne ce paquet, ou rien s’il est dans un état normal. La page dpkg(1) date ce contrôle paquet par paquet de dpkg 1.17.10, et le nom se place après l’action.

  3. Les états sous forme de trois lettres, pour trier la liste.

    dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package} ${Version}\n' | grep -Ev '^[a-z]{2} '

    À l’écran : une ligne par paquet hors état normal, avec trois caractères, le nom et la version. La page dpkg-query(1) lit ces caractères comme l’action souhaitée, l’état du paquet et l’erreur : ii pour installé, iF pour à demi configuré, iU pour dépaqueté, iH pour à demi installé, et un R en troisième position quand dpkg réclame une réinstallation. Une lettre majuscule à l’une de ces places annonce, d’après la même page, un paquet capable de poser de graves problèmes.

  4. Le plan de réparation, sans rien écrire.

    apt-get -s --fix-broken install

    À l’écran : une ligne par opération prévue, Inst pour un dépaquetage, Conf pour une configuration, Remv pour un retrait. La page apt-get(8) indique que les crochets encadrent les paquets cassés et que des crochets vides signalent une rupture sans conséquence. La simulation se lance sans root et sans verrou, avec une réserve écrite : un utilisateur ordinaire peut manquer de droits de lecture, ce qui fausse le calcul.

Les quatre commandes d’audit, leur lecture et leur écriture dans la base dpkg
Commande Source lue Écrit dans /var/lib/dpkg Résultat à l’écran
dpkg --audit la base /var/lib/dpkg/status non les paquets groupés par problème, ou rien
dpkg --audit nom-du-paquet la base /var/lib/dpkg/status non le bloc du paquet nommé, ou rien
apt-get -s --fix-broken install les index APT et la base dpkg non, verrous désactivés les lignes Inst, Conf et Remv du plan
sudo apt --fix-broken install les index APT et la base dpkg oui, par l’intermédiaire de dpkg les paquets manquants installés ou retirés

La réparation suit l’ordre de la référence Debian : –fix-broken d’abord, –configure -a ensuite

Une installation lancée avec dpkg -i sur un système où il manque des dépendances se termine en paquet partiellement installé. La section 2.6.4 de la référence Debian traite ce cas de figure : elle indique d’installer les paquets de dépendances manquants, puis de configurer les paquets laissés de côté. Les deux commandes qui suivent appliquent cet ordre. La page apt-get(8) écrit que l’option -f, écrite en clair --fix-broken, corrige un système aux dépendances cassées sur place ; sans nom de paquet, APT déduit la solution probable. La page dpkg(1) réserve --configure -a aux paquets dépaquetés mais pas encore configurés, et la commande rend une ligne par paquet repris. Deux avertissements de la page apt-get(8) expliquent les impasses qui restent : -f combiné à -m peut produire une erreur selon les cas, et une structure de dépendances très abîmée peut exiger une intervention manuelle, le plus souvent dpkg --remove sur les paquets fautifs.

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

À l’écran : une ligne Setting up nom-du-paquet (version) ... par paquet repris ; sous locale française, elle devient Paramétrage de nom-du-paquet (version) .... La gestion courante reprend ensuite avec l’administration Debian.

Le script fautif, puis la base abîmée : deux pannes que l’audit ne répare pas

Le blocage n’a parfois rien à voir avec les dépendances. Quand une commande d’un script de maintenance renvoie une erreur, la gestion des paquets s’arrête et le système conserve des paquets partiellement installés, écrit la référence Debian en section 2.6.6. Quatre scripts peuvent être en cause pour un même paquet, dans /var/lib/dpkg/info/ : preinst, postinst, prerm et postrm, chacun suffixé du nom du paquet. Relancer dpkg --configure -a rejoue le script fautif et bute sur la même erreur. La référence propose deux retouches, réservées à un administrateur averti : mettre en commentaire la ligne fautive en la précédant d’un #, ou la faire passer pour réussie en ajoutant || true à sa fin. Le second cas est plus grave, car un fichier /var/lib/dpkg/status perdu ou corrompu ne se reconstitue pas tout seul.

tail -n 20 /var/log/dpkg.log

À l’écran : les dernières lignes datées du journal, aux formats que la page dpkg(1) décrit à l’option --log, YYYY-MM-DD HH:MM:SS status état paquet version-installée pour un changement d’état et YYYY-MM-DD HH:MM:SS configure paquet version-installée version-disponible pour une configuration.

ls -l /var/lib/dpkg/status-old /var/backups/dpkg.status*

La page dpkg(1) note que le fichier /var/lib/dpkg/status est sauvegardé chaque jour dans /var/backups, et la table 2.17 de la référence Debian nomme /var/lib/dpkg/status-old pour la première génération, /var/backups/dpkg.status.* pour les suivantes. À l’écran : une ligne par copie conservée, avec sa date, ses droits et sa taille. L’échec de la commande signale une machine sans filet, et la réinstallation documentée de Debian devient la sortie de secours.

Le préfixe, le hold et le drapeau reinstreq décident des cas qui résistent

Trois questions reviennent quand la réparation ne suffit pas, et chacune a sa réponse dans les pages de manuel. L’ordre des deux commandes de réparation ne s’inverse pas, la simulation se relit avant d’agir, et le préfixe des erreurs dépend de la commande employée depuis Debian 13. Le drapeau reinstreq, décrit par dpkg(1), marque un paquet cassé qui exige une réinstallation et refuse le retrait ordinaire ; l’option --force-remove-reinstreq existe pour ce cas précis, avec un avertissement écrit dans la même page sur les morceaux de paquet qui resteront sur le système. Un paquet en hold arrête la réparation tant qu’il n’est pas libéré, et la page apt-mark(8) fournit les deux commandes qui vont par paire, hold et unhold. Les cinq réponses qui suivent tiennent en une commande, une option ou une valeur.

Dans quel ordre lancer –fix-broken et –configure -a ?

La référence Debian fixe l’ordre en section 2.6.4 : d’abord sudo apt --fix-broken install, qui comble les dépendances manquantes, puis sudo dpkg --configure -a, qui termine les configurations en attente. L’inverse laisse le problème intact, puisque dpkg travaille sur ce qui est déjà téléchargé et que la même référence note qu’il fonctionne sans connexion réseau.

Comment lire la simulation d’apt-get -s –fix-broken install ?

Chaque ligne annonce une opération dpkg, note la page apt-get(8) : Inst pour un dépaquetage, Conf pour une configuration, Remv pour un retrait. Les crochets encadrent un paquet cassé, et des crochets vides une rupture sans conséquence. Rien n’est écrit et les verrous sont désactivés, ce qui autorise autant de passages que nécessaire avant la vraie commande.

Pourquoi apt écrit Error: là où apt-get écrit E: ?

Sous Debian 13, le fichier error.cc d’APT 3.0.3 choisit le préfixe en comparant le niveau APT::Output-Version à 30, et seule une commande qui demande le niveau 3.0 reçoit « Error: » : c’est le cas d’apt, tandis qu’apt-get garde « E: ». Sous Debian 12, le fichier error.cc d’APT 2.6.1 écrit la lettre E en dur, donc les deux commandes se ressemblent. Le message qui suit le préfixe ne change pas d’une version à l’autre.

Un paquet marqué reinstreq refuse de partir : quelle option le débloque ?

La page dpkg(1) décrit le drapeau reinstreq comme un paquet cassé qui exige une réinstallation et qui ne peut pas être retiré sans --force-remove-reinstreq. La même page prévient que ce forçage peut laisser des morceaux du paquet sur le système, que dpkg oubliera ensuite. La tentative se place après une copie de /var/lib/dpkg/status, et la réinstallation propre du paquet reste la voie normale.

La réparation peut-elle modifier un paquet en hold ?

Pas par défaut. La page apt-get(8) écrit que --assume-yes fait abandonner la commande plutôt que de changer un paquet en attente, et elle qualifie --allow-change-held-packages de dangereuse, apparue avec APT 1.1. Le geste réversible tient en trois temps : sudo apt-mark unhold nom-du-paquet, la réparation, puis sudo apt-mark hold nom-du-paquet.

Sources