Ubuntu 24.04 : « dpkg a été interrompu » — la séquence de réparation sûre (pas de roulette)

Ce message arrive toujours au pire moment possible. Vous essayez de patcher un serveur, d’installer un pilote ou d’importer une bibliothèque pour un déploiement, et Ubuntu répond :
« dpkg a été interrompu, vous devez exécuter manuellement ‘dpkg –configure -a’ ».

Vous pouvez forcer les choses. Les gens le font. Et parfois ça « marche » de la même façon que tirer une clé USB sans l’éjecter « marche » — jusqu’à la catastrophe. Voici la séquence de réparation sûre pour Ubuntu 24.04 :
elle termine ce qui est en attente, corrige ce qui est cassé et vous explique pourquoi c’est cassé — sans transformer votre base de paquets en scène de crime.

Ce que l’erreur signifie vraiment (et ce qu’elle ne signifie pas)

La pile de gestion de paquets d’Ubuntu est essentiellement un système en couches :
APT (apt/apt-get) est le résolveur et le téléchargeur de haut niveau, et
dpkg est l’installateur bas niveau qui décompresse les fichiers, exécute les scripts du mainteneur et met à jour la base de données d’état des paquets.
Quand dpkg est interrompu — coupure de courant, processus tué, disque plein, contention de verrou ou échec d’un script mainteneur — APT ne peut pas continuer en toute sécurité tant que la machine à états de dpkg n’est pas revenue à un point cohérent.

La partie effrayante est que « interrompu » ne signifie pas toujours « planté ». Cela veut souvent dire « une autre opération de paquet est en cours » ou « une opération précédente a laissé des paquets à l’état semi-configuré ». Cette différence importe, car la correction est différente. Le chemin sûr commence par observer, pas par marteler les boutons.

Voici le modèle mental qui vous évite des ennuis :

• La base de données de dpkg est la source de vérité : /var/lib/dpkg/status plus les fichiers de support sous /var/lib/dpkg/.
• « Configuré » est un jalon : les fichiers décompressés ne suffisent pas ; les scripts du mainteneur doivent réussir.
• Les verrous sont un dispositif de sécurité : ils empêchent deux installateurs d’éditer la base en même temps.
• La plupart des événements « dpkg interrompu » sont récupérables : à moins que vous ne commenciez à supprimer au hasard des fichiers dans /var/lib/dpkg/.

Une citation qui devrait figurer dans chaque runbook d’astreinte :
L’espoir n’est pas une stratégie. — Général Gordon R. Sullivan

Répliques de diagnostic rapide

Quand le temps presse, vous n’avez pas besoin d’un cours de philosophie. Vous avez besoin du chemin le plus rapide vers « qu’est-ce qui me bloque » et « est-il sûr de continuer ».
C’est l’ordre que j’utilise sur des machines de production.

1) Un autre processus de gestion de paquets est-il en concurrence ?

La cause la plus fréquente est aussi la plus ennuyeuse : une autre instance apt/dpkg tourne (souvent unattended-upgrades).
Si vous la tuez aveuglément, vous risquez d’interrompre dpkg à nouveau et d’empirer la situation.

2) dpkg est-il réellement bloqué sur un script mainteneur ou attend-il une saisie ?

dpkg peut sembler « interrompu » lorsqu’un script postinst est bloqué (attente réseau, redémarrage de service en impasse, DNS cassé),
ou lorsqu’il attend une décision de configuration mais que vous n’êtes pas attaché à un terminal.

3) Avez-vous des problèmes de disque, d’inodes ou de système de fichiers ?

Peu d’espace disque dans / ou /var peut provoquer des fichiers d’état partiellement écrits et des étapes unpack/configure échouées.
Sur des systèmes avec /var séparé ou de petites partitions root, c’est classique.

4) Et seulement ensuite : exécutez les étapes de réparation dpkg

La séquence sûre commence par finir les configurations en attente, puis réparer les dépendances, puis relancer les triggers interrompus.
Si vous sautez directement à « supprimer les fichiers de verrou » ou « rm -rf /var/lib/dpkg/info », vous jouez à la roulette avec votre gestionnaire de paquets.

Faits et historique intéressants (court, utile et un peu nerd)

1. dpkg a précédé apt : dpkg est apparu au milieu des années 1990 comme outil de paquet de Debian ; apt est arrivé plus tard comme résolveur de dépendances superposé.
2. Les verrous sont volontairement simples : dpkg utilise des verrous système de fichiers afin qu’un environnement de récupération minimal puisse raisonner sur l’état des paquets.
3. Les scripts du mainteneur sont de vrais programmes : les scripts postinst/prerm peuvent faire presque n’importe quoi — redémarrer des services, créer des utilisateurs, migrer des données — donc « installer un paquet » est effectivement une exécution d’automatisation contrôlée.
4. Les triggers ont réduit le travail redondant : les triggers dpkg (comme la mise à jour des caches d’icônes ou de man-db) ont été ajoutés pour éviter que de nombreux paquets n’exécutent chacun les mêmes opérations coûteuses.
5. Les unattended-upgrades ont changé la surface de panne : une fois que les serveurs ont commencé à appliquer automatiquement les mises à jour de sécurité, la contention de verrous est devenue une cause majeure d’erreurs dpkg visibles par les humains.
6. La base de données d’état de dpkg est en texte clair : /var/lib/dpkg/status peut être lu avec un pager, et en urgence peut être réparée — soigneusement — car ce n’est pas un blob binaire.
7. dpkg a des états “à moitié installé” par conception : les transitions d’état des paquets sont enregistrées pour que dpkg puisse reprendre, pas pour faire comme si rien ne s’était passé.
8. Les “conffiles” sont spéciaux : dpkg traite les fichiers de configuration différemment, et les invites de configuration interrompues tournent souvent autour des changements de conffiles.

La séquence de réparation sûre (pas à pas, sans roulette)

Voici la séquence que je recommande sur Ubuntu 24.04 quand vous voyez « dpkg a été interrompu ».
Elle est sûre parce qu’elle répond à trois questions dans l’ordre :
(1) Y a-t-il quelque chose d’actif ?
(2) Qu’est-ce qui est cassé maintenant ?
(3) Quelle est l’action minimale pour atteindre un état cohérent ?

Étape 0 : Obtenez un shell root et arrêtez d’improviser

Utilisez une seule session privilégiée (sudo -i) et gardez-la ouverte. Ne lancez pas apt dans cinq terminaux à la fois.
Si vous êtes sur un système distant, utilisez une session persistante (tmux/screen) pour qu’une coupure SSH ne devienne pas la prochaine « interruption » de dpkg.

Étape 1 : Vérifier les gestionnaires de paquets en cours et les verrous

Il y a deux types de « verrouillé » :
un vrai processus le détient (bon signe), ou un fichier de verrou obsolète existe parce qu’un processus est mort au mauvais moment (moins courant, mais réel).
Vous le diagnostiquez en vérifiant qui possède le verrou.

Étape 2 : Si quelque chose tourne, attendez — puis décidez si vous devez intervenir

Si unattended-upgrades fait son travail, laissez-le finir. Le coût d’attendre cinq minutes est faible comparé au coût d’imposer un état partiel d’upgrade.
Si c’est bloqué depuis une heure et que vous ne voyez aucun progrès, vous pouvez devoir intervenir — mais faites-le avec des preuves : logs, strace ou état du service.

Étape 3 : Si rien ne tourne, terminez d’abord les configurations en attente

dpkg --configure -a n’est pas magique. Il parcourt simplement les paquets en état « non configuré » et exécute leurs scripts de configuration.
Si un paquet est à moitié installé, la configuration peut échouer tant que les dépendances ne sont pas présentes — c’est pourquoi la réparation des dépendances est l’étape suivante, pas la première.

Étape 4 : Réparez les dépendances avec apt en mode “fix broken”

Une fois que dpkg a tenté de configurer tout ce qu’il peut, lancez la correction des dépendances d’APT.
C’est là qu’APT peut décider d’installer des dépendances manquantes ou d’ajuster des versions pour satisfaire les contraintes.

Étape 5 : Relancez configure pour terminer les paquets nouvellement décompressés

La réparation des dépendances décompresse souvent des paquets mais les laisse en attente de configuration. Relancez dpkg configure.
Oui, cela semble redondant. C’est aussi comme cela que vous obtenez un système cohérent au lieu d’un système « plutôt correct ».

Étape 6 : Vérifiez la santé de dpkg/apt et nettoyez

Confirmez qu’aucun paquet n’est resté à l’état à moitié installé ou non configuré, et vérifiez qu’APT peut effectuer une opération normale.
Ce n’est qu’ensuite que vous poursuivez avec l’installation/mise à jour que vous vouliez initialement.

Blague n°1 : Supprimer les fichiers de verrou pour “fixer” dpkg, c’est comme enlever le détecteur de fumée pour “fixer” le bip. C’est plus calme jusqu’à la partie intéressante.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici des tâches réelles que vous pouvez exécuter immédiatement. Chacune inclut la commande, ce que la sortie signifie habituellement, et la décision à prendre ensuite.
Je suppose que vous êtes sur Ubuntu 24.04 et que vous avez sudo.

Task 1: Confirm your OS and context (don’t assume)

cr0x@server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

Signification : Vous êtes réellement sur la 24.04 (Noble). Certains comportements de packaging diffèrent selon les versions.
Décision : Poursuivez avec ces étapes ; si vous êtes dans un container ou sur un OS dérivé, ajustez vos attentes (systemctl peut ne pas se comporter normalement).

Task 2: See if dpkg/apt is currently running

cr0x@server:~$ ps aux | egrep -i 'apt|dpkg|unattended|packagekit' | grep -v egrep
root         812  0.0  0.2  18332  9780 ?        Ss   10:11   0:00 /usr/bin/unattended-upgrade-shutdown --wait-for-signal
root         925  0.2  1.1 115184 46392 ?        S    10:12   0:01 /usr/bin/python3 /usr/bin/unattended-upgrade
root        1044  0.0  0.1  10420  5364 ?        Ss   10:12   0:00 /usr/bin/dpkg --status-fd 39 --configure --pending

Signification : dpkg configure des paquets sous le contrôle d’un unattended-upgrades.
Décision : Attendez. Ne lancez pas apt en parallèle. Si vous devez intervenir, capturez d’abord les logs (voir tâches suivantes).

Task 3: Identify who holds the lock (and whether it’s real)

cr0x@server:~$ sudo fuser -v /var/lib/dpkg/lock-frontend
                     USER        PID ACCESS COMMAND
/var/lib/dpkg/lock-frontend:
                     root       1044 F....  dpkg

Signification : Le PID 1044 (dpkg) détient légitimement le verrou.
Décision : Laissez-le finir ou dépannez ce processus (Task 6/7). Ne supprimez pas les fichiers de verrou.

Task 4: If the lock exists, check if a process is holding it

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dpkg    1044 root    3uW  REG  252,0        0  945 /var/lib/dpkg/lock-frontend

Signification : Le fichier de verrou est ouvert par dpkg.
Décision : Même décision que ci-dessus : attendez ou déboguez dpkg ; ne « supprimez le verrou » pas.

Task 5: If no process holds the lock, verify it’s stale (carefully)

cr0x@server:~$ sudo fuser -v /var/lib/dpkg/lock-frontend
cr0x@server:~$ echo $?
1

Signification : Aucun processus n’utilise ce fichier. Le code de sortie 1 est typique pour « aucun utilisateur ».
Décision : Vous pouvez envisager le nettoyage d’un verrou obsolète — mais seulement après avoir confirmé qu’aucun processus apt/dpkg n’existe (Task 2) et que vous avez des logs pour comprendre la dernière panne.

Task 6: Watch dpkg progress in logs

cr0x@server:~$ sudo tail -n 80 /var/log/dpkg.log
2025-12-28 10:12:18 configure linux-image-6.8.0-41-generic:amd64 6.8.0-41.41
2025-12-28 10:12:19 status unpacked linux-modules-6.8.0-41-generic:amd64 6.8.0-41.41
2025-12-28 10:12:24 configure openssh-server:amd64 1:9.6p1-3ubuntu13.5
2025-12-28 10:12:25 trigproc man-db:amd64 2.12.0-4build2 <none>

Signification : dpkg progresse dans configure et le traitement des triggers. Si les horodatages avancent, il est vivant.
Décision : Attendez. Si les horodatages s’arrêtent longtemps sur un paquet spécifique, examinez les scripts de ce paquet (Task 12).

Task 7: Check journald for apt/dpkg service restart failures

cr0x@server:~$ sudo journalctl -b -u unattended-upgrades --no-pager -n 60
Dec 28 10:12:08 server unattended-upgrades[925]: Installing the upgrades failed!
Dec 28 10:12:08 server unattended-upgrades[925]: error: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Dec 28 10:12:08 server unattended-upgrades[925]: Traceback (most recent call last):
Dec 28 10:12:08 server unattended-upgrades[925]:   ...

Signification : unattended-upgrades a rencontré l’interruption de dpkg et a abandonné. Cela ne signifie pas que dpkg tourne encore.
Décision : Si aucun processus dpkg n’existe, procédez à la réparation manuelle (Task 9 et suivantes).

Task 8: Confirm you have disk space and inodes (classic silent killer)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        30G   29G  420M  99% /

Signification : Vous êtes à 99% sur root. dpkg écrit dans /var/lib/dpkg et décompresse dans / ; cela peut absolument provoquer des échecs en cours de transaction.
Décision : Libérez de l’espace avant la réparation. Nettoyez le cache de paquets, les logs ou les anciens kernels (Task 8b/8c).

cr0x@server:~$ df -i /
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda2      1966080 1891120  74960   97% /

Signification : Les inodes sont aussi presque pleins. Beaucoup de petits fichiers peuvent casser les étapes unpack/configure.
Décision : Trouvez les consommateurs d’inodes (par ex. tempêtes de logs, répertoires de cache) avant de retenter dpkg.

Task 9: Dry-run the repair action: see what dpkg thinks is pending

cr0x@server:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 linux-image-6.8.0-41-generic  Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Signification : dpkg a un paquet spécifique bloqué « à moitié configuré ».
Décision : Vous pouvez lancer une configuration globale (dpkg --configure -a) ou cibler ce paquet. Démarrez par la config globale à moins que vous ne déboguiez un coupable connu.

Task 10: Run the canonical dpkg recovery step (with visibility)

cr0x@server:~$ sudo dpkg --configure -a
Setting up linux-image-6.8.0-41-generic (6.8.0-41.41) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
Setting up openssh-server (1:9.6p1-3ubuntu13.5) ...
Processing triggers for man-db (2.12.0-4build2) ...

Signification : dpkg configure les paquets en attente et exécute les triggers. S’il finit sans erreurs, vous avez généralement terminé.
Décision : S’il échoue, capturez le paquet en échec et le message, puis utilisez apt fix-broken (Task 11) ou déboguez le script (Task 12/13).

Task 11: Repair dependencies (the safe apt move)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  linux-modules-6.8.0-41-generic
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.
Need to get 32.1 MB of archives.
After this operation, 137 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

Signification : APT a trouvé des dépendances manquantes et propose un plan de correction concret.
Décision : Si le plan a l’air raisonnable, acceptez. S’il veut supprimer des paquets critiques, arrêtez-vous et inspectez le pinning/les paquets en hold (Task 14/15).

Task 12: If a maintainer script fails, run it with tracing mentality (don’t guess)

cr0x@server:~$ sudo dpkg --configure linux-image-6.8.0-41-generic
Setting up linux-image-6.8.0-41-generic (6.8.0-41.41) ...
run-parts: failed to exec /etc/kernel/postinst.d/zz-update-grub: No such file or directory
dpkg: error processing package linux-image-6.8.0-41-generic (--configure):
 installed linux-image-6.8.0-41-generic package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-6.8.0-41-generic

Signification : Le postinst du kernel attendait un script hook qui manque. C’est une vraie erreur, pas « dpkg qui fait des siennes ».
Décision : Identifiez quel paquet fournit ce script (généralement lié à grub), réinstallez/réparez-le, puis relancez dpkg configure.

Task 13: Find which package owns a missing file (quick ownership check)

cr0x@server:~$ dpkg -S /etc/kernel/postinst.d/zz-update-grub
dpkg-query: no path found matching pattern /etc/kernel/postinst.d/zz-update-grub

Signification : Aucun paquet installé ne possède actuellement ce fichier. Soit il a été supprimé, soit il vous manque un paquet que vous devriez avoir.
Décision : Réinstallez le fournisseur probable (habituellement grub2-common) ou restaurez le répertoire de hook depuis des sauvegardes/gestion de configuration.

Task 14: Check for held packages (APT will silently refuse to solve otherwise)

cr0x@server:~$ apt-mark showhold
linux-image-generic

Signification : Quelque chose est mis en hold. Cela peut empêcher la réparation des dépendances du kernel et laisser dpkg en boucle.
Décision : Si le hold est intentionnel (conformité), planifiez une mise à jour contrôlée du kernel. S’il est accidentel, enlevez le hold et relancez fix-broken.

Task 15: Review dpkg state for “half-installed” or “unpacked” packages

cr0x@server:~$ dpkg -l | awk '$1 ~ /^(iF|iU|iH|rc|un|pn)$/ {print}'
iF  linux-image-6.8.0-41-generic  6.8.0-41.41  amd64  Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Signification : iF indique « installé, échec de configuration ». C’est votre indice majeur.
Décision : Corrigez la configuration ou les dépendances de ce paquet ; n’essayez pas des installations aléatoires tant qu’il est cassé.

Task 16: Check for broken packages APT knows about

cr0x@server:~$ sudo apt-get check
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 linux-image-6.8.0-41-generic : Depends: linux-modules-6.8.0-41-generic but it is not installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

Signification : APT confirme des problèmes de dépendances.
Décision : Utilisez apt-get -f install (Task 11), pas des installations dpkg manuelles, sauf si vous faites une récupération hors ligne explicitement.

Task 17: Clean APT’s cache if disk is tight (safe, reversible)

cr0x@server:~$ sudo apt-get clean
cr0x@server:~$ sudo du -sh /var/cache/apt/archives
12K	/var/cache/apt/archives

Signification : Le cache est vidé ; vous avez récupéré de l’espace disque (parfois des gigaoctets).
Décision : Retentez dpkg configure et apt fix-broken si la pression disque vous bloquait.

Task 18: If you must remove a stale lock file, do it only after proving it’s stale

cr0x@server:~$ sudo rm -v /var/lib/dpkg/lock-frontend
removed '/var/lib/dpkg/lock-frontend'

Signification : Vous avez supprimé un fichier de verrou. Ce n’est pas une maintenance de routine ; c’est une étape de dernier recours après avoir confirmé qu’aucun processus ne le possède.
Décision : Exécutez immédiatement dpkg --configure -a pour réconcilier l’état, puis effectuez un apt check. Si vous vous êtes trompé, vous pouvez corrompre la base dpkg.

Blague n°2 : Si votre “fix” implique rm -f /var/lib/dpkg/*, félicitations — vous avez inventé une nouvelle stratégie de déploiement appelée « archéologie ».

Listes de contrôle / plan étape par étape

Checklist A: The safe repair sequence (standard case)

1. Ouvrez une session admin stable (tmux/screen si distant).
2. Confirmez qu’aucun autre apt/dpkg ne tourne :
   • ps aux | egrep -i 'apt|dpkg|unattended|packagekit'
   • fuser -v /var/lib/dpkg/lock-frontend
3. Vérifiez l’espace disque et les inodes disponibles :
   • df -h /
   • df -i /
4. Auditez l’état de dpkg : dpkg --audit
5. Configurez les paquets en attente : sudo dpkg --configure -a
6. Corrigez les dépendances : sudo apt-get -f install
7. Relancez la configuration : sudo dpkg --configure -a
8. Vérifiez la santé :
   • sudo apt-get check
   • dpkg -l | awk '$1 ~ /^(iF|iU|iH)$/ {print}'

Checklist B: When a process is holding the lock

1. Identifiez le PID : fuser -v /var/lib/dpkg/lock-frontend
2. Voyez ce qu’il fait : ps -fp PID et tail -f /var/log/dpkg.log
3. S’il progresse : attendez.
4. S’il est bloqué :
   • Vérifiez s’il attend une saisie (TTY) ou s’il est bloqué sur un redémarrage de service.
   • Inspectez journald pour le service de ce paquet.
5. Seulement si vous devez l’arrêter : essayez d’arrêter d’abord le pilote de haut niveau (unattended-upgrades), puis relancez dpkg configure immédiatement après.

Checklist C: When you’re disk-full or inode-full

1. Libérez de l’espace en toute sécurité :
   • apt-get clean
   • Rotation/compression des logs si la politique le permet.
   • Supprimez les anciens kernels avec précaution (évitez de supprimer celui en cours d’utilisation).
2. Puis exécutez :
   • dpkg --configure -a
   • apt-get -f install
   • apt-get check

Erreurs courantes : symptôme → cause racine → correction

Ce sont les schémas que vous verrez en vraie vie opérationnelle. L’astuce est de traiter les symptômes comme des indices, pas comme une insulte.

Mistake 1: “Could not get lock /var/lib/dpkg/lock-frontend”

• Symptôme : apt indique qu’il ne peut pas acquérir le verrou.
• Cause racine : Un autre processus apt/dpkg tourne (souvent unattended-upgrades ou PackageKit), ou un fichier de verrou obsolète existe.
• Correction : Utilisez fuser -v et lsof pour confirmer. Si un processus le détient, attendez. Si aucun processus ne le détient, supprimez le verrou obsolète seulement après avoir confirmé qu’aucun apt/dpkg ne tourne, puis exécutez dpkg --configure -a.

Mistake 2: Running apt repeatedly while dpkg is broken

• Symptôme : Chaque commande apt se termine par « dpkg a été interrompu » ou « dpkg returned an error code (1). »
• Cause racine : dpkg a des paquets dans un état non terminal (iF/iU), et APT refuse d’avancer.
• Correction : Exécutez dpkg --audit, puis dpkg --configure -a, puis apt-get -f install.

Mistake 3: Killing dpkg because “it’s taking too long”

• Symptôme : Après kill -9, vous obtenez des échecs de configuration répétés et un bazar plus profond.
• Cause racine : dpkg était en cours de transaction ou exécutait des triggers ; vous l’avez à nouveau interrompu.
• Correction : Si dpkg est vraiment bloqué, diagnostiquez le point de blocage : tail des logs, vérifiez le script mainteneur spécifique, contrôlez le disque et les dépendances réseau. Évitez SIGKILL sauf si le système doit redémarrer et que vous avez accepté une fenêtre de réparation.

Mistake 4: Deleting random files under /var/lib/dpkg

• Symptôme : dpkg signale des fichiers info manquants, des paquets « non installés » mais des fichiers présents, ou des incohérences du fichier status.
• Cause racine : Quelqu’un a essayé de « réinitialiser » dpkg en supprimant des métadonnées.
• Correction : Restaurez depuis une sauvegarde si possible. Sinon, réinstallez soigneusement les paquets affectés et reconstruisez l’état. Attendez-vous à un travail manuel. La prévention la plus sûre est : ne faites pas ça dès le départ.

Mistake 5: Ignoring conffile prompts in noninteractive environments

• Symptôme : dpkg semble bloqué ; l’utilisation CPU est faible ; rien n’avance dans dpkg.log.
• Cause racine : dpkg attend une invite pour un fichier de configuration mais n’a pas d’interface utilisable (par ex. exécuté sous automatisation sans DEBIAN_FRONTEND réglé convenablement).
• Correction : Exécutez en mode interactif, ou définissez une politique pour les conffiles et exécutez avec des options non-interactives en automatisation. Puis relancez dpkg --configure -a.

Mistake 6: APT wants to remove “important” packages to fix dependencies

• Symptôme : apt-get -f install propose de supprimer des paquets centraux (meta-paquets kernel, ssh, composants systemd).
• Cause racine : Dépôts mixtes, versions pinées, upgrade partiel ou paquets en hold empêchant une solution cohérente.
• Correction : Vérifiez les holds (apt-mark showhold), vérifiez la politique (apt-cache policy package) et identifiez les mélanges de dépôts. N’acceptez pas des suppressions massives sur un serveur important.

Trois mini-histoires d’entreprise depuis le terrain

Incident causé par une mauvaise hypothèse : « C’est juste un verrou obsolète »

Une entreprise de taille moyenne gérait une flotte de serveurs Ubuntu pour des services internes. Un ingénieur a vu le message d’interruption de dpkg pendant une fenêtre de patch nocturne.
Ils avaient déjà rencontré des problèmes de verrou et ont supposé que c’était la même histoire : supprimer le fichier de verrou, relancer apt, rentrer chez soi.

Le verrou n’était pas obsolète. Un unattended-upgrade reconfigurait activement libc et autres. L’ingénieur a supprimé le fichier de verrou et lancé un apt en parallèle.
Maintenant, deux processus écrivaient dans la base dpkg, et le fichier status est devenu incohérent. Le redémarrage suivant n’a pas échoué de façon spectaculaire ; il a échoué silencieusement — des services ne sont pas remontés parce que quelques paquets étaient en « half-configured » et certains scripts postinst n’avaient jamais été exécutés.

Ils ont passé la matinée suivante à faire une danse inconfortable : vérifier les états dpkg, réinstaller des paquets et démêler des chaînes de dépendances. Le pire n’était pas la correction technique.
C’était l’incertitude : chaque étape de « réparation » pouvait empirer les choses, et l’équipe ne savait plus dans quel état la machine devait être.

La leçon n’était pas « ne supprimez jamais les verrous ». C’était : traitez les verrous comme un symptôme, pas comme le diagnostic.
Si un processus tient le verrou, le supprimer est du sabotage déguisé en confiance. Prouvez qu’il est obsolète, puis agissez.

Une optimisation qui s’est retournée contre eux : « Accélérer les upgrades en forçant le non-interactif partout »

Une autre organisation avait une bonne idée : les upgrades ne doivent jamais demander d’input, car les prompts bloquent l’automatisation. Ils ont appliqué des variables agressives par défaut :
DEBIAN_FRONTEND=noninteractive, plus des options pour accepter automatiquement les changements de fichiers de configuration. Ils ont déployé ça sur leurs serveurs.

Ça a bien marché jusqu’à ce que ça ne marche plus. Une mise à jour critique d’un service a introduit un changement de conffile où la nouvelle config supprimait un chemin d’inclusion legacy.
Sur des serveurs avec des personnalisations, le choix automatique de conffile a effectivement écrasé des réglages locaux. dpkg a terminé rapidement — mission accomplie, non ?

Puis est venue la défaillance secondaire : les services redémarrés par le postinst ont pris la nouvelle config, et certaines instances ont échoué les contrôles de santé.
La pipeline de déploiement a blâmé l’application. Le SRE d’astreinte a blâmé le réseau. Personne n’a regardé les logs dpkg pendant une heure parce que « les paquets ont été installés correctement ».

Une fois qu’ils ont retracé l’origine, la correction a été simple : restaurer l’état voulu de la gestion de configuration et définir des politiques de conffile par paquet.
La correction la plus difficile a été culturelle : la vitesse n’est pas le seul KPI ; la déterminisme des upgrades compte davantage.
Une politique dpkg adaptée à l’automatisation a besoin de garde-fous, pas d’un « ne jamais poser de questions » universel.

Une pratique ennuyeuse mais correcte qui a sauvé la mise : « Une session persistante, une mise à jour à la fois »

Une équipe de services financiers gérait des workloads régulés où le patching devait être rapide et auditable.
Leur runbook était ennuyeux : patcher uniquement depuis une session persistante, désactiver les opérations de paquets parallèles, snapshotter avant les upgrades risqués et logguer chaque action dans le ticket.
Les ingénieurs plaisantaient en disant que c’était du « paperwork avec sudo ».

Lors d’une mise à jour de routine, un script mainteneur s’est bloqué parce qu’un redémarrage de service attendait une dépendance temporairement indisponible sur le réseau (un miroir interne en coupure).
dpkg n’a pas planté ; il a attendu. Leur astreinte a suivi le runbook : garder la session, tailer les logs dpkg, vérifier que le processus tourne toujours et contrôler le disque.

Quand il est devenu clair que c’était bloqué sur le réseau, ils ont rétabli l’accès au miroir et dpkg a continué.
Pas de suppression de verrou. Pas de kill de dpkg. Pas d’upgrades partiels depuis plusieurs terminaux. Juste des vérifications méthodiques.

La morale : ce runbook a empêché un incident bien plus grave parce qu’il a préservé la capacité de dpkg à terminer proprement sa machine d’états.
Ennuyeux n’est pas l’opposé d’intelligent. C’est l’opposé du chaotique.

FAQ

1) Dois-je toujours exécuter dpkg --configure -a ?

Si vous voyez « dpkg a été interrompu », oui — après avoir confirmé qu’aucun autre processus de paquets ne tourne et que vous n’êtes pas à court de disque.
L’exécuter pendant qu’une autre instance de dpkg détient le verrou ne fera qu’ajouter du bruit.

2) Est-il sûr de supprimer /var/lib/dpkg/lock-frontend ?

Seulement quand vous avez prouvé qu’il est obsolète : aucun processus apt/dpkg/unattended-upgrades, et fuser/lsof montrent que personne ne détient le fichier.
Si un processus détient le verrou, supprimer le fichier est le mauvais type de « fix ».

3) Pourquoi apt me dit-il sans cesse d’exécuter dpkg manuellement ?

Parce que dpkg gère l’état bas niveau. APT n’essayera pas d’opérations complexes de dépendances si la base de dpkg indique des transitions inachevées.
C’est une fonctionnalité de sécurité, pas une attaque personnelle.

4) Que faire si dpkg est bloqué et ne produit aucune sortie ?

Vérifiez /var/log/dpkg.log pour connaître le dernier paquet touché. Puis suspectez : invite conffile, script postinst bloqué, redémarrage de service en attente ou épuisement des ressources.
Les logs journald révèlent souvent quel redémarrage de service échoue.

5) Puis-je redémarrer pour régler le problème ?

Le redémarrage peut éliminer un processus bloqué, mais il ne « répare » pas l’état de dpkg. Après un reboot, vous devrez typiquement encore exécuter
dpkg --configure -a et éventuellement apt-get -f install.
Redémarrer est acceptable si vous ne pouvez pas arrêter proprement un dpkg bloqué et que vous avez une fenêtre de maintenance.

6) Que signifie iF dans dpkg -l ?

iF signifie installé mais configuration échouée. C’est un état très exploitable : identifiez le paquet et corrigez ses dépendances ou ses erreurs postinst.

7) Pourquoi les paquets kernel apparaissent-ils si souvent dans ces incidents ?

Les mises à jour du kernel impliquent génération d’initramfs, hooks bootloader et triggers. Il y a plus d’éléments en mouvement que pour une petite librairie.
L’espace disque dans /boot ou des hooks grub manquants peuvent transformer une mise à jour normale en échec dpkg.

8) apt --fix-broken install diffère-t-il de apt-get -f install ?

Ils ont le même objectif : réparer les dépendances cassées. Le format de sortie diffère, et apt-get est plus stable pour le scripting.
Dans une situation de réparation, je préfère apt-get -f install car c’est plus prévisible.

9) Que faire si la base de données status de dpkg est corrompue ?

Vous verrez des erreurs de parsing ou des sections manquantes quand dpkg lit /var/lib/dpkg/status. À ce stade, vous êtes en territoire de récupération :
restaurez /var/lib/dpkg/ depuis des backups/snapshots si disponibles. Sinon, attendez-vous à une reconstruction manuelle et des réinstallations.
C’est exactement pourquoi jouer à la roulette avec les fichiers de verrou est une très mauvaise habitude.

10) Comment éviter que cela se reproduise ?

Ne lancez pas apt en parallèle, gardez une marge d’espace disque, surveillez le comportement d’unattended-upgrades et utilisez des sessions persistantes pour les upgrades.
La plupart des interruptions dpkg sont des échecs d’hygiène opérationnelle, pas des bugs exotiques.

Conclusion : prochaines étapes que vous ferez vraiment

La séquence de réparation sûre n’est pas compliquée. Elle est disciplinée :
prouvez si un gestionnaire de paquets tourne, vérifiez les ressources, terminez les configurations en attente, réparez les dépendances et validez l’état.
C’est tout. La différence entre une récupération propre et une journée perdue est de traiter dpkg comme une base de données (ça l’est) ou comme une machine à sous (ce qu’elle n’est pas).

Prochaines étapes :

1. Exécutez la réplique de diagnostic rapide dans l’ordre : process/lock → script bloqué → disque/inodes → dpkg configure.
2. Exécutez la checklist standard de réparation (configure, fix-broken, configure encore).
3. Vérifiez la santé avec dpkg --audit et apt-get check avant de retenter votre installation/mise à jour initiale.
4. Notez ce qui a causé l’interruption — pression disque, unattended upgrades, postinst défaillant — pour ne pas le revoir la semaine prochaine.