Proxmox « pve-apt-hook failed » : pourquoi les mises à jour sont bloquées et comment débloquer en toute sécurité

Ce que fait réellement « pve-apt-hook »

Proxmox VE repose sur Debian, mais ce n’est pas « juste Debian avec une interface web ». C’est un hôte de virtualisation avec des opinions : sur les noyaux, les dépôts, la cohérence de cluster, les chargeurs d’amorçage et l’ordre de packaging. Ces opinions sont encodées dans des outils, et l’un d’eux est un ensemble de hooks APT fournis par les paquets Proxmox (souvent via pve-manager et compagnons).

Les hooks APT sont des scripts qui s’exécutent avant ou après les opérations de paquet — pensez « contrôles pré-vol » et « nettoyage post-vol ». Proxmox les utilise pour éviter une classe de pièges fréquents sur les hyperviseurs :

• Mélanger des suites Debian ou des dépôts Proxmox de manière à produire des systèmes Frankenstein.
• Mettre à niveau vers un noyau ou un chargeur d’amorçage depuis lequel le nœud ne peut pas redémarrer proprement.
• Laisser des nœuds du cluster diverger en versions majeures puis s’étonner quand corosync ou l’API diffèrent.
• Casser les piles de stockage (ZFS, bibliothèques clientes Ceph) en mettant à jour des composants dans le mauvais ordre.
• Installer des paquets en conflit avec les méta-paquets Proxmox (comme les méta-paquets de noyau).

Quand un hook se termine avec un code non nul, APT le traite comme une erreur critique et s’arrête. C’est pourquoi vous voyez des mises à jour « bloquées » alors que le graphe de dépendances est correct. La garde s’est déclenchée.

Deux conséquences opérationnelles importantes :

1. La défaillance du hook est généralement un symptôme, pas la maladie. Corrigez la discordance sous-jacente (dépôts, état des paquets, verrou dpkg, config) et le hook cessera de hurler.
2. Contourner le hook est un dernier recours. Vous pouvez bidouiller les hooks APT, mais vous vous engagez alors à assumer ce que le hook tentait d’empêcher — possiblement à 2 h du matin après un redémarrage.

Idée paraphrasée (Gene Kranz) : Les échecs ne sont pas une option — pas en bravade, mais en discipline : vous concevez des systèmes qui n’acceptent pas les défaillances évitables.

Pourquoi les mises à jour sont bloquées : vrais modes de défaillance

1) Mélanges de dépôts : enterprise vs no-subscription, mauvaise suite, mauvais majeur

Le déclencheur le plus courant est l’incohérence des dépôts. APT calcule volontiers un chemin de mise à niveau à travers des dépôts mixtes. Proxmox, à raison, l’accepte moins bien. Problèmes typiques :

• Activation de pve-enterprise sans abonnement, qui renvoie HTTP 401/403 ou des erreurs de signature « not signed ».
• Avoir à la fois pve-enterprise et pve-no-subscription activés, produisant un chaos de pinning.
• Utiliser une suite Debian qui ne correspond pas à votre majeur Proxmox (par exemple, passer Debian à trixie alors que votre Proxmox majeur attend bookworm).
• Copier-coller une liste de sources depuis un billet de blog écrit pour une version Proxmox différente.

2) État APT/dpkg endommagé : installations interrompues, paquets à moitié configurés

Si dpkg a été interrompu ou si un script post-installation a échoué, les hooks Proxmox ont tendance à bloquer les mises à jour « normales » jusqu’à ce que l’état du packaging soit cohérent à nouveau. APT appelle cela « half-installed » ou « not fully installed or removed ». Proxmox appelle cela « non, pas aujourd’hui ».

3) Paquets en hold et noyaux épinglés

Les mises à jour de noyau ne sont pas comme la mise à jour de htop. Un paquet de noyau épinglé, un pve-kernel-* en hold, ou un méta-paquet désaccordé peuvent créer une situation où Proxmox essaie de vous maintenir sur des trajectoires de noyau supportées. Le hook bloque lorsqu’il détecte que vous êtes sur le point de dévier du chemin prévu.

4) Problèmes de chargeur d’amorçage / EFI, surtout après des changements de partition

Certaines machines se mettent à jour sans problème et ne plantent qu’après redémarrage — Proxmox est donc prudent ici. Si vous avez un ESP mal monté, un /boot/efi manquant, ou un /boot saturé, les mises à jour qui installent de nouveaux noyaux et images initramfs deviennent risquées.

5) Décalage de version dans le cluster et majeures mixtes

Dans un cluster, « mettre à jour un nœud seulement » peut être valide, mais les mises à niveau entre versions majeures exigent de la planification. Les hooks sont une des façons dont Proxmox vous encourage à éviter les sauts majeurs accidentels.

6) Couplage serré de la pile de stockage : ZFS et Ceph

Les nœuds Proxmox exécutent souvent ZFS ou des clients Ceph (ou les deux). Mettre à jour des bibliothèques, des modules noyau, ou des outils utilisateur dans le mauvais ordre peut casser les imports, les flags de fonctionnalités du pool, ou la compatibilité client. Les hooks ne résolvent pas tout, mais ils réduisent le risque de faire quelque chose d’évidemment dangereux.

Blague #1 : Un hook APT, c’est comme un agent de sécurité avec un casque : agaçant jusqu’au moment où il vous empêche de tomber dans le trou que vous avez creusé vous-même.

Playbook de diagnostic rapide

Quand l’erreur apparaît, ne commencez pas à « réparer » en éditant des fichiers au hasard. Faites le triage rapide dans l’ordre. Vous cherchez le premier goulot qui explique la défaillance du hook.

Première étape : APT est-il sain et les dépôts sont-ils joignables ?

• Exécutez apt update et lisez la première erreur, pas la dernière.
• Recherchez 401/403, « Release file », « not signed », erreurs TLS, problèmes DNS.
• Confirmez qu’un seul dépôt Proxmox prévu est activé (enterprise ou no-subscription, pas les deux).

Deuxième étape : dpkg est-il dans un état propre ?

• Vérifiez si dpkg --configure -a signale des problèmes.
• Vérifiez les paquets en hold (apt-mark showhold).
• Vérifiez les dépendances cassées (apt -f install).

Troisième étape : le blocage concerne-t-il les noyaux / l’amorçage ?

• Vérifiez l’espace libre dans /boot et /boot/efi.
• Confirmez quel noyau est en cours et quels noyaux sont installés.
• Sur un root ZFS, confirmez que l’état de proxmox-boot-tool est sain (si applicable).

Quatrième étape : considérations de cluster

• Si vous êtes en cluster, vérifiez si vous faites une mise à niveau majeure et si d’autres nœuds sont sur un autre majeur.
• Vérifiez la santé du quorum corosync avant de toucher aux paquets.

Tâches pratiques : commandes, sorties et décisions

Voici des tâches réelles que vous pouvez lancer sur un nœud Proxmox. Chacune inclut ce que la sortie implique et la décision suivante. Faites-les dans cet ordre approximatif sauf si vous connaissez déjà la cause probable.

Tâche 1 : reproduire l’échec avec un maximum de contexte

cr0x@server:~$ apt-get -o Debug::pkgProblemResolver=yes -o Debug::Acquire::https=true dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
...
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running hook scripts.

Ce que cela signifie : Vous avez confirmé qu’il s’agit d’une sortie de hook, pas d’un problème du résolveur. Le débogage autour de l’échec peut montrer quel contrôle a déclenché.

Décision : Allez vérifier les logs/messages spécifiques au hook, puis validez les dépôts et l’état de dpkg.

Tâche 2 : vérifier le hook exact et le paquet propriétaire

cr0x@server:~$ dpkg -S /usr/share/proxmox-ve/pve-apt-hook
pve-manager: /usr/share/proxmox-ve/pve-apt-hook

Ce que cela signifie : Le hook provient de pve-manager. C’est votre paquet de plan de contrôle, et il fait exprès de vous rappeler à l’ordre.

Décision : Ne le supprimez pas. Comprenez ce qui le contrarie.

Tâche 3 : exécuter APT update et lire les erreurs comme un SRE

cr0x@server:~$ apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Err:3 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  401  Unauthorized [IP: 51.91.38.34 443]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  401  Unauthorized
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Ce que cela signifie : Le dépôt enterprise est activé sans identifiants/abonnement. APT le désactive ; le hook Proxmox bloque souvent les mises à jour quand la configuration des dépôts est incohérente.

Décision : Soit ajoutez un accès enterprise valide, soit désactivez le dépôt enterprise et activez le dépôt no-subscription (proprement).

Tâche 4 : inspecter les listes de sources Proxmox et Debian

cr0x@server:~$ grep -R --line-number -E 'proxmox|pve|ceph' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
/etc/apt/sources.list.d/ceph.list:1:deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription

Ce que cela signifie : Les dépôts enterprise et no-subscription sont activés. C’est comme mettre deux volants différents dans la même voiture.

Décision : Choisissez un seul canal Proxmox. Si vous n’avez pas d’abonnement, désactivez pve-enterprise.list.

Tâche 5 : désactiver le mauvais dépôt (en toute sécurité, traçable)

cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ 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
Hit:4 http://download.proxmox.com/debian/ceph-quincy bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Ce que cela signifie : APT voit maintenant des dépôts cohérents. Vous avez retiré une source d’erreur prévisible.

Décision : Réessayez la mise à jour. Si le hook échoue toujours, passez à l’intégrité de dpkg.

Tâche 6 : confirmer que dpkg n’est pas à moitié cassé

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems configuring them the first time.
 pve-manager

Ce que cela signifie : Vous avez une configuration interrompue. Cela peut absolument causer des échecs de hook, car les paquets Proxmox s’appuient sur des scripts postinst.

Décision : Terminez la configuration avant de tenter d’autres mises à jour.

Tâche 7 : terminer la configuration de paquets en attente

cr0x@server:~$ dpkg --configure -a
Setting up pve-manager (8.2.2) ...
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 cela signifie : Vous avez maintenant la raison concrète : pveproxy ne démarre pas, donc la configuration de pve-manager échoue.

Décision : Arrêtez de poursuivre APT. Réparez la défaillance du service (souvent certificats, ports ou configuration).

Tâche 8 : inspecter l’unité systemd défaillante et les logs

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 Thu 2025-12-26 09:41:12 UTC; 15s ago
    Process: 18722 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
...
cr0x@server:~$ journalctl -xeu pveproxy.service --no-pager | tail -n 20
Dec 26 09:41:12 server pveproxy[18722]: can't open certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 26 09:41:12 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=255/EXCEPTION

Ce que cela signifie : Certificat SSL manquant dans /etc/pve. C’est du ressort du système de fichiers de cluster. Soit pmxcfs est mal en point, soit des fichiers ont été supprimés.

Décision : Validez la santé de pve-cluster/pmxcfs et régénérez les certificats si approprié.

Tâche 9 : vérifier le statut de pmxcfs (système de fichiers de cluster)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 09:39:01 UTC; 2min 34s ago
cr0x@server:~$ ls -l /etc/pve/local/ | head
total 8
-rw-r----- 1 root www-data  428 Dec 26 09:39 pve-ssl.key
-rw-r----- 1 root www-data  0 Dec 26 09:39 pve-ssl.pem

Ce que cela signifie : Le PEM existe mais fait zéro octet. Cela fera planter pveproxy.

Décision : Régénérez les certificats (idéalement de manière contrôlée, en connaissant les implications pour le cluster).

Tâche 10 : régénérer les certificats du nœud Proxmox

cr0x@server:~$ pvecm updatecerts --force
forcing certificate regeneration
writing new private key to '/etc/pve/local/pve-ssl.key'
writing new certificate to '/etc/pve/local/pve-ssl.pem'
Restarting pveproxy.service
Restarting pvedaemon.service

Ce que cela signifie : Le certificat manquant/vide est corrigé et les services ont redémarré. C’est souvent suffisant pour que pve-manager termine sa configuration.

Décision : Relancez dpkg --configure -a et retentez la mise à jour. Si vous êtes en cluster, comprenez la distribution des certificats et l’identité des nœuds.

Tâche 11 : vérifier la santé des services après correction

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

Ce que cela signifie : Le plan de contrôle est de retour. Les scripts postinst des paquets ont maintenant une chance de réussir.

Décision : Reprendre la configuration dpkg et les mises à jour.

Tâche 12 : identifier les paquets en hold (sabotateurs discrets)

cr0x@server:~$ apt-mark showhold
pve-kernel-6.2.16-20-pve

Ce que cela signifie : Un paquet de noyau est en hold. Parfois c’est intentionnel (tests de compatibilité matérielle). Parfois c’est du ruban adhésif oublié.

Décision : Si vous n’avez pas de raison écrite de le garder en hold, le sortir du hold. Si vous en avez, attendez-vous à ce que le hook se plaigne quand les méta-paquets ne pourront pas progresser.

Tâche 13 : lever le hold avec intention, puis prévisualiser les changements

cr0x@server:~$ apt-mark unhold pve-kernel-6.2.16-20-pve
Canceled hold on pve-kernel-6.2.16-20-pve.
cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,40p'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-kernel-6.5.13-5-pve pve-kernel-helper proxmox-ve
...

Ce que cela signifie : La simulation montre un chemin de mise à niveau noyau/méta normal. Pas de surprise du type suppression de la moitié du système.

Décision : Procédez quand la fenêtre de maintenance permet un redémarrage (les mises à jour de noyau importent).

Tâche 14 : vérifier l’espace libre des partitions d’amorçage avant d’installer des noyaux

cr0x@server:~$ df -h /boot /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       512M  486M   26M  95% /boot
/dev/sda1       512M  110M  402M  22% /boot/efi

Ce que cela signifie : /boot est presque plein. Les installations de noyau peuvent échouer en cours de route, conduisant à une corruption de dpkg et, pire, à une confusion du chargeur d’amorçage.

Décision : Nettoyez les anciens noyaux avant la mise à jour, mais faites-le prudemment pour garder au moins un noyau connu bon.

Tâche 15 : lister les noyaux installés et supprimer les anciens en toute sécurité

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/{print $2,$3}'
pve-kernel-6.2.16-20-pve 6.2.16-20
pve-kernel-6.2.16-22-pve 6.2.16-22
pve-kernel-6.5.13-5-pve 6.5.13-5
cr0x@server:~$ uname -r
6.2.16-22-pve
cr0x@server:~$ apt-get remove pve-kernel-6.2.16-20-pve
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  pve-kernel-6.2.16-20-pve
After this operation, 380 MB disk space will be freed.
Do you want to continue? [Y/n] y

Ce que cela signifie : Vous avez supprimé un noyau ancien qui n’était pas en cours d’exécution. Libérer de l’espace réduit le risque d’échec de mise à jour.

Décision : Gardez le noyau en cours d’exécution et un noyau de secours. Puis procédez à la mise à jour.

Tâche 16 : vérifier la politique des paquets et les priorités des dépôts (vérification du pinning)

cr0x@server:~$ apt-cache policy pve-manager proxmox-ve | sed -n '1,80p'
pve-manager:
  Installed: 8.2.2
  Candidate: 8.2.2
  Version table:
 *** 8.2.2 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status
proxmox-ve:
  Installed: 8.2-1
  Candidate: 8.2-1
  Version table:
 *** 8.2-1 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Ce que cela signifie : Les candidats proviennent du dépôt attendu. Si les candidats venaient d’origines inattendues, vous auriez des frictions de hook et des mises à jour étranges.

Décision : Procédez. Si les candidats semblent incorrects, corrigez d’abord les sources/pinning.

Tâche 17 : effectuer la mise à niveau réelle dans un environnement contrôlé

cr0x@server:~$ apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
...
Setting up proxmox-ve (8.2-1) ...
Processing triggers for pve-ha-manager (4.0.5) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve

Ce que cela signifie : Les scripts postinst et les triggers initramfs se sont exécutés avec succès — c’est là que beaucoup de systèmes cassés meurent.

Décision : Planifiez le redémarrage. Ne « redémarrez pas maintenant » puis n’oubliez pas pendant 90 jours.

Tâche 18 : confirmer que le hook ne bloque plus et vérifier les redémarrages en attente

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2-1 (running kernel: 6.2.16-22-pve)
pve-manager: 8.2.2 (running version: 8.2.2)
...
cr0x@server:~$ ls -l /var/run/reboot-required 2>/dev/null || echo "no reboot flag"
-rw-r--r-- 1 root root 0 Dec 26 10:12 /var/run/reboot-required

Ce que cela signifie : Vous avez mis à jour des paquets mais vous exécutez toujours un ancien noyau. Le flag de redémarrage est votre rappel que la réalité n’a pas encore rattrapé l’opération.

Décision : Redémarrez pendant la fenêtre, puis validez le nouveau noyau et la santé du stockage.

Trois mini-récits d’entreprise depuis le terrain

Incident n°1 (mauvaise hypothèse) : « C’est Debian, donc ça se comportera comme Debian. »

Une équipe gérait un petit cluster Proxmox hébergeant des charges « internes ». La logique métier était classique : si c’est interne, ce n’est pas critique ; si ce n’est pas critique, on improvise. Ils avaient un playbook Debian standard pour les mises à jour et ont décidé que Proxmox pouvait suivre le même processus.

La mauvaise hypothèse est apparue dans la configuration des dépôts. Quelqu’un a activé le dépôt enterprise parce que cela paraissait « plus stable », mais il n’y avait pas d’abonnement. apt update a commencé à renvoyer des erreurs d’authentification. Ils ont vu les erreurs, haussé les épaules, et ont lancé apt dist-upgrade quand même. Le hook l’a bloqué. Ils l’ont pris personnellement.

Pour « réparer », ils ont commenté le hook dans la configuration APT (pas recommandé, et oui, c’était aussi moche que ça en a l’air). La mise à jour a avancé, mais elle a récupéré un ensemble de paquets Debian qui n’étaient pas alignés avec l’ensemble Proxmox prévu. Pas de crash immédiat — juste une dérive silencieuse.

Un mois plus tard, ils ont redémarré le nœud pour une maintenance matérielle non liée. Le boot s’est lancé sur un noyau qui n’avait pas l’alignement attendu du module ZFS. Import échoué. Ils n’avaient pas de noyau de secours propre car les anciens noyaux avaient été autoremovés lors du « correctif » précédent. La panne n’était pas spectaculaire ; elle était pire — lente, confuse, et remplie de symptômes contradictoires.

Le postmortem a tranché : le hook avait raison. Il ne cherchait pas à leur gâcher la journée. Il cherchait à les empêcher de mettre à jour sur une base de dépôts incohérente. Ils ont revu leur processus : politique de dépôts explicite par environnement, vérifications d’origine des paquets, et règle stricte que si Proxmox bloque une mise à jour, on la traite comme un diagnostic, pas comme un obstacle.

Incident n°2 (optimisation qui se retourne contre vous) : « Accélérons les mises à jour en nettoyant agressivement. »

Une autre organisation avait des fenêtres de maintenance strictes. Leur optimisation était simple : accélérer les mises à jour en réduisant le bloat disque. Un ingénieur bien intentionné a ajouté un cron pour purger les anciens noyaux et nettoyer les caches de paquets plus agressivement que les valeurs par défaut.

Ça a marché — jusqu’au jour où ça n’a plus marché. Un nœud avait une partition /boot légèrement plus petite (image legacy, jamais standardisée). Les paquets de noyau se sont accumulés avec le temps. Le cron a supprimé les anciens noyaux, mais sans la moindre conscience de « garder un noyau de secours ». Il a également tourné proche de l’heure de mise à jour.

Pendant une mise à jour de routine, initramfs-tools a essayé de générer un nouvel initrd et a manqué d’espace en cours d’écriture. C’est le type particulier d’échec qui laisse dpkg à moitié configuré et vos artefacts de boot incohérents. Les hooks APT ont alors commencé à bloquer les mises à jour supplémentaires parce que l’état du packaging était cassé.

Ils l’ont débloqué en nettoyant plus (bien sûr), ce qui a supprimé le dernier noyau connu bon. Le nœud a redémarré dans un état où l’hyperviseur était opérationnel mais le réseau instable à cause d’incompatibilités de pilotes. Les VMs ont migré lentement, et la réparation a exigé une intervention sur site et un démarrage de secours.

La leçon n’était pas « ne nettoyez pas ». La leçon était « ne nettoyez pas aveuglément ». L’hygiène disque est bonne, mais le cycle de vie des noyaux sur un hyperviseur doit être intentionnel : conservez un secours, confirmez l’espace de boot, et traitez la génération d’initramfs comme un chemin critique, pas une tâche facultative.

Incident n°3 (pratique ennuyeuse mais correcte) : staging, simulation, et un noyau de secours ont sauvé la situation

Une troisième équipe gérait un cluster à charges mixtes : bases de données stateful, web stateless, quelques appliances étranges, et quelques hôtes GPU que personne n’osait toucher. Leur processus était sans glamour : chaque mise à jour commençait par apt-get -s dist-upgrade, puis vérification de l’origine des paquets, puis un snapshot de l’état de configuration.

Ils avaient aussi une habitude qui paraissait paranoïaque mais qui était en réalité compétente : ils s’assuraient toujours que le noyau en cours restait installé et qu’il y avait au moins un noyau plus récent installé avant le redémarrage. Pas d’exception, même si cela coûtait quelques centaines de mégaoctets.

Un jour, une mise à jour a introduit une régression pour un pilote NIC spécifique sur leur matériel. Le nœud a redémarré avec un réseau dégradé — toujours joignable, mais pas suffisamment stable pour la production. Parce qu’ils avaient conservé le noyau précédent, ils ont choisi l’ancien noyau dans le menu de boot (console distante via IPMI). Le nœud est revenu à un comportement stable.

Ils ont épinglé le noyau problématique pour ces hôtes uniquement, documenté la raison, et attendu le correctif suivant. Le hook n’a jamais été l’ennemi, parce que l’équipe ne traitait pas les mises à jour comme une roulette. La réparation était ennuyeuse, et l’ennuyeux est sous-estimé.

Blague #2 : La seule chose pire qu’une mise à jour échouée, c’est une mise à jour « réussie » qui échoue au prochain redémarrage.

Erreurs fréquentes : symptômes → cause → correctif

1) Symptom : « pve-apt-hook failed » juste après l’activation d’un dépôt

Cause : Dépôt enterprise activé sans abonnement, ou enterprise et no-subscription activés simultanément.

Correctif : Activez exactement un canal Proxmox. Commentez /etc/apt/sources.list.d/pve-enterprise.list si vous n’avez pas accès ; conservez pve-no-subscription si c’est votre politique. Exécutez apt update jusqu’à ce que ce soit propre.

2) Symptom : la mise à jour échoue, dpkg se plaint de « post-installation script returned error »

Cause : Un service Proxmox (souvent pveproxy, pvedaemon, pve-cluster) ne peut pas démarrer à cause d’un problème de config/certificat.

Correctif : Arrêtez de lancer apt en boucle. Inspectez systemctl status et journalctl, réparez le service, puis exécutez dpkg --configure -a.

3) Symptom : « pas assez d’espace libre dans /boot » pendant la mise à jour, suivi par des échecs de hook

Cause : L’installation d’un noyau a échoué en cours de route, laissant dpkg dans un état cassé ; les exécutions suivantes rencontrent hooks et erreurs de packaging.

Correctif : Libérez de l’espace dans /boot en supprimant d’anciens noyaux qui ne sont pas en cours d’exécution. Ensuite exécutez apt -f install et dpkg --configure -a pour réparer.

4) Symptom : le hook échoue après une tentative de « mise à niveau de release Debian »

Cause : Incompatibilité de suite Debian avec les attentes de la version Proxmox ; vous avez peut-être mélangé bullseye/bookworm ou similaire dans les sources.

Correctif : Alignez les sources Debian sur la suite supportée pour votre majeur Proxmox. Si vous effectuez une mise à niveau majeure de Proxmox, suivez une séquence de montée de version majeure, pas un simple apt dist-upgrade.

5) Symptom : la mise à jour veut supprimer proxmox-ve ou installer des noyaux Debian aléatoires

Cause : Conflits de méta-paquets, mauvaises priorités de dépôts, ou suppression accidentelle de méta-paquets Proxmox.

Correctif : Inspectez apt-cache policy proxmox-ve et assurez-vous que les candidats proviennent des dépôts Proxmox. Réinstallez le méta-paquet proxmox-ve si nécessaire, et supprimez les méta-paquets noyau Debian accidentels s’ils prennent le dessus.

6) Symptom : sur systèmes boot ZFS, les noyaux s’installent mais le nœud ne boot pas le nouveau noyau

Cause : Problèmes de synchronisation du chargeur d’amorçage sur des ESPs miroir ou proxmox-boot-tool non mis à jour après des changements de disques.

Correctif : Validez proxmox-boot-tool status et ré-initialisez/synchronisez si nécessaire avant de faire confiance aux mises à jour de noyau.

7) Symptom : les nœuds du cluster montrent des candidats de paquets différents et les hooks échouent seulement sur un nœud

Cause : Sources spécifiques au nœud, pinning résiduel, ou différence d’un proxy apt local.

Correctif : Comparez /etc/apt et confirmez que les définitions de dépôts correspondent à la politique du cluster. Standardisez les pins et nettoyez les listes obsolètes.

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

Quand vous voyez « pve-apt-hook failed » (nœud unique)

1. Stoppez. Ne relancez pas la même commande cinq fois. Vous ne forcez pas un hook.
2. Exécutez apt update et rendez-le propre (pas d’erreurs d’auth, pas de fichiers Release manquants).
3. Auditez les dépôts Proxmox : exactement un des dépôts enterprise/no-subscription activé.
4. Exécutez dpkg --audit. Si quelque chose est à moitié configuré, réparez cela en priorité.
5. Exécutez dpkg --configure -a et traitez les échecs en réparant le service ou le fichier qui cause l’erreur postinst.
6. Vérifiez apt-mark showhold pour des holds qui bloquent des méta-paquets.
7. Vérifiez l’espace disque dans /boot et /var.
8. Simulez la mise à jour (apt-get -s dist-upgrade) et assurez-vous qu’elle ne supprime pas proxmox-ve.
9. Procédez à la mise à jour réelle.
10. Redémarrez dans la fenêtre. Confirmez que uname -r correspond au nouveau noyau.

Posture sûre pour upgrade en cluster (quoi faire avant de toucher aux paquets)

1. Confirmez la santé du quorum et de corosync. Une mise à jour de cluster quand le quorum est instable est un pari.
2. Choisissez un ordre : nœuds non critiques d’abord, puis nœuds critiques, puis nœuds « matériel spécial » (GPU, HBA passthrough).
3. Migrer ou arrêter les VMs sur le nœud que vous mettez à jour. Si vous ne pouvez pas, vous n’êtes pas en fenêtre de maintenance ; vous êtes en mode espoir.
4. Snapshot des configs : sauvegardez /etc et l’état de /etc/pve (au moins des tarballs). Sur les clusters, traitez /etc/pve avec précaution.
5. Assurez-vous qu’au moins une entrée de démarrage de secours (ancien noyau) reste installée.

Ce qu’il faut éviter (parce que ça « marche » jusqu’à ce que ça vous ruine)

• Ne supprimez pas ou ne contournez pas les hooks APT Proxmox comme première réponse.
• Ne mélangez pas les canaux de dépôts « temporairement ». Les changements temporaires ont une longue demi-vie.
• Ne mettez pas à jour les noyaux quand /boot est plein. C’est ainsi que vous créez la corruption dpkg sur mesure.
• Ne faites pas de montées de version majeures en « dist-upgrade » improvisé. Les upgrades majeures méritent un plan et une stratégie de rollback.

Faits intéressants et contexte historique

• Fait 1 : Le modèle de packaging de Proxmox VE utilise délibérément des méta-paquets (comme proxmox-ve) pour garder un ensemble cohérent de noyau et composants userland alignés.
• Fait 2 : Les hooks APT existent depuis des années comme moyen d’étendre le comportement des paquets sans forker APT lui-même ; Proxmox utilise ce mécanisme pour faire respecter des invariants système.
• Fait 3 : Proxmox VE est construit sur Debian stable, qui privilégie la stabilité plutôt que la nouveauté — Proxmox superpose ensuite sélectivement des noyaux plus récents et des composants de virtualisation.
• Fait 4 : La séparation entre les dépôts enterprise et no-subscription n’est pas qu’un théâtre de licences ; elle concerne aussi le rythme des mises à jour et les attentes de support.
• Fait 5 : Beaucoup de nœuds Proxmox démarrent depuis ZFS (y compris des setups ESPs miroir), ce qui complique la gestion noyau/bootloader comparé à une racine ext4 unique.
• Fait 6 : /etc/pve n’est pas un répertoire normal dans les configurations en cluster ; c’est un système de fichiers de cluster, et des fichiers manquants là-bas peuvent signaler des problèmes d’état du cluster plus profonds.
• Fait 7 : L’accumulation de paquets noyau est un problème récurrent en exploitation car les noyaux et les images initramfs sont volumineux, et les partitions /boot sont souvent sous-dimensionnées par des valeurs héritées.
• Fait 8 : Proxmox a historiquement supporté plusieurs backends de stockage (LVM, ZFS, Ceph), et la sécurité des mises à jour doit tenir compte des modes de défaillance propres à chacun.

FAQ

Q1 : « pve-apt-hook failed » est-ce un bug APT ou un bug Proxmox ?

Généralement ni l’un ni l’autre. C’est Proxmox qui retourne volontairement un code non nul depuis un hook APT parce qu’il a détecté un état risqué ou incohérent. Traitez-le comme un signal de violation de politique.

Q2 : Puis-je simplement désactiver le hook pour forcer la mise à jour ?

Vous pouvez, mais vous ne devriez pas — sauf en cas d’urgence contrôlée où vous avez un accès console et un plan de rollback. Si vous le contournez à la légère, vous vous inscrivez à des échecs d’amorçage, de la dérive des dépôts, et des surprises « pourquoi l’interface est cassée ».

Q3 : J’ai activé pve-enterprise et maintenant les mises à jour échouent. Quelle est la bonne correction ?

Si vous avez un abonnement, conservez-le et assurez-vous que les identifiants/l’accès sont corrects. Si vous n’en avez pas, commentez le dépôt enterprise et activez pve-no-subscription. Ensuite exécutez apt update jusqu’à ce que ce soit propre.

Q4 : Pourquoi Proxmox accorde-t-il tant d’importance à la cohérence des dépôts ?

Parce que les hyperviseurs sont de l’infrastructure. Les dépôts mixtes peuvent produire un système qui « fonctionne » jusqu’au prochain redémarrage, prochain noyau, ou prochaine relance d’un service. Proxmox préfère échouer tôt pendant que vous avez encore un nœud fonctionnel.

Q5 : Le hook échoue mais apt update est propre. Et ensuite ?

Vérifiez l’état de dpkg (dpkg --audit), terminez la configuration (dpkg --configure -a), vérifiez les paquets en hold, et confirmez que /boot n’est pas plein. Les échecs de hook suivent souvent une corruption dpkg.

Q6 : Dois-je redémarrer après les mises à jour ?

Si un noyau ou des bibliothèques bas-niveau ont été mises à jour, oui. Vous pouvez vérifier avec /var/run/reboot-required et en comparant uname -r aux noyaux installés. Redémarrer plus tard est acceptable ; oublier indéfiniment ne l’est pas.

Q7 : Comment savoir si une mise à jour tente de supprimer quelque chose de critique ?

Simulez-la : apt-get -s dist-upgrade. Si elle veut supprimer proxmox-ve ou installer un méta-paquet noyau Debian générique au lieu des noyaux Proxmox, arrêtez-vous et corrigez vos sources/pinning.

Q8 : Cette erreur affecte-t-elle Ceph ou ZFS différemment ?

Le hook lui-même est général, mais les conséquences diffèrent. Sur root ZFS, l’alignement noyau/module compte. Avec Ceph, la compatibilité des bibliothèques clientes peut être critique. Dans tous les cas, gardez les mises à jour cohérentes et suivez une discipline de redémarrage et de validation.

Q9 : Pourquoi réparer pveproxy est-il important pour les mises à jour de paquets ?

Parce que les paquets Proxmox exécutent souvent des scripts post-installation qui s’attendent à ce que des services centraux démarrent ou que des configurations soient validées. Si le postinst échoue, dpkg reste cassé, et le hook continuera probablement à bloquer les opérations « normales » jusqu’à ce que vous répariez.

Prochaines étapes qui ne vous mordront pas plus tard

Quand Proxmox lance pve-apt-hook failed, ce n’est pas pour faire du cinéma. Il fait respecter des invariants : cohérence des dépôts, état cohérent du packaging, et résultats de noyau/boot plus sûrs. Votre tâche est de trouver quel invariant vous avez violé — puis de corriger cela, pas le messager.

Étapes pratiques :

1. Rendez apt update propre et assurez-vous qu’un seul canal Proxmox prévu est activé.
2. Réparez l’état de dpkg (dpkg --audit, dpkg --configure -a) et corrigez les services défaillants au lieu de relancer les mises à jour.
3. Vérifiez l’espace /boot et supprimez les anciens noyaux avec précaution (gardez un secours).
4. Simulez les mises à jour avant de les exécuter, et ne balayez pas sous le tapis les redémarrages planifiés.
5. Pour les clusters : confirmez le quorum, mettez à jour dans l’ordre, et traitez chaque nœud comme un système de production — parce que c’en est un.