Résoudre les échecs d’apt update sur Proxmox : DNS, dépôts et clés GPG (pas à pas)

janvier 26, 2026 • février 3, 2026 • Lecture : 30 min • Views: 9

Cet article vous a aidé ?

Quand apt update plante sur un nœud Proxmox, ce n’est rarement « juste apt ». C’est votre DNS. Ou votre choix de dépôt. Ou un proxy qui réécrit silencieusement le TLS. Ou une clé qui a expiré à 02:00 un dimanche, comme si quelqu’un détestait dormir.

Ce guide est destiné aux personnes qui gèrent des clusters en production et n’ont pas le temps d’admirer les messages d’erreur. Vous diagnostiquerez rapidement, ferez des changements propres et laisserez le nœud plus prévisible qu’à votre arrivée.

Playbook de diagnostic rapide

Si vous voulez un ensemble de vérifications qui trouve rapidement le goulot d’étranglement, faites ceci dans l’ordre. Arrêtez dès que vous trouvez la première couche défaillante. Empiler des corrections sans comprendre, c’est ce qui vous donne « ça marche sur ce nœud mais pas sur l’autre » pour l’année suivante.

1) Accessibilité réseau (y a-t-il un chemin du tout ?)

Vérifiez l’adresse IP, la route par défaut et l’état du lien.
Pinguez votre passerelle et une IP publique connue.
Si vous ne pouvez pas atteindre d’IP, ne touchez pas encore à apt, aux dépôts ou aux clés.

2) Résolution DNS (le nœud connaît-il les noms ?)

Résolvez les noms d’hôtes des dépôts via getent et resolvectl.
Recherchez un DNS fractionné, des stub resolvers, ou un résolveur pointant vers 127.0.0.1 sans rien à l’écoute.

3) Exactitude des dépôts (demandez-vous au bon serveur pour la bonne distro ?)

Vérifiez que le nom de code Debian correspond à votre version Proxmox.
Assurez-vous de ne pas utiliser par erreur le dépôt enterprise sans abonnement.
Vérifiez que vous n’avez pas copié une ligne de dépôt Ubuntu dans Debian. Oui, des gens font ça.

4) TLS / certificats / comportement du proxy (êtes-vous autorisé à récupérer ?)

Vérifiez la présence d’un proxy MITM d’entreprise, d’un portail captif ou d’erreurs TLS.
Confirmez que l’heure système est saine (une mauvaise heure fait paraître le TLS « cassé »).

5) Clés de signature GPG (apt peut-il vérifier ce qu’il a téléchargé ?)

Recherchez NO_PUBKEY ou « signé par une clé inconnue ».
Utilisez des keyrings par dépôt, pas l’ancienne approche « asperger des clés dans apt-key ».

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « You build it, you run it. » Ça signifie que vous le déboguez aussi à des moments inopportuns.

Faits intéressants et contexte (pour les curieux et les marqués)

La vérification des signatures APT est devenue moins optionnelle avec le temps. Les workflows de l’ère Debian utilisaient apt-key ; les recommandations modernes poussent vers des keyrings par dépôt pour la confinement.
Proxmox est basé sur Debian, pas « Debian-ish ». Les confusions de dépôts arrivent parce que des gens le traitent comme un appliance générique, puis s’étonnent que la résolution de dépendances fonde.
Proxmox sépare les dépôts selon le modèle de support. Le dépôt enterprise est protégé ; le dépôt no-subscription est ouvert mais n’offre pas la même promesse de stabilité.
Les échecs DNS sont le problème d’apt le plus courant dans les datacenters. Parce que le DNS est une des rares choses que tout le monde présume « doit être OK ».
L’heure système est une dépendance cachée de la gestion des paquets. TLS, fenêtres de validité des clés et certains proxies dépendent d’horloges cohérentes.
L’IPv6 peut être à la fois héros et vilain. Si un nœud préfère l’IPv6 mais que votre réseau ne le supporte qu’à moitié, vous aurez des blocages lents et des échecs intermittents.
Les 401/403 des dépôts Proxmox sont généralement des règles, pas une panne transitoire. Cela signifie souvent « mauvais dépôt pour votre état d’abonnement ».
Les fichiers Release et les noms de suite comptent. Une seule mauvaise appellation (comme bullseye vs bookworm) peut apparaître comme « Release file changed », « does not have a Release file » ou des conflits de dépendances.

Ce que signifie réellement « apt update failed » sur Proxmox

apt update est une chaîne :

Résoudre les noms (DNS, /etc/hosts, systemd-resolved, résolveurs locaux en cache).
Se connecter aux serveurs (routage, firewall, règles de proxy).
Négocier le TLS (chaîne de certificats, heure système, interception par proxy).
Télécharger les métadonnées (fichiers Release/InRelease).
Vérifier les signatures (clés GPG et configuration de confiance).
Analyser les métadonnées du dépôt et construire l’index des paquets.

Votre message d’erreur vous dit quelle étape a échoué, mais seulement si vous savez le lire. « Temporary failure resolving » signifie DNS ; « The following signatures couldn’t be verified » signifie clés ; « 401 Unauthorized » signifie que vous toquez à la porte enterprise sans badge.

Blague n°1 : Le DNS, c’est comme l’oxygène — personne ne s’en soucie jusqu’à ce qu’il disparaisse, et tout le monde devient soudain spécialiste respiratoire.

Tâches pratiques : commandes, sorties et décisions (le cœur)

Ci-dessous se trouvent des tâches pratiques que vous pouvez lancer sur le nœud Proxmox. Chaque tâche inclut une commande, une sortie réaliste, ce que cela signifie et quelle décision prendre ensuite. Faites-les dans l’ordre sauf si vous savez déjà quelle couche échoue.

Task 1: Confirm Proxmox and Debian version alignment

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-2-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2a1b3c0c)
pve-kernel-6.8: 6.8.12-2
pve-kernel-helper: 8.1.0
pve-kernel-libc-dev: 6.8.12-2
pve-qemu-kvm: 8.1.5
pve-container: 5.0.1
ceph-fuse: 16.2.15-pve1
corosync: 3.1.8-pve1
cr0x@server:~$ . /etc/os-release && echo "$PRETTY_NAME"
Debian GNU/Linux 12 (bookworm)

Ce que cela signifie : PVE 8 suit Debian 12 (bookworm). C’est votre hypothèse de base pour les suites des dépôts.

Décision : Si votre release OS est Debian 11 mais que vous essayez d’utiliser les dépôts PVE 8 (ou l’inverse), arrêtez et corrigez le décalage avant de toucher aux clés.

Task 2: Capture the exact apt failure without “fixing” anything

cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Err:2 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 [IP: 51.91.38.34 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.

Ce que cela signifie : Le réseau et le DNS vont bien. Vous avez atteint le dépôt enterprise, mais vous n’êtes pas autorisé. La ligne « not signed » est un effet secondaire du fait de ne pas avoir pu récupérer le fichier Release signé, pas nécessairement un problème de clé.

Décision : Corrigez la sélection du dépôt (enterprise vs no-subscription) avant de courir après les clés GPG.

Task 3: Check basic interface and routing

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
vmbr0            UP             10.20.30.41/24 fe80::a00:27ff:fe4e:1122/64
cr0x@server:~$ ip route
default via 10.20.30.1 dev vmbr0
10.20.30.0/24 dev vmbr0 proto kernel scope link src 10.20.30.41

Ce que cela signifie : Le lien est up, la route par défaut existe et vous n’êtes pas dans une situation bizarre « sans passerelle ».

Décision : Si la route par défaut manque ou pointe vers la mauvaise interface (fréquent après un renommage de bridge), corrigez le réseau d’abord. Apt ne peut pas contourner la physique.

Task 4: Prove you can reach the internet by IP (DNS-independent)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=1.78 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=1.72 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.721/1.750/1.780/0.029 ms

Ce que cela signifie : Le routage vers l’extérieur fonctionne.

Décision : Si cela échoue, regardez les règles firewall, le routage amont ou le tagging VLAN. Ne modifiez pas les sources apt tant que la connectivité de base n’est pas corrigée.

Task 5: Test DNS resolution the way apt actually uses it

cr0x@server:~$ getent ahosts deb.debian.org | head
2a04:4e42:83::644 deb.debian.org
2a04:4e42:83::644 STREAM deb.debian.org
2a04:4e42:83::644 DGRAM  deb.debian.org
2a04:4e42:83::644 RAW    deb.debian.org
146.75.106.132 deb.debian.org
146.75.106.132 STREAM deb.debian.org

Ce que cela signifie : La résolution de noms fonctionne. Vous obtenez des réponses IPv6 et IPv4.

Décision : Si getent échoue mais que dig réussit, vous avez un problème NSS/systemd-resolved. Corrigez la pile de résolveurs, pas la liste des dépôts.

Task 6: Inspect resolver configuration (systemd-resolved vs /etc/resolv.conf)

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11
Fallback DNS Servers: 1.1.1.1 8.8.8.8

Ce que cela signifie : Vous utilisez systemd-resolved, pointé vers des serveurs DNS internes, avec des fallback configurés.

Décision : Si votre « Current DNS Server » est vide, ou pointe vers quelque chose injoignable, corrigez la configuration réseau (souvent dans /etc/network/interfaces pour Proxmox) ou vos paramètres DHCP/DNS statiques.

Task 7: Identify IPv6-related hangs and failures

cr0x@server:~$ apt-get -o Acquire::ForceIPv4=true update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian-security bookworm-security InRelease
Err:3 https://download.proxmox.com/debian/pve bookworm InRelease
  Temporary failure resolving 'download.proxmox.com'
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Temporary failure resolving 'download.proxmox.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

Ce que cela signifie : Forcer IPv4 a changé le comportement. Si forcer IPv4 fait que ça marche (ou échoue plus vite), votre chemin IPv6 ou votre résolveur IPv6 est peut-être instable.

Décision : Si l’IPv6 casse apt, soit corrigez l’IPv6 correctement (préférable), soit forcez temporairement IPv4 pour apt en attendant une correction réseau.

Task 8: Spot proxy settings that change apt behavior

cr0x@server:~$ grep -R "Acquire::http::Proxy\|Acquire::https::Proxy" -n /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/99proxy:1:Acquire::http::Proxy "http://proxy.corp.local:3128";
/etc/apt/apt.conf.d/99proxy:2:Acquire::https::Proxy "http://proxy.corp.local:3128";

Ce que cela signifie : Apt utilise explicitement un proxy pour HTTP et HTTPS. Si ce proxy intercepte le TLS ou nécessite une auth, vos erreurs ressembleront à des échecs TLS ou dépôt.

Décision : Confirmez la joignabilité du proxy et s’il supporte CONNECT pour HTTPS. Si c’est un hôte Proxmox, réfléchissez à l’usage du proxy — les proxies qui réécrivent le contenu sont un cadeau qui continue de donner des problèmes.

Task 9: Validate system time (TLS and key validity depend on it)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 10:14:11 UTC
           Universal time: Thu 2025-12-26 10:14:11 UTC
                 RTC time: Thu 2025-12-26 10:14:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée. Bien — le TLS ne faillira pas parce que votre nœud croit qu’il est en 1970 ou 2038.

Décision : Si la synchronisation est no, corrigez NTP d’abord. Une horloge erronée crée des leurres « certificat non encore valide » et « clé expirée ».

Task 10: Inspect apt sources for Proxmox and Debian

cr0x@server:~$ grep -R --line-number --no-messages '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-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Ce que cela signifie : Le nœud est configuré pour utiliser le dépôt enterprise. Si vous n’avez pas d’abonnement, vous aurez des erreurs 401. Si vous en avez un mais que vous avez toujours 401, vérifiez l’installation de la clé d’abonnement et l’authentification proxy sortante.

Décision : Décidez quel dépôt Proxmox vous voulez. Pour des labs et de nombreuses petites structures : no-subscription. Pour des environnements régulés : enterprise, avec support réel.

Task 11: Switch from enterprise repo to no-subscription repo (when appropriate)

cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Get:4 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Get:5 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages [312 kB]
Fetched 315 kB in 1s (451 kB/s)
Reading package lists... Done

Ce que cela signifie : Vous utilisez maintenant le dépôt adapté pour un environnement sans abonnement enterprise, et apt peut récupérer les métadonnées.

Décision : Si cela fonctionne, vous avez résolu le problème d’autorisation du dépôt. Passez ensuite à l’hygiène des clés et à la prévention des régressions.

Task 12: Diagnose “NO_PUBKEY” and signature errors cleanly

cr0x@server:~$ apt-get update
Get:1 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Err:1 http://download.proxmox.com/debian/pve bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
Reading package lists... Done
W: GPG error: http://download.proxmox.com/debian/pve bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
E: The repository 'http://download.proxmox.com/debian/pve bookworm InRelease' is not signed.

Ce que cela signifie : Le dépôt est joignable, mais apt refuse de lui faire confiance parce que la clé de signature n’est pas disponible dans vos keyrings configurés.

Décision : Installez la clé d’archive Proxmox dans un keyring dédié et référez-vous à elle avec signed-by. N’utilisez pas apt-key add sauf si vous aimez la confiance globale et que votre futur vous en voudra.

Task 13: Install the Proxmox repo key the modern way (dedicated keyring)

cr0x@server:~$ install -d -m 0755 /etc/apt/keyrings
cr0x@server:~$ wget -qO /etc/apt/keyrings/proxmox-archive-keyring.gpg /usr/share/keyrings/proxmox-archive-keyring.gpg && echo "ok"
ok
cr0x@server:~$ chmod 0644 /etc/apt/keyrings/proxmox-archive-keyring.gpg
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Hit:4 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done

Ce que cela signifie : Apt fait désormais confiance au dépôt Proxmox en utilisant une clé explicite scellée au dépôt.

Décision : Conservez les clés ciblées. Si la clé d’un dépôt est compromise, vous voulez un rayon d’impact limité, pas un feu d’artifice.

Task 14: Debug “Release file changed” and suite mismatch

cr0x@server:~$ apt-get update
Err:1 http://deb.debian.org/debian stable InRelease
  404  Not Found [IP: 151.101.130.132 80]
Reading package lists... Done
E: The repository 'http://deb.debian.org/debian stable InRelease' does not have a Release file.

Ce que cela signifie : Vos sources sont incorrectes. « stable » peut marcher dans certains contextes, mais sur des nœuds d’infrastructure vous voulez le nom de code explicite pour éviter les surprises lors d’une transition Debian stable.

Décision : Remplacez stable par le nom de code correct (par ex. bookworm) dans toutes les lignes concernées. La cohérence compte plus que l’astuce.

Task 15: Detect TLS interception/certificate chain issues

cr0x@server:~$ apt-get update
Err:1 https://download.proxmox.com/debian/pve bookworm InRelease
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 144.217.225.162 443]
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification.
W: Some index files failed to download. They have been ignored, or old ones used instead.

Ce que cela signifie : Soit votre bundle CA est cassé/obsolète, soit votre heure est fausse, soit un proxy d’entreprise intercepte le TLS et présente une CA personnalisée non approuvée par le nœud.

Décision : Ne désactivez pas la vérification des certificats. Corrigez la confiance des CA correctement (installez la CA racine d’entreprise dans le magasin de confiance système si vous devez utiliser l’interception), ou contournez le proxy pour les domaines de dépôt.

Task 16: Confirm CA certificates package and update it

cr0x@server:~$ dpkg -l ca-certificates | awk 'NR==1 || $1 ~ /^ii/ {print}'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version         Architecture Description
ii  ca-certificates 20230311        all          Common CA certificates
cr0x@server:~$ update-ca-certificates | tail -n 5
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Ce que cela signifie : Le paquet CA est présent et le magasin de certificats a été mis à jour. Si le TLS échoue encore, suspectez l’interception ou un chemin proxy cassé.

Décision : Si vous êtes dans un réseau d’entreprise avec interception TLS, installez la CA d’entreprise (proprement) ou configurez apt pour aller en direct.

Task 17: Check for repo pinning and holds that make updates “look broken”

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8.12-2-pve
cr0x@server:~$ apt-cache policy pve-kernel-6.8.12-2-pve | sed -n '1,25p'
pve-kernel-6.8.12-2-pve:
  Installed: 6.8.12-2
  Candidate: 6.8.12-2
  Version table:
 *** 6.8.12-2 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Ce que cela signifie : Les mises en attente n’empêchent pas apt update, mais elles peuvent causer de la confusion « pourquoi ça ne veut pas upgrader ? » après avoir corrigé update.

Décision : Retirez les holds seulement si vous savez pourquoi ils existent. Les holds de noyau peuvent être intentionnels (pilotes de stockage, modules hors-arbre, ou fenêtres de changement conservatrices).

Task 18: Ensure apt can write its lists (disk space and permissions)

cr0x@server:~$ df -h /var
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/pve-root                94G   92G     0 100% /
cr0x@server:~$ apt-get update
E: Write error - write (28: No space left on device)
E: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Write error - write (28: No space left on device)
E: Some index files failed to download. They have been ignored, or old ones used instead.

Ce que cela signifie : Votre système de fichiers racine est plein. Apt ne peut pas mettre à jour ses listes, et même si c’était possible, vous ne pourrez probablement rien installer de toute façon.

Décision : Libérez d’abord de l’espace (logs, anciens noyaux, ISOs déplacés hors du root). Ensuite relancez apt.

Task 19: See what apt thinks it should fetch (debug acquisition)

cr0x@server:~$ apt-get -o Debug::Acquire::https=true update 2>&1 | sed -n '1,30p'
Acquire::https::download.proxmox.com:443: Server supports multiplexing
Acquire::https::download.proxmox.com:443: Negotiating SSL
Acquire::https::download.proxmox.com:443: Verify-Peer: 1
Acquire::https::download.proxmox.com:443: Cipher: TLS_AES_256_GCM_SHA384
Get:1 https://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Fetched 2,768 B in 0s (14.2 kB/s)
Reading package lists... Done

Ce que cela signifie : Utile quand le comportement proxy/TLS est étrange. Vous pouvez voir la négociation et les décisions de vérification.

Décision : Si vous voyez des reconnexions répétées, des problèmes SNI, ou une vérification inversée, vous êtes probablement face à un proxy interceptant ou une chaîne CA cassée.

Task 20: Validate that Proxmox repo stanzas aren’t duplicated or conflicting

cr0x@server:~$ awk 'NF && $1 != "#" {print FILENAME ":" NR ":" $0}' /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 [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Ce que cela signifie : Un jeu clair de lignes Debian, un jeu clair de lignes Proxmox. Pas de duplicata, pas de dépôt enterprise obsolète encore actif.

Décision : Si vous voyez plusieurs lignes Proxmox pour différentes suites ou à la fois enterprise et no-subscription activés, nettoyez. Apt ne « choisira pas la bonne ». Il choisira le chaos.

Blague n°2 : Les erreurs APT sont comme les e-mails d’entreprise — techniquement informatives, émotionnellement inutiles, et arrivent toujours quand vous êtes déjà occupé.

Listes de contrôle / plan pas à pas

Voici la séquence pratique que j’utilise en production. Elle évite de « corriger la mauvaise chose » et laisse des traces pour le prochain opérateur.

Checklist A: Fix DNS-related apt failures

Confirmez le routage (Task 3–4). Si la connectivité IP est cassée, arrêtez ici.
Confirmez la résolution de noms via NSS (Task 5). Si getent échoue, ne faites pas confiance à dig comme preuve qu’apt fonctionnera.
Inspectez l’état de systemd-resolved (Task 6). Confirmez que les serveurs DNS actuels sont joignables.
Vérifiez si le DNS est seulement cassé pour les domaines externes (fréquent avec le DNS fractionné). Testez des noms internes et externes.
Décidez d’une stratégie de résolveur :
- Préféré : corriger les serveurs DNS en amont et la configuration DHCP/static.
- Acceptable à court terme : définir des résolveurs explicites dans votre config réseau pour que les nœuds Proxmox ne dépendent pas d’un scope DHCP poste de travail.
Relancez apt update et confirmez que la classe d’erreur a changé. Aucun changement signifie que vous avez corrigé la mauvaise couche.

Checklist B: Fix repository and suite problems

Identifiez la version Proxmox et le nom de code Debian (Task 1).
Imprimez toutes les lignes de dépôt (Task 10, Task 20). Cherchez :
- Mauvais nom de code (bullseye sur Debian 12).
- Utiliser stable au lieu du nom de code explicite (Task 14).
- Dépôt enterprise activé sans abonnement (Task 2).
- Protocoles mixtes et entrées dupliquées.
Prenez une décision unique sur le dépôt :
- Dépôt enterprise si vous avez un abonnement et voulez le flux de mises à jour curaté.
- Dépôt no-subscription si vous n’en avez pas. Soyez honnête et configurez en conséquence.
Désactivez le dépôt que vous n’utilisez pas (commentez-le, ne le supprimez pas ; vous voulez une auditabilité).
Exécutez apt update de nouveau et vérifiez que les fetchs de dépôts sont Hit/Get, pas Err.

Checklist C: Fix keys and signature verification the right way

Confirmez que l’échec porte réellement sur les signatures (Task 12). Si vous obtenez des HTTP 401/404, les clés ne sont pas le problème.
Créez /etc/apt/keyrings (Task 13). C’est la convention moderne.
Utilisez un keyring par dépôt et signed-by (Task 13). Ciblez la confiance étroitement.
Relancez apt update. Si ça échoue encore, vérifiez l’heure (Task 9) et l’interception TLS (Task 15–16).

Checklist D: Fix proxy and TLS breakage without disabling security

Trouvez la configuration du proxy (Task 8). Les réglages proxy apt peuvent vivre dans plusieurs fichiers.
Confirmez que votre proxy supporte HTTPS CONNECT. Sinon, les dépôts HTTPS échoueront avec des bizarreries de handshake.
Corrigez la confiance des CA correctement :
- Si votre organisation intercepte le TLS, installez la CA racine d’entreprise dans le magasin de confiance OS.
- Si votre organisation peut autoriser un accès direct aux domaines de dépôt, contournez le proxy pour ces domaines.
Validez avec la sortie debug d’apt (Task 19). Rendez ça ennuyeux.

Erreurs courantes : symptôme → cause → correction

Cela revient constamment dans les environnements Proxmox parce que des gens copient/colle des configs de dépôts entre nœuds, et parce que l’UI Proxmox facilite de cliquer jusqu’au problème.

1) « Temporary failure resolving ‘download.proxmox.com’ »

Symptôme : Apt échoue avec des erreurs de résolution ; le ping par IP fonctionne.
Cause racine : DNS mal configuré ; systemd-resolved stub qui ne pointe nulle part ; firewall qui bloque UDP/TCP 53 ; DNS fractionné qui casse la résolution externe.
Correction : Validez avec getent et resolvectl status ; corrigez les serveurs DNS dans votre config réseau ; assurez la joignabilité du résolveur ; retestez.

2) « 401 Unauthorized » depuis enterprise.proxmox.com

Symptôme : Le fetch du dépôt enterprise échoue avec 401, parfois suivi de « not signed ».
Cause racine : Dépôt enterprise activé sans abonnement ; ou le proxy supprime l’auth ; ou la clé d’abonnement n’est pas installée où elle devrait l’être.
Correction : Désactivez le dépôt enterprise si vous n’avez pas d’abonnement et activez no-subscription ; si vous en avez un, vérifiez le statut d’abonnement dans Proxmox et le comportement du proxy.

3) « NO_PUBKEY … The repository is not signed »

Symptôme : Apt atteint le dépôt mais refuse de lui faire confiance.
Cause racine : Clé de signature d’archive manquante, mauvais keyring ou configuration de confiance obsolète.
Correction : Utilisez un keyring par dépôt dans /etc/apt/keyrings et signed-by ; ne comptez pas sur les approches globales dépréciées.

4) « Certificate verification failed: issuer unknown »

Symptôme : Le handshake TLS échoue ; apt signale un émetteur inconnu ou un certificat non approuvé.
Cause racine : Interception TLS d’entreprise sans CA racine installée ; bundle CA cassé ; heure incorrecte ; proxy présentant un certificat personnalisé.
Correction : Corrigez la synchronisation temporelle ; mettez à jour le bundle CA ; installez la CA d’entreprise si nécessaire ; évitez de désactiver la vérification.

5) « does not have a Release file »

Symptôme : 404 ou « Release file missing », souvent après avoir changé les labels de suite Debian.
Cause racine : Mauvaise suite/nom de code, mauvaise distribution, faute de frappe dans la ligne de dépôt, ou utilisation d’un dépôt non prévu pour votre release Debian.
Correction : Confirmez le nom de code Debian ; corrigez la ligne de dépôt ; évitez stable sur les nœuds d’infrastructure si vous voulez un comportement prévisible lors des transitions Debian.

6) Apt update fonctionne, mais les upgrades cassent plus tard des dépendances

Symptôme : apt update réussit ; apt full-upgrade veut supprimer des paquets Proxmox ou en retient d’autres critiques.
Cause racine : Dépôts mixtes de différentes suites ; définitions de dépôts dupliquées ; lignes Debian testing/unstable accidentelles ; mélange stale enterprise/no-subscription.
Correction : Nettoyez les sources pour une seule suite Debian et un seul canal Proxmox ; supprimez les lignes accidentelles ; utilisez apt-cache policy pour confirmer les origines.

7) « Write error (28: No space left on device) »

Symptôme : Apt ne peut pas écrire les fichiers de listes ; update échoue en cours de route.
Cause racine : Système de fichiers racine plein (logs, dumps, téléchargements d’ISO, anciens noyaux).
Correction : Libérez de l’espace, puis relancez update ; envisagez de déplacer les stockages volumineux hors du root et de mettre en place une rétention des logs.

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

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox propre en colo : trois nœuds, un petit pool Ceph, et une fenêtre de changement qui commençait toujours tard à cause des réunions. Pendant une mise à jour de routine, un nœud a refusé de se mettre à jour. L’erreur ressemblait à un problème de clé, donc l’opérateur est parti chasser des corrections GPG.

La mauvaise hypothèse : « Si apt dit ‘not signed’, c’est toujours un problème de clé. » Ce n’était pas le cas. Le nœud avait une ligne de dépôt enterprise activée parce que quelqu’un avait copié le même fichier .list depuis un environnement abonné des mois plus tôt. Cet environnement n’était pas abonné. Apt a reçu une réponse 401, puis s’est plaint de ne pas pouvoir vérifier un fichier qu’il n’avait jamais obtenu.

L’équipe a tenté trois importations de clés, ajouté une exception proxy, et envisagé brièvement de désactiver la vérification. Heureusement, la dernière étape a été bloquée par une ingénieure sécurité grincheuse qui avait raison pour une fois. Quand ils ont finalement lu attentivement la première ligne échouée — 401 Unauthorized — ils ont désactivé le dépôt enterprise et activé le dépôt no-subscription. Problème résolu en quelques minutes.

Le vrai coût fut le temps et la confiance. Le nœud est resté en retard sur les mises à jour de sécurité plus longtemps que nécessaire. Aussi, une fois que vous « réparez » des choses au hasard, vous ne pouvez plus expliquer facilement quel changement a compté. Après l’incident, ils ont ajouté un simple contrôle préliminaire : grep des lignes de dépôt enterprise et échouer le job de mise à jour si trouvé sur des clusters non abonnés.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise exécutait des nœuds Proxmox dans un réseau avec une politique d’egress stricte. Pour accélérer les mises à jour, quelqu’un a introduit un proxy de cache HTTP(S) et forcé tout le trafic Debian et Proxmox à le traverser. Sur le papier : téléchargements plus rapides, moins de connexions externes, audit plus simple. L’idée qui a l’air superbe dans une présentation.

Puis la réalité est arrivée. Le proxy avait l’interception TLS activée pour « analyse de sécurité ». L’équipe Linux n’a pas installé la CA racine d’entreprise sur les nœuds Proxmox parce que « ce ne sont que des mises à jour de paquets, ça ira ». Ça n’a pas été le cas. Apt a commencé à échouer avec des erreurs d’émetteur de certificat — de manière intermittente — selon quel nœud proxy dans la ferme répondait.

Ils ont « optimisé » encore en autorisant le fallback vers HTTP pour certains dépôts. Cela a fait disparaître les erreurs, jusqu’à ce que quelqu’un remarque que des métadonnées et des paquets traversaient le réseau sans TLS. Entamez une revue d’incident sécurité, puis un rollback rapide et désagréable.

La correction fut ennuyeuse : installer proprement la CA racine d’entreprise, contourner l’interception pour les domaines de dépôt lorsque la politique le permettait, et garder tout en HTTPS. Ils ont conservé un proxy pour le caching, mais ont arrêté de le laisser se faire passer pour Internet. Les gains de performance sont restés, mais maintenant les mises à jour sont prévisibles.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe avait une habitude qui semblait excessivement prudente : chaque nœud Proxmox avait la même disposition de dépôts, le même chemin de keyring, et le même script de pré-check exécuté avant la mise à jour. Rien de magique. Pas de débogage héroïque pendant la fenêtre de changement — car la plupart des problèmes étaient détectés plus tôt.

Un soir, un nœud a commencé à échouer les mises à jour avec « Temporary failure resolving ». Mais leur pré-check ne se contentait pas de lancer apt update ; il exécutait aussi des vérifications getent pour les noms d’hôtes des dépôts, enregistrait l’état du résolveur et confirmait la synchronisation temporelle. La sortie a été jointe automatiquement au ticket.

Quand l’astreinte a ouvert le ticket, elle n’a pas deviné. Elle a vu que le nœud avait changé de serveurs DNS après une maintenance réseau, pointant vers un résolveur qui servait des zones internes mais bloquait la récursion externe. Apt n’était pas cassé ; la politique DNS l’était.

Ils ont réparé en restaurant les résolveurs corrects dans la config du nœud et en mettant à jour le playbook réseau pour que les futurs changements n’abandonnent pas l’infrastructure sur un DNS « interne uniquement ». La pratique ennuyeuse n’a pas seulement accéléré la résolution ; elle a rendu l’incident moins stressant. Moins de stress veut dire moins de mauvaises décisions. Moins de mauvaises décisions veut dire moins d’incidents de suivi. Voilà le but.

FAQ

1) Dois-je utiliser le dépôt enterprise ou no-subscription ?

Si vous avez un abonnement et que vous tenez au support et à un flux de mises à jour curaté, utilisez enterprise. Si vous n’avez pas d’abonnement, désactivez enterprise et utilisez no-subscription. Exécuter enterprise sans droit d’accès ne fait que vous donner des erreurs 401.

2) Pourquoi apt dit « repository is not signed » après une erreur HTTP ?

Parce qu’apt attend des métadonnées signées (InRelease/Release.gpg). S’il ne peut pas les récupérer — à cause d’un 401/404/réseau — il peut signaler un problème de signature en conséquence. Lisez la première ligne « Err: » ; c’est généralement la défaillance réelle.

3) Est-il acceptable de définir `Acquire::https::Verify-Peer "false";` ?

Non. C’est comme apprendre à votre infrastructure à accepter des paquets altérés. Corrigez la confiance des CA ou le comportement du proxy à la place. Si vous devez faire quelque chose de temporaire pendant une urgence de maintenance, documentez-le, limitez la portée et retirez-le immédiatement.

4) J’ai corrigé le DNS mais apt échoue encore parfois. Pourquoi l’intermittence ?

Causes courantes : plusieurs serveurs DNS avec des règles de récursion incohérentes, chemin IPv6 cassé, load-balancing proxy défaillant, ou problèmes MTU provoquant des stalls de handshake TLS. Intermittent signifie « deux chemins existent et l’un est mauvais ».

5) Quelle est la façon la plus sûre de gérer les clés apt sur Proxmox ?

Utilisez des fichiers keyring par dépôt sous /etc/apt/keyrings et référencez-les avec signed-by= dans la ligne de dépôt. Évitez les magasins de confiance globaux sauf si vous voulez qu’une clé compromise bénisse tout.

6) Puis-je mélanger des dépôts Debian de différentes releases sur Proxmox ?

Vous pouvez, mais vous ne devriez pas. Mélanger les suites invite aux conflits de dépendances et aux upgrades imprévisibles. Gardez un seul nom de code Debian cohérent et un seul canal Proxmox cohérent. La monotonie gagne.

7) Pourquoi forcer IPv4 règle parfois « apt update » ?

Si votre nœud préfère IPv6 et que l’IPv6 de votre réseau est mal routé, filtré ou renvoie des réponses DNS cassées, les connexions peuvent se bloquer ou échouer. Forcer IPv4 est un outil de diagnostic ; la vraie correction est de faire fonctionner l’IPv6 ou de le désactiver de façon intentionnelle et cohérente.

8) Apt update réussit, mais l’interface Proxmox GUI se plaint encore des dépôts. Pourquoi ?

L’interface peut alerter sur la configuration du dépôt enterprise, l’état d’abonnement ou des canaux de dépôt non alignés. Confirmez que les fichiers réels dans /etc/apt/sources.list.d correspondent à votre intention, puis rafraîchissez l’UI.

9) Et si le nœud est isolé (air-gapped) ou sans Internet sortant ?

Alors apt update doit pointer vers un miroir interne que vous contrôlez, avec des clés de signature correctes et une disponibilité prévisible. Traitez ce miroir comme une infrastructure de production. S’il est instable, vos patchs le seront aussi.

Étapes suivantes (pour que ça reste corrigé)

Une fois que apt update fonctionne, ne vous arrêtez pas au « vert ».

Standardisez les fichiers de dépôts entre nœuds. Une suite Debian, une décision Proxmox, pas de duplicata.
Scoppez la confiance avec des keyrings signed-by. C’est plus propre, plus sûr et plus facile à auditer.
Faites du DNS et de la synchronisation temporelle des dépendances non négociables. Surveillez la joignabilité des résolveurs et l’état NTP comme vous surveillez la latence de stockage.
Documentez le comportement du proxy. Si l’interception TLS existe, intégrez l’installation de la CA dans le provisionnement. Ne laissez pas cela devenir un savoir tribal.
Ajoutez un script de pré-check. Exécutez-le avant les fenêtres de patch : routage, DNS via getent, synchronisation temporelle, vérifications de sanity des dépôts, espace disque.

Si vous faites tout cela, la prochaine fois que quelqu’un dira « apt est en panne », vous saurez déjà quelle couche ment.