Proxmox « dpkg was interrupted » : réparer les paquets cassés sans réinstaller

Ce que signifie réellement « dpkg was interrupted »

Proxmox fonctionne sur Debian. Debian utilise dpkg pour effectuer les étapes bas-niveau d’extraction et de configuration.
apt est le résolveur/téléchargeur de plus haut niveau qui orchestre dpkg.
Quand dpkg est interrompu — coupure de courant, processus tué, disque plein, script pre/postinst cassé,
ou paquets en conflit — il laisse un état partiellement écrit dans /var/lib/dpkg/.

Le message célèbre signifie généralement que le gestionnaire de paquets vous dit :
« Je ne peux pas avancer tant que les étapes de configuration en attente ne sont pas terminées. »
Ce n’est pas une suggestion. C’est le journal de transaction qui vous demande de rejouer la partie incomplète.

Il y a deux grandes catégories de problèmes de « paquets cassés » sur Proxmox :

• Problèmes d’état pur dpkg/apt : fichiers de verrouillage, configuration interrompue, dépendances manquantes,
  extraction partielle. Ceux-ci sont réparables sur l’hôte avec des commandes prudentes.
• Problèmes de dépôts/mismatch : mélange de versions Debian, mélange de dépôts Proxmox,
  ou pinning mal configuré. Ceux-ci peuvent ressembler à des erreurs dpkg mais la vraie solution est d’arrêter de fournir
  des métadonnées apt incohérentes.

Votre objectif n’est pas de « faire taire apt ». Votre objectif est de rétablir une base de paquets propre et cohérente
afin que les mises à jour futures ne deviennent pas une roulette russe avec votre noyau, les modules ZFS ou l’interface de gestion.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.
(Pas ingénieur logiciel, mais toute rotation d’astreinte est d’accord avec lui.)

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : est-ce que dpkg tourne réellement ou est-il juste bloqué ?

Si une opération de paquet légitime est toujours en cours, ne la « corrigez » pas en la tuant. Laissez-la se terminer.
Si elle est bloquée, comprenez pourquoi avant de commencer à supprimer des fichiers de verrouillage comme un barbier médiéval.

Second : le système de fichiers est-il sain et inscriptible ?

« dpkg interrompu » signifie fréquemment « disque plein » ou « système racine monté en lecture seule ».
Sur un hôte Proxmox, cela peut provenir d’une croissance des logs, d’un local-lvm plein, d’un miroir cassé ou d’un SSD qui a rendu l’âme.

Troisième : apt reçoit-il des dépôts cohérents ?

Un nœud configuré avec le mauvais nom de code Debian ou des dépôts Proxmox mélangés peut échouer en cours de mise à jour et laisser
dpkg à moitié configuré. Réparer dpkg sans corriger les dépôts ne fait que rejouer l’échec, mais en plus fort.

Puis : réparer l’état dpkg, réparer les dépendances, vérifier les services Proxmox

Ce n’est qu’après avoir confirmé que dpkg n’est pas actif et que le système peut écrire sur le disque que vous lancez les étapes de réparation.
L’ordre importe : configurer les paquets en attente, réparer les dépendances, puis finir la mise à niveau.

Faits intéressants et bref historique (pourquoi ça revient)

1. dpkg est antérieur à apt. dpkg remonte aux débuts de Debian ; apt a été introduit plus tard pour gérer
   la résolution de dépendances et les dépôts distants de façon plus conviviale.
2. dpkg est volontairement « simple ». Il ne résout pas les dépendances ; il exécute les scripts de paquet
   et enregistre l’état. Cette simplicité le rend prévisible — et incapable de « deviner » comment récupérer.
3. Les scripts de paquets sont du code, pas des métadonnées. Les scripts preinst/postinst peuvent faire presque tout :
   mettre à jour initramfs, redémarrer des services, réécrire des configs. C’est du pouvoir et du danger.
4. Proxmox est une distribution Debian avec des paquets opinionnés. Proxmox ajoute son propre noyau,
   sa pile de gestion et ses règles de dépôt sur Debian, ce qui explique pourquoi le mélange de dépôts est plus pénalisant ici.
5. Le verrouillage est coopératif. Les fichiers de verrouillage dans /var/lib/dpkg/ et
   /var/lib/apt/lists/lock ne sont pas magiques ; ce sont des conventions. Les supprimer pendant qu’un processus est actif
   invite la corruption.
6. Les mises à niveau interrompues étaient plus fréquentes sur disques magnétiques. I/O lente, timeouts agressifs
   et humains qui redémarraient parce que « ça a l’air bloqué » ont créé beaucoup de systèmes à moitié configurés.
7. dpkg enregistre des états fins. Les paquets peuvent être « unpacked but not configured », « half-configured »,
   « triggers pending », etc. L’état exact indique souvent le type de panne.
8. Les triggers existent pour regrouper du travail. Des tâches comme update-initramfs ou
   update-ca-certificates peuvent être différées via des triggers — jusqu’à ce qu’une interruption les laisse en attente.

Sécurité d’abord sur un hôte Proxmox (ne pas briquer le nœud)

Sur un portable, vous pouvez forcer les réparations de paquets. Sur un hôte Proxmox qui héberge des VM/CT,
un peu de discipline est nécessaire :

• Ne redémarrez pas « pour nettoyer ». Un redémarrage ne corrige pas l’état dpkg. Il ajoute juste une nouvelle variable,
  comme des services qui échouent à démarrer parce que leurs paquets n’ont jamais fini de se configurer.
• N’arrêtez pas les services pve en plein upgrade sauf si nécessaire. Quand les paquets de gestion sont en flux,
  relancer pveproxy peut couper votre propre accès. Utilisez SSH et gardez une session root ouverte.
• Évitez les tentatives héroïques uniquement à distance. Si c’est un nœud en datacenter sans accès hors-bande,
  planifiez une fenêtre ou assurez-vous que l’IPMI/iKVM fonctionne. « Ce ne sont que des paquets » est la façon dont on se rit au milieu de la nuit.
• Faites un snapshot du disque racine si vous le pouvez. Si le système Proxmox est sur ZFS root, prenez un snapshot.
  S’il est sur LVM-thin et que vous avez un mécanisme de snapshot au niveau hyperviseur, utilisez-le. Restauration vaut mieux que regret.

Blague #1 : Supprimer aveuglément les fichiers de verrouillage dpkg, c’est comme couper le fil rouge parce qu’il « a l’air plus sûr ».
Parfois ça marche. Ce n’est pas un compliment.

Tâches pratiques de réparation (commandes, sorties, décisions)

Ci‑dessous les tâches que j’exécute réellement en production quand un nœud Proxmox affiche « dpkg was interrupted ».
Chaque tâche inclut : une commande, une sortie typique, ce que ça signifie et la décision à prendre.
Faites-les dans l’ordre sauf raison contraire.

Tâche 1 : Confirmer les processus apt/dpkg et s’ils sont bloqués

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | egrep -v egrep
root      1523  0.0  0.1  21440  9820 ?        Ss   10:11   0:00 /usr/bin/dpkg --configure -a
root      1544  0.2  0.1  72868 11640 ?        S    10:11   0:03 /usr/bin/perl /usr/share/debconf/frontend /var/lib/dpkg/info/pve-manager.postinst configure

Ce que ça signifie : dpkg est en cours et configure activement des paquets (ici c’est dans un postinst).

Décision : Attendez. Vérifiez CPU/disque. S’il est vraiment bloqué (pas d’I/O, aucun progrès pendant longtemps),
inspectez les logs et le script en cours avant de tuer quoi que ce soit.

Tâche 2 : Vérifier les fichiers de verrou dpkg sans les supprimer

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

Ce que ça signifie : Le verrou est détenu par dpkg PID 1523.

Décision : Ne pas supprimer les verrous. Si un verrou existe mais qu’aucun processus ne le tient, c’est différent.

Tâche 3 : Vérifier l’espace du système racine (disque plein classique)

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   60G   59G  320M 100% /

Ce que ça signifie : Vous êtes à court d’espace. dpkg ne peut pas décompresser/configurer de façon fiable.

Décision : Libérez de l’espace d’abord. Ne lancez pas les commandes de réparation tant que vous n’avez pas de marge.

Tâche 4 : Vérifier si le système de fichiers est passé en lecture seule

cr0x@server:~$ mount | grep ' on / '
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro)

Ce que ça signifie : Le root est monté en lecture seule. dpkg échouera à répétition.

Décision : Stop. Inspectez dmesg, la santé du stockage, et remontez uniquement si c’est sûr.
Un remontage en lecture-écriture indique généralement des erreurs système ou un problème d’appareil.

Tâche 5 : Lire les dernières entrées des logs dpkg/apt (trouver l’échec réel)

cr0x@server:~$ tail -n 40 /var/log/dpkg.log
2025-12-26 10:10:59 unpacked pve-manager:amd64 8.2.4
2025-12-26 10:11:01 configuring pve-manager:amd64 8.2.4
2025-12-26 10:11:04 status half-configured pve-manager:amd64 8.2.4
2025-12-26 10:11:04 error processing package pve-manager:amd64 (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1

Ce que ça signifie : L’échec est dans le script du paquet (postinst), pas dans la résolution de dépendances.

Décision : Vous devrez probablement lire la sortie du postinst (voir tâches suivantes) et corriger la cause sous-jacente.

Tâche 6 : Lancer la relecture de configuration dpkg (le correctif canonique)

cr0x@server:~$ sudo dpkg --configure -a
Setting up pve-manager (8.2.4) ...
Job for pveproxy.service failed because the control process exited with error code.
See "systemctl status pveproxy.service" and "journalctl -xeu pveproxy.service" for details.
dpkg: error processing package pve-manager (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 pve-manager

Ce que ça signifie : dpkg a fait son travail ; le paquet a échoué à cause d’un problème de démarrage/restart de service.

Décision : Ne relancez pas dpkg en espérant un changement. Déboguez l’échec du service.

Tâche 7 : Inspecter le service en échec (pveproxy est le suspect habituel)

cr0x@server:~$ systemctl status pveproxy.service --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 10:11:03 UTC; 12s ago
    Process: 1622 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
   Main PID: 1622 (code=exited, status=255/EXCEPTION)
     Status: "starting server"
     Error: unable to load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory

Ce que ça signifie : dpkg échoue car pveproxy ne peut pas démarrer à cause de certificats manquants.
C’est courant après des problèmes du système de fichiers de cluster, des permissions ou un état pve-cluster incomplet.

Décision : Corrigez la configuration Proxmox sous-jacente (régénération de certificats, santé de /etc/pve), puis relancez dpkg.

Tâche 8 : Vérifier la disponibilité de /etc/pve et la santé du système de fichiers de cluster

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   57
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-26 10:12:01
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1a
Quorate:          Yes

Ce que ça signifie : Le cluster est quoré, ce qui suggère fortement que /etc/pve devrait être monté et inscriptible.

Décision : Si ce n’est pas quoré, il peut être nécessaire de restaurer le quorum ou de travailler en mode local avec prudence.
Les nœuds non quorés causent souvent des effets secondaires étranges lors des scripts de paquet.

Tâche 9 : Régénérer les certificats Proxmox si c’est le blocage

cr0x@server:~$ sudo pvecm updatecerts --force
Generating new node certificate...
Restarting pveproxy and pvedaemon...
Done.

Ce que ça signifie : Les certificats du nœud ont été régénérés et les services redémarrés.

Décision : Réessayez dpkg --configure -a. Si la régénération échoue, vérifiez les permissions et le montage de /etc/pve.

Tâche 10 : Réparer automatiquement les dépendances (quand dpkg ne suffit pas)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following packages will be upgraded:
  pve-manager pveproxy pvedaemon
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/2,914 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pveproxy (8.2.3) ...
Setting up pvedaemon (8.2.3) ...
Setting up pve-manager (8.2.4) ...

Ce que ça signifie : apt a trouvé un plan de dépendances cohérent et l’a appliqué. Cela résout souvent les upgrades partiels.

Décision : Si apt propose la suppression de paquets centraux Proxmox (ex. pve-manager), stoppez et examinez les dépôts/pinning.

Tâche 11 : Identifier les paquets « à moitié installés » et leurs états

cr0x@server:~$ dpkg -l | awk '$1 ~ /^(iF|iU|iH|iW|rc)$/ {print}'
iF  pve-manager   8.2.4   amd64   Proxmox Virtual Environment manager
iU  pve-kernel-6.8 6.8.12-4 amd64 Proxmox kernel image

Ce que ça signifie : Ces paquets ne sont pas proprement installés/configurés.

Décision : Concentrez votre débogage sur ces paquets. Une image de noyau bloquée en iU peut casser la logique de boot future ou la compilation DKMS.

Tâche 12 : Vérifier les paquets en attente qui empêchent la résolution apt

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8
zfs-dkms

Ce que ça signifie : Quelqu’un a mis des paquets en hold. Parfois c’est voulu ; souvent c’est oublié.

Décision : Si les holds bloquent des mises à jour de sécurité/noyau, retirez-les délibérément et planifiez un redémarrage/test.

Tâche 13 : Retirer les holds (après avoir compris pourquoi ils existaient)

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.8 zfs-dkms
Canceled hold on pve-kernel-6.8.
Canceled hold on zfs-dkms.

Ce que ça signifie : Les paquets peuvent maintenant évoluer vers des versions cohérentes selon apt.

Décision : Suivez immédiatement par apt-get -f install ou apt full-upgrade pour converger.

Tâche 14 : Confirmer que la configuration des dépôts est cohérente (spécifique à Proxmox)

cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Ce que ça signifie : La release Debian est Bookworm et le dépôt Proxmox correspond à Bookworm. C’est bon.

Décision : Si vous voyez des noms de code mélangés (bullseye + bookworm) ou à la fois enterprise et no-subscription sans intention, corrigez cela d’abord.

Tâche 15 : Rafraîchir les listes de paquets et repérer les erreurs immédiates de dépôt

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Ce que ça signifie : Les dépôts sont joignables et les métadonnées cohérentes.

Décision : Si vous voyez des 401/403 ou des erreurs de signature, ne procédez pas aux mises à jour tant que l’accès/la confiance au dépôt n’est pas réparé.

Tâche 16 : Terminer la réparation avec une mise à niveau contrôlée

cr0x@server:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-kernel-6.8 pve-manager pveproxy pvedaemon
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 58.4 MB of archives.
After this operation, 312 MB of additional disk space will be used.
Do you want to continue? [Y/n] y

Ce que ça signifie : apt a un plan cohérent. Il met à jour des composants centraux ; c’est normal sur Proxmox.

Décision : Procédez pendant une fenêtre de maintenance si des noyaux sont concernés. Planifiez le redémarrage.

Tâche 17 : Vérifier que la base de paquets est propre

cr0x@server:~$ sudo dpkg --audit

Ce que ça signifie : L’absence de sortie est bonne : dpkg ne détecte pas de paquets cassés/à moitié installés.

Décision : S’il liste des paquets, vous avez encore du travail — revenez aux logs et aux scripts en échec.

Tâche 18 : Confirmer que les services de gestion Proxmox sont sains

cr0x@server:~$ systemctl is-active pveproxy pvedaemon pvestatd
active
active
active

Ce que ça signifie : Le plan de gestion est opérationnel.

Décision : Si l’un n’est pas actif, consultez journalctl -u avant de déclarer la victoire.

Tâche 19 : Nettoyer les anciens verrous seulement s’ils sont obsolètes (rare, mais réel)

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend
cr0x@server:~$ sudo ls -l /var/lib/dpkg/lock-frontend
-rw-r----- 1 root root 0 Dec 26 10:05 /var/lib/dpkg/lock-frontend

Ce que ça signifie : Aucun processus ne tient le verrou, mais le fichier existe (c’est normal). Les verrous sont des fichiers, pas des sockets.

Décision : Ne le supprimez pas juste parce qu’il existe. N’agissez que si apt se plaint explicitement d’un verrou et
que vous avez vérifié qu’aucun processus ne le tient.

Tâche 20 : Quand un script de paquet est cassé, relancez-le avec sortie de debug

cr0x@server:~$ sudo sh -x /var/lib/dpkg/info/pve-manager.postinst configure
+ set -e
+ systemctl daemon-reload
+ systemctl try-restart pveproxy.service
Job for pveproxy.service failed because the control process exited with error code.
+ exit 1

Ce que ça signifie : Le postinst échoue précisément au redémarrage du service.

Décision : Corrigez la dépendance du service (certificats, ports, config, espace disque) plutôt que de bricoler l’état dpkg.
Si vous devez garder le nœud en service, vous pouvez parfois empêcher temporairement les redémarrages — mais c’est un dernier recours qui doit être documenté.

Blague #2 : dpkg n’est pas « cassé », il vous tient simplement aux mêmes standards que votre gestionnaire de changements prétend avoir.

Trois mini-récits en entreprise issus du terrain

Incident causé par une mauvaise supposition : « C’est juste un paquet GUI »

Une entreprise de taille moyenne exploitait un cluster Proxmox à trois nœuds hébergeant des services internes : un serveur Git, de la supervision, des runners CI,
et quelques VM Windows que personne n’avouait posséder. Un après-midi, un admin a vu des mises à jour en attente et a lancé apt upgrade
sur un nœud pendant les heures de travail. La mise à jour a bloqué, puis le nœud a commencé à renvoyer « dpkg was interrupted ».

La mauvaise hypothèse était simple : ils pensaient que pve-manager était « juste l’interface web ». Ce n’est pas le cas. Les hooks du paquet
redémarrent des services, touchent des certificats et dépendent du système de fichiers de cluster. Pendant la mise à jour, le nœud
a brièvement perdu le quorum à cause d’un changement réseau séparé. Le postinst a essayé d’accéder à /etc/pve, a obtenu un état partiel,
et a échoué. dpkg s’est arrêté en cours de configuration.

Leur première réaction a été de redémarrer. Le nœud est revenu, mais le proxy n’a pas redémarré. Ils ne pouvaient plus utiliser l’interface web pour migrer les charges.
SSH fonctionnait toujours, mais l’équipe a perdu du temps à chercher « où Proxmox stocke le binaire GUI » comme s’il s’agissait d’une appli de bureau.

La correction n’a pas été dramatique. Ils ont restauré la connectivité du cluster, confirmé le quorum, régénéré les certificats du nœud, relancé
dpkg --configure -a, puis fini la mise à jour. La leçon majeure : sur Proxmox, les paquets de gestion sont des paquets opérationnels. Traitez-les comme une mise à jour de noyau d’hyperviseur.

Optimisation qui s’est retournée contre eux : « Automatisons tout la nuit »

Un autre environnement avait une initiative de « modernisation » : moins d’étapes manuelles, plus d’automatisation. Ils ont déployé unattended upgrades
sur les nœuds Proxmox. L’idée était louable — correctifs de sécurité sans oublis humains. L’implémentation ne l’était pas.

Ils ne l’ont pas alignée avec les fenêtres de maintenance ni avec la réalité du stockage. Certains nœuds avaient des partitions root petites et un fort turn-over de logs.
Une nuit, unattended upgrades a tenté d’appliquer un update de noyau et de nouveaux paquets firmware alors que le root était presque plein.
dpkg a décompressé à moitié, puis manque d’espace. Le nœud a continué d’héberger des VM, mais le prochain apt a affiché « dpkg was interrupted ».

La vraie partie amusante : leur automation retentait chaque heure. Toutes les heures elle heurtait le même échec, laissant la base de paquets dans un état
« presque configurée » perpétuel. Les alertes de monitoring étaient bruyantes mais vagues : « mises à jour échouent ». L’équipe a fini par les ignorer.

Ils ont résolu le problème en désactivant unattended upgrades sur les hyperviseurs, en ajoutant des contrôles explicites d’espace disque,
et en lançant les mises à jour pendant des fenêtres planifiées avec des vérifications post-op : audit dpkg, santé des services, et une file de reboot pour les changements de noyau.
L’automatisation c’est bien. Automatiser le chaos, c’est du chaos — juste plus rapide.

Pratique ennuyeuse mais juste qui a sauvé la mise : accès hors-bande et snapshots

Une troisième organisation avait une règle stricte : tout changement aux paquets d’hyperviseur nécessitait (1) accès console hors-bande testé,
(2) sauvegarde récente de config, et (3) plan de rollback. Ça semblait bureaucratique jusqu’à ce qu’un nœud meure de la façon la plus ennuyeuse :
un hic firmware a provoqué un remontage du système de fichiers en lecture seule pendant une mise à jour de paquets.

dpkg s’est arrêté en pleine transaction. Le nœud hébergeait toujours des charges critiques, et l’interface web est devenue instable car les services ne pouvaient
pas écrire dans /var. Mais comme ils avaient iKVM et un snapshot ZFS du root pris juste avant la maintenance,
ils ont pu prendre une décision calme : tenter la réparation d’abord, et si le FS nécessitait un fsck hors-ligne, revenir en arrière et évacuer.

Ils ont vérifié la santé du disque, confirmé que le pool root avait des erreurs, et décidé de ne pas forcer les écritures. Ils ont migré les VM hors du nœud,
redémarré en environnement de secours, réparé le système de fichiers, puis relancé la configuration dpkg. Le snapshot n’a même pas été nécessaire,
mais il a réduit la pression. C’est ce que l’ennui achète : du temps pour réfléchir.

Erreurs courantes : symptôme → cause racine → correction

1) Symbole : « Could not get lock /var/lib/dpkg/lock-frontend »

Cause racine : Un autre processus apt/dpkg tourne (ou est bloqué), ou un outil en arrière-plan applique des mises à jour.

Correction : Utilisez ps et lsof pour identifier le processus. S’il est légitime, attendez.
S’il est bloqué, examinez pourquoi (disque plein, NFS bloqué, postinst cassé). Tuez seulement en dernier recours,
puis lancez dpkg --configure -a.

2) Symbole : « dpkg was interrupted, you must manually run ‘dpkg –configure -a’ »

Cause racine : Des étapes de configuration de paquets sont en attente ; la base dpkg indique un état incomplet.

Correction : Lancez dpkg --configure -a. S’il échoue, suivez le script/service en échec,
pas vos sentiments. Lisez /var/log/dpkg.log et journalctl.

3) Symbole : dpkg configure échoue sur pve-manager/pveproxy à cause de certificats manquants

Cause racine : /etc/pve mal monté, problèmes de quorum, ou certificats manquants/corrompus.

Correction : Vérifiez pvecm status. Assurez le quorum. Régénérez les certificats avec
pvecm updatecerts --force, puis relancez la configuration dpkg.

4) Symbole : « No space left on device » pendant la mise à jour

Cause racine : Système de fichiers root plein ; dpkg ne peut pas décompresser/configurer. Parfois c’est /boot plein à cause d’anciens noyaux.

Correction : Libérez de l’espace en sécurité (nettoyer le cache apt, élaguer les logs, supprimer d’anciens noyaux si vous savez ce que vous faites).
Puis relancez dpkg --configure -a et apt-get -f install.

5) Symbole : apt veut supprimer les meta-paquets Proxmox (pve-manager, proxmox-ve)

Cause racine : Mélange de releases Debian, mauvais dépôt Proxmox, ou pinning causant des conflits de dépendances.

Correction : Stoppez. Auditez /etc/apt/sources.list*. Alignez les noms de code.
Supprimez les dépôts conflictuels. Relancez apt update et réévaluez.

6) Symbole : dpkg boucle sur des triggers (initramfs, ca-certificates) et ne finit jamais

Cause racine : La commande de trigger échoue (souvent à cause d’espace disque manquant, d’un hook noyau cassé,
ou d’un environnement update-initramfs défaillant).

Correction : Lancez l’outil de trigger manuellement et capturez les erreurs. Corrigez le problème sous-jacent,
puis relancez dpkg --configure -a.

7) Symbole : Les scripts de paquets se bloquent indéfiniment

Cause racine : Attente d’un arrêt de service qui ne se termine jamais, I/O bloquée, DNS qui bloque dans un script,
ou prompt interactif dans une session non interactive.

Correction : Consultez journalctl, confirmez la santé I/O, et assurez un frontend non interactif
si vous travaillez à distance. Si nécessaire, définissez DEBIAN_FRONTEND=noninteractive pour la réparation.

Listes de vérification / plan pas-à-pas

Phase 0 : Assurez-vous de ne pas le regretter

• Confirmez que vous avez accès SSH, et idéalement une console hors-bande.
• Confirmez que vous pouvez survivre à un redémarrage du plan de gestion (gardez une session ouverte).
• Vérifiez d’abord l’espace libre et la santé du système de fichiers.
• Si en cluster : confirmez le quorum. Les scripts qui touchent /etc/pve détestent l’ambiguïté.

Phase 1 : Diagnostiquer rapidement le mode de panne

1. Vérifiez les processus en cours : ps aux | egrep 'apt|dpkg'.
2. Vérifiez les verrous avec lsof.
3. Vérifiez l’espace disque (df -h) et les flags de montage (mount).
4. Lisez /var/log/dpkg.log et les entrées récentes du journal pour l’unité en échec.

Phase 2 : Réparer l’état dpkg et les dépendances

1. Lancez dpkg --configure -a.
2. S’il échoue, corrigez la cause (config service, certificats, stockage, dépôts).
3. Lancez apt-get -f install pour corriger les dépendances.
4. Lancez apt full-upgrade pour converger le système.
5. Vérifiez que dpkg --audit ne renvoie rien.

Phase 3 : Vérifications spécifiques Proxmox après la réparation

1. Vérifiez les services de gestion : systemctl is-active pveproxy pvedaemon pvestatd.
2. Confirmez l’état du cluster (si applicable) : pvecm status.
3. Confirmez l’alignement noyau/modules si ZFS est utilisé : assurez-vous que le nouveau noyau et les paquets zfs sont bien installés avant reboot.
4. Planifiez le redémarrage si le noyau a été mis à jour ; ne redémarrez pas « à l’aveugle » en période de charge.

FAQ

1) Puis-je corriger « dpkg was interrupted » sans redémarrer ?

En général oui. Les réparations dpkg/apt sont des opérations en espace utilisateur. Le redémarrage ne résout pas l’état de la base dpkg.
Redémarrez seulement après avoir installé un nouveau noyau ou corrigé un problème de système de fichiers le nécessitant.

2) Est-ce que lancer dpkg --configure -a est toujours sûr sur Proxmox ?

C’est la première étape correcte, mais « sûr » dépend de la raison de l’interruption. Si le disque est plein ou si le root est en lecture seule,
la commande échouera et peut aggraver la situation. Vérifiez d’abord la santé du système de fichiers.

3) apt veut supprimer proxmox-ve ou pve-manager. Dois-je l’autoriser ?

Non, pas sans précautions. C’est le signe d’un mauvais alignement de dépôts ou d’un chaos de dépendances.
Corrigez d’abord les dépôts et le pinning. Supprimer des meta-paquets peut laisser un hôte Debian Frankenstein
qui continue de faire tourner des VM jusqu’à ce que ce ne soit plus le cas.

4) Que faire si dpkg est bloqué dans un script postinst ?

Identifiez quel script avec ps, puis vérifiez ses dépendances : redémarrages de services, fichiers sous /etc/pve,
DNS ou stockage. S’il est vraiment bloqué (pas d’I/O, aucun progrès), enquêtez avec les logs et relancez le script en traçant.
Tuer dpkg est un dernier recours et doit être suivi d’étapes de réparation immédiates.

5) Dois-je arrêter les VM/containers avant de réparer des paquets ?

Pas toujours. Beaucoup de réparations peuvent se faire en live. Mais si vous mettez à jour le noyau, la pile ZFS, ou des services Proxmox critiques,
planifiez une fenêtre. L’hôte peut continuer d’exécuter des charges, mais l’accès de gestion peut vaciller pendant les redémarrages.

6) Pourquoi une erreur de certificat casse-t-elle dpkg ?

Parce que les scripts de paquet redémarrent souvent des services pour activer de nouvelles versions. Si pveproxy ne peut pas démarrer à cause de fichiers SSL manquants,
le postinst sort avec un code non nul. dpkg considère cela comme « paquet non configuré » et arrête la transaction.

7) Comment savoir que la base de paquets est à nouveau propre ?

Lancez dpkg --audit (aucune sortie = bon signe), vérifiez dpkg -l pour des états étranges (iF, iU),
et assurez-vous que apt-get -f install n’a plus rien à corriger.

8) Quand réinstaller Proxmox est-elle justifiée ?

Si le disque OS est corrompu au-delà de toute réparation raisonnable, si les dépôts ont été mélangés trop longtemps et que la résolution des dépendances
exige des suppressions massives, ou si vous ne pouvez pas faire confiance à la baseline du nœud. Même dans ce cas, évacuez d’abord les charges et reconstruisez proprement.

9) Le clustering change-t-il la façon de réparer les paquets ?

Oui. Les nœuds en cluster dépendent du quorum pour le comportement cohérent de /etc/pve. Si vous êtes non-quoré,
certaines opérations de gestion et scripts peuvent échouer. Restaurez le quorum d’abord si possible.

10) Puis-je « forcer » dpkg à ignorer des scripts en échec ?

Vous pouvez, mais vous ne devriez pas sauf en cas d’intervention chirurgicale contrôlée et documentée.
Forcer les installations en ignorant les échecs de postinst peut laisser des services non configurés et le nœud subtilement cassé.
Corrigez la cause plutôt.

Conclusion : prochaines étapes réellement utiles

« dpkg was interrupted » n’est pas une raison de réinstaller Proxmox. C’est une raison de ralentir et de réparer l’état comme un adulte :
vérifiez que dpkg n’est pas actif, vérifiez que le système peut écrire sur le disque, vérifiez que les dépôts sont cohérents, puis rejouez la
configuration et corrigez le script ou le service spécifique qui a échoué.

Prochaines étapes pratiques :

1. Lancez le diagnostic rapide : processus → santé disque/montage → dépôts.
2. Réparez avec dpkg --configure -a, puis apt-get -f install, puis apt full-upgrade.
3. Confirmez que dpkg --audit est propre et que les services Proxmox sont actifs.
4. Si un noyau a changé, planifiez le redémarrage — ne faites pas ça à l’improviste.
5. Après récupération, corrigez la cause racine : dimensionnement des disques, hygiène des dépôts, fenêtres de maintenance et accès hors-bande.