Dépôt Proxmox sans abonnement : configurer les dépôts sans casser les mises à niveau

novembre 22, 2025 • février 3, 2026 • Lecture : 26 min • Views: 5

Cet article vous a aidé ?

Cette bannière rouge « No valid subscription » est agaçante, mais ce n’est pas votre vrai problème. Le vrai problème est la demi-solution : activer/désactiver des dépôts au hasard jusqu’à ce que apt update cesse de râler — et puis, lors de la prochaine mise à niveau, voir votre nœud transformé en objet de musée.

Si vous exécutez Proxmox en production sans abonnement, vous pouvez le faire proprement. Mais vous devez traiter les dépôts APT comme de la gestion du changement, pas comme un caprice. Ce guide montre exactement comment configurer correctement le dépôt no-subscription, maintenir l’alignement entre les suites Debian et Proxmox, et effectuer des mises à niveau sans roulette.

Ce que vous changez réellement (et pourquoi c’est important)

Quand vous « basculez vers le dépôt no-subscription », vous ne touchez pas à un simple réglage cosmétique. Vous modifiez la provenance des paquets Proxmox (kernel, qemu, pve-manager, pve-kernel, corosync, souvent les paquets Ceph), ce qui change :

Rythme des mises à jour : le dépôt enterprise est trié et retardé ; le no-subscription reflète davantage le pipeline d’emballage en amont.
Graphe de dépendances : les paquets Proxmox sont liés à une suite Debian spécifique (par ex. Bullseye ou Bookworm). Mélanger les suites provoque une dérive silencieuse des dépendances.
Sécurité du chemin de mise à niveau : les mises à niveau Proxmox sont en fait des montées de version Debian coordonnées plus des composants Proxmox. Les dépôts sont la feuille de route ; mal les configurer, c’est sortir de la route.

C’est tout à fait légitime d’exécuter no-subscription en labo et dans de nombreuses entreprises. La discipline requise est la même que pour des mises à jour de noyau en production : sources cohérentes, suites explicites, et pas de « juste ce paquet depuis testing ».

Une citation qui tient encore (idée paraphrasée) : « En opérations, l’automatisation et des valeurs par défaut prudentes préviennent les erreurs humaines répétées. » — idée paraphrasée attribuée à Gene Kim (thèmes DevOps)

Faits historiques et contexte qui expliquent le désordre actuel des dépôts

La configuration des dépôts dans Proxmox semble étrange jusqu’à ce que vous vous rappeliez comment le projet a grandi : pile de virtualisation, base Debian, Ceph optionnel, et chaîne de support payante. Un peu de contexte rend les conventions actuelles moins arbitraires.

Proxmox est basé sur Debian par conception, pas seulement « compatible Debian ». Cela signifie qu’APT est natif, et l’alignement des suites Debian est incontournable.
Le dépôt « enterprise » existe principalement pour la supportabilité : mises à jour plus lentes et triées, adaptées aux fenêtres de changement des clients payants.
Le dépôt « no-subscription » n’est pas « instable » ; il est simplement moins retardé. Les paquets y arrivent généralement plus tôt après les tests, et ce décalage a un impact sur le risque.
La bannière d’abonnement est au niveau de l’UI (pve-manager vérifie l’état des dépôts/abonnement). Ce n’est pas votre hyperviseur qui refuse de fonctionner.
Les versions majeures de Proxmox suivent étroitement les versions Debian. Si votre base Debian est Bookworm et que vos dépôts Proxmox pointent encore vers Bullseye, vous avez créé un OS en état de conflit.
Ceph dans Proxmox est verrouillé par version par Proxmox parce que les clusters requièrent des versions compatibles entre nœuds. Un désalignement de dépôts peut créer un cluster où la moitié des nœuds veut un Ceph différent.
Historiquement, Proxmox a empaqueté des noyaux personnalisés tôt pour fournir des fonctionnalités KVM/QEMU sans attendre Debian stable. C’est utile — jusqu’à ce que vous tiriez accidentellement un noyau d’une mauvaise suite.
Le pinning APT existe depuis les débuts de Debian pour gérer exactement ce problème : plusieurs dépôts, une seule politique. Les gens l’oublient, puis le réinventent mal avec des « hold » partout.

Le modèle de dépôts Proxmox : enterprise vs no-subscription vs Debian

1) Dépôts Debian

Votre nœud est Debian. Debian fournit la base utilisateur : libc, systemd, openssl, python, journald, et beaucoup d’« infrastructure ennuyeuse » sur laquelle Proxmox repose. Proxmox attend des suites Debian spécifiques :

PVE 7.x → Debian 11 (bullseye)
PVE 8.x → Debian 12 (bookworm)

Quand vous passez des versions majeures de PVE, vous effectuez en pratique une montée de version majeure Debian plus les paquets Proxmox. Cela signifie que vos lignes deb Debian doivent correspondre à votre version majeure PVE.

2) Dépôt Proxmox enterprise

C’est le canal payant. Si vous n’avez pas d’abonnement, laisser enterprise activé produit généralement des 401 Unauthorized ou des erreurs apt. Le pire n’est pas l’erreur ; c’est ce que les gens font ensuite : ils ajoutent des dépôts supplémentaires pour « réparer » cela, et créent accidentellement un Frankenhost à suites mixtes.

3) Dépôt Proxmox no-subscription

C’est le dépôt correct pour les systèmes non abonnés. Il est maintenu par Proxmox, sans la restriction enterprise. Vous recevrez toujours des mises à jour de sécurité ; elles arrivent simplement selon un calendrier différent.

4) Dépôts Ceph (si vous utilisez Ceph)

Si vous faites tourner Proxmox avec Ceph, traitez les dépôts Ceph comme faisant partie de la plateforme, pas comme une garniture optionnelle. Proxmox attend généralement une version majeure de Ceph par version PVE. Mélanger les dépôts Ceph transforme un cluster de stockage en art de performance.

Blague #1 : Les dépôts APT sont comme les machines à café de bureau : tout le monde pense pouvoir « juste modifier un truc », et ensuite personne ne peut travailler.

Base : à quoi ressemble une configuration no-subscription correcte

Une configuration correcte a trois caractéristiques :

Un seul canal Proxmox (enterprise OU no-subscription, pas les deux).
La suite Debian correspond à la version majeure PVE (bullseye pour PVE7, bookworm pour PVE8).
Dépôts Ceph alignés (soit le dépôt Ceph fourni par Proxmox pour votre version PVE, soit aucun si vous n’utilisez pas les paquets Ceph).

Proxmox utilise un mélange de /etc/apt/sources.list et /etc/apt/sources.list.d/*.list. Votre objectif est la clarté. Si vous ne pouvez pas expliquer ce que fait chaque ligne, ça n’a pas sa place en production.

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

Task 1: Identify your Proxmox and Debian versions (don’t guess)

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/2f1f9a3d)
pve-kernel-6.8: 6.8.12-2
qemu-server: 8.2.2
pve-qemu-kvm: 9.0.2-3

Ce que cela signifie : Ceci est un PVE 8.x. Votre base Debian doit être Bookworm, et la suite de votre dépôt Proxmox doit être bookworm.

Décision : Si vous voyez PVE 7.x, utilisez les suites Bullseye. Si PVE 8.x, utilisez Bookworm. Tout décalage est un arrêt immédiat avant les mises à niveau.

cr0x@server:~$ cat /etc/debian_version
12.5

Ce que cela signifie : Debian 12 (Bookworm). Cela correspond à PVE 8.x. Bien.

Décision : Si ceci affiche Debian 11 alors que vous êtes sur PVE 8, vous êtes déjà dans un état de mise à niveau partielle. Corrigez les dépôts avant de toucher à autre chose.

Task 2: Dump all APT sources in one view (humans need one page)

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-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Ce que cela signifie : Enterprise et no-subscription sont tous deux activés. Ce n’est pas de la « redondance », c’est une politique conflictuelle.

Décision : Désactivez enterprise si vous n’avez pas d’abonnement. Conservez uniquement no-subscription.

Task 3: Disable enterprise repo cleanly (don’t delete history unless you must)

cr0x@server:~$ sudo sed -i 's/^[[:space:]]*deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Ce que cela signifie : La ligne du dépôt enterprise est commentée, conservée pour l’audit.

Décision : Si vous avez un abonnement, faites l’inverse : conservez enterprise et désactivez no-subscription. Choisissez un canal.

Task 4: Ensure the no-subscription repo exists and targets the right suite

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Ce que cela signifie : Correct pour PVE 8.x sur Bookworm.

Décision : Si vous voyez bullseye ici sur un hôte Bookworm, corrigez-le avant de mettre à jour.

Task 5: Run apt update and interpret the failures like an adult

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

Ce que cela signifie : L’authentification des dépôts est correcte, les fichiers de release sont valides, et APT est content.

Décision : Si vous obtenez 401 Unauthorized, enterprise est probablement activé ou des identifiants en cache sont incorrects. Si vous obtenez « Release file changed », confirmez que vous êtes sur la suite prévue.

Task 6: Inspect candidate versions to detect mixed suites (quietly deadly)

cr0x@server:~$ apt-cache policy pve-manager
pve-manager:
  Installed: 8.2.4
  Candidate: 8.2.4
  Version table:
 *** 8.2.4 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Ce que cela signifie : pve-manager provient uniquement du dépôt Proxmox prévu.

Décision : Si vous voyez des candidats venant de plusieurs suites ou de dépôts inconnus, arrêtez et retirez les coupables. Les origines mixtes peuvent produire des mises à niveau « réussies » mais opérationnellement cassées.

Task 7: Detect cross-release Debian dependencies before you upgrade

cr0x@server:~$ apt-cache policy libc6 | sed -n '1,12p'
libc6:
  Installed: 2.36-9+deb12u9
  Candidate: 2.36-9+deb12u9
  Version table:
 *** 2.36-9+deb12u9 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
        100 /var/lib/dpkg/status

Ce que cela signifie : libc6 est strictement Bookworm. Bien.

Décision : Si vous voyez un candidat provenant de testing, sid ou d’une autre release Debian, vous avez une dérive de dépôts. Corrigez les sources et éventuellement pinnez.

Task 8: Verify the configured suites system-wide (APT preferences sanity)

cr0x@server:~$ apt-cache policy | sed -n '1,40p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm-updates InRelease
 500 http://deb.debian.org/debian bookworm InRelease
Pinned packages:

Ce que cela signifie : Seuls Bookworm et le dépôt Proxmox Bookworm sont présents.

Décision : Si vous voyez bullseye + bookworm simultanément, c’est presque toujours incorrect en dehors d’une fenêtre d’upgrade soigneusement gérée.

Task 9: Check for held packages (they’re sometimes justified, often forgotten)

cr0x@server:~$ apt-mark showhold
pve-kernel-6.5.13-5-pve

Ce que cela signifie : Quelqu’un a mis en hold un ancien noyau. Peut-être pour un contournement de pilote. Peut-être sans raison.

Décision : Si c’est intentionnel, documentez-le et planifiez sa suppression. Si c’est accidentel, retirez le hold sinon vous échouerez aux futures mises à niveau avec des erreurs de dépendances étranges.

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.5.13-5-pve
Canceled hold on pve-kernel-6.5.13-5-pve.

Task 10: Simulate an upgrade before you do it (cheap insurance)

cr0x@server:~$ sudo apt -o Debug::pkgProblemResolver=yes -s dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8.12-2-pve proxmox-ve qemu-server
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst pve-kernel-6.8.12-2-pve [6.8.12-1] (6.8.12-2 Proxmox bookworm/pve-no-subscription amd64)
Inst pve-manager [8.2.3] (8.2.4 Proxmox bookworm/pve-no-subscription amd64)
Inst proxmox-ve [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Inst qemu-server [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Conf proxmox-ve (8.2.2 Proxmox bookworm/pve-no-subscription amd64)

Ce que cela signifie : La mise à niveau est simple : pas de suppressions, pas de gymnatiques étranges du résolveur.

Décision : Si la simulation propose de supprimer proxmox-ve, pve-manager ou la moitié de votre pile réseau, arrêtez. Cela indique des dépôts mixtes, des pins ou un état de mise à niveau partielle.

Task 11: Confirm your running kernel vs installed kernels (avoid reboot surprises)

cr0x@server:~$ uname -r
6.8.12-1-pve

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.8.12-1-pve 6.8.12-1
pve-kernel-6.8.12-2-pve 6.8.12-2

Ce que cela signifie : Le nouveau noyau est installé mais pas encore en cours d’exécution.

Décision : Planifiez une fenêtre de redémarrage. Les mises à jour de noyau sans redémarrage sont comme acheter des extincteurs et les laisser en magasin.

Task 12: Check Proxmox services health after updates (don’t trust “apt succeeded”)

cr0x@server:~$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Ce que cela signifie : Aucun unit systemd en échec.

Décision : Si vous voyez pveproxy ou pvedaemon en échec, votre mise à niveau n’est pas « terminée ». Corrigez cela avant de toucher un autre nœud.

Task 13: If you use a cluster, confirm cluster health before and after repo changes

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

Quorum information
------------------
Date:             Thu Dec 26 14:03:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que cela signifie : Vous avez le quorum. Vous ne changez pas les dépôts sur un nœud déjà en feu.

Décision : Si non quorate, ne mettez pas à niveau. Réparez d’abord la communication du cluster.

Task 14: If you run Ceph, confirm Ceph package origin and cluster status

cr0x@server:~$ ceph -s
  cluster:
    id:     9a1b2c3d-1111-2222-3333-abcdefabcdef
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,c (age 5h)
    mgr: a(active, since 5h), standbys: b
    osd: 12 osds: 12 up (since 5h), 12 in (since 5h)

  data:
    pools:   4 pools, 128 pgs
    objects: 3.1M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     128 active+clean

Ce que cela signifie : Ceph est en bonne santé actuellement.

Décision : Si Ceph est dégradé, n’empilez pas des mises à jour par-dessus. Les changements de dépôts qui modifient les versions Ceph appartiennent aux fenêtres de maintenance avec plans de basculement explicites.

cr0x@server:~$ apt-cache policy ceph-common | sed -n '1,20p'
ceph-common:
  Installed: 18.2.2-pve1
  Candidate: 18.2.2-pve1
  Version table:
 *** 18.2.2-pve1 500
        500 http://download.proxmox.com/debian/ceph-reef bookworm InRelease
        100 /var/lib/dpkg/status

Ce que cela signifie : Les paquets Ceph proviennent du dépôt Ceph fourni par Proxmox pour cette série Ceph (exemple : Reef).

Décision : Si les paquets Ceph proviennent de Debian main ou de dépôts tiers aléatoires, arrêtez. Alignez-vous sur le dépôt Ceph Proxmox qui correspond à votre matrice de support PVE.

Task 15: Detect and remove “helpful” third-party repos

cr0x@server:~$ ls -1 /etc/apt/sources.list.d
pve-enterprise.list
pve-no-subscription.list
random-kernel-tuning.list

cr0x@server:~$ cat /etc/apt/sources.list.d/random-kernel-tuning.list
deb http://deb.debian.org/debian sid main

Ce que cela signifie : Quelqu’un a ajouté Debian sid. C’est comme ça que vous obtenez une nouvelle libstdc++ à 14h00 et une panne à 14h05.

Décision : Supprimez ou commentez immédiatement sauf si vous gérez délibérément un mix de suites avec pinning (rare, délibéré, documenté).

Task 16: Use APT pinning if you have a justified exception (and document it)

Si vous devez vraiment garder un dépôt supplémentaire (pour un outil de pilote spécifique, par exemple), pinnez-le pour qu’il ne puisse pas « gagner » par accident. Exemple minimal qui préfère Bookworm et Proxmox, tout en autorisant un dépôt externe seulement quand il est explicitement demandé.

cr0x@server:~$ sudo tee /etc/apt/preferences.d/99-local-pinning >/dev/null <<'EOF'
Package: *
Pin: release n=bookworm
Pin-Priority: 990

Package: *
Pin: origin "download.proxmox.com"
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: 50
EOF

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm InRelease
 500 http://deb.debian.org/debian sid InRelease
Pinned packages:
     release n=bookworm priority 990
     origin download.proxmox.com priority 990
     release a=unstable priority 50

Ce que cela signifie : APT préférera presque toujours Bookworm et Proxmox. Unstable est visible mais effectivement « opt-in ».

Décision : Si vous n’avez pas besoin de dépôts supplémentaires, ne les ajoutez pas. Le pinning est une ceinture de sécurité, pas un permis pour des cascades.

Playbook de diagnostic rapide

Quand les mises à niveau échouent, vous voulez trouver rapidement le goulot d’étranglement : mauvais dépôt, mauvaise suite, paquets cassés ou contraintes de cluster. Voici l’ordre qui fait gagner du temps.

First: repo reachability and auth

Exécutez apt update. Recherchez 401, erreurs de « Release file », ou des échecs DNS/TLS.
Si 401 Unauthorized : le dépôt enterprise est activé sans identifiants. Désactivez-le.
Si TLS ou DNS échoue : corrigez le réseau, la synchronisation temporelle ou les paramètres proxy avant de modifier les dépôts.

Second: suite alignment (Debian and Proxmox must agree)

Vérifiez pveversion -v et /etc/debian_version.
Exportez toutes les lignes deb avec grep sur les sources.
Tout mélange Bullseye/Bookworm en dehors d’une fenêtre d’upgrade est une cible de rollback immédiat.

Third: dependency solver preview

Simulez apt -s dist-upgrade.
Signaux d’alerte : propose la suppression de proxmox-ve, pve-manager, corosync, systemd, libc6, ifupdown2.
Stratégie de résolution : retirez les dépôts errants ; enlevez les holds ; corrigez les pins ; puis resimulez.

Fourth: cluster and storage constraints

Si en cluster : vérifiez le quorum (pvecm status) avant de toucher quoi que ce soit.
Si Ceph : vérifiez ceph -s et les origines des paquets Ceph. Ne changez pas les dépôts Ceph en pleine urgence.

Trois mini-récits d’entreprise issus des tranchées des dépôts

Mini-story 1: The incident caused by a wrong assumption

Ils avaient un petit cluster Proxmox utilisé pour des outils internes : runners CI, ticketing, une VM de monitoring que tout le monde avait oubliée comme mission-critique jusqu’à ce qu’elle ne le soit plus. Pas d’abonnement. Quelqu’un a vu la bannière d’abonnement et décidé de « ranger ».

L’hypothèse : « Le dépôt Enterprise donne juste de meilleures mises à jour ; le laisser ne fera pas de mal. » Ils ont activé enterprise, lancé apt update, obtenu une erreur d’auth, et « réparé » ça en ajoutant un dépôt Debian trouvé sur un thread de forum. Ce dépôt venait d’une suite Debian différente.

La mise à niveau avait l’air normale au début. Quelques paquets se sont mis à jour. Puis les services Proxmox ont commencé à redémarrer de façon étrange. L’interface web tanguait. Le démarrage des VM échouait de façon intermittente parce que les paquets qemu et les bibliothèques n’étaient plus cohérents avec l’ensemble attendu de dépendances.

Le post-mortem était ennuyeux dans le bon sens : APT a fait exactement ce qu’on lui a dit. Les sources du système décrivaient un OS qui n’existait pas. La correction fut aussi ennuyeuse : retirer enterprise pour les nœuds non abonnés, revenir à la bonne suite Debian, et relancer la mise à niveau dans une séquence contrôlée avec simulations d’abord.

Ce qui a changé ensuite : ils ont ajouté une checklist pré-changement pour les modifications de dépôts, et rendu « exporter toutes les sources APT » obligatoire avant toute mise à niveau. Ce n’était pas glamour. Ça a arrêté l’hémorragie.

Mini-story 2: The optimization that backfired

Une autre équipe voulait des mises à jour plus rapides, un CI plus rapide, tout plus rapide. Ils ont créé un proxy de mise en cache APT local et répliqué « tout ce dont ils pourraient avoir besoin » pour accélérer les installations. Objectif louable. L’erreur était subtile : ils ont répliqué plusieurs suites et n’ont pas imposé quelle suite les clients devaient utiliser.

Avec le temps, des nœuds ont commencé à tirer des paquets depuis le cache qui ne correspondaient pas à leur release OS, parce que le cache les présentait et que les priorités APT étaient en gros « ce qui semble le plus récent ». Ce n’était pas malveillant ; c’était l’entropie en tant que service.

Pendant des mois, « ça marchait », jusqu’à ce qu’une mise à jour de sécurité provoque une augmentation d’une dépendance critique. Soudain, un sous-ensemble de nœuds a mis à jour une bibliothèque depuis la mauvaise suite, et les paquets Proxmox sur ces nœuds ont refusé de se configurer proprement. La panne n’était pas totale ; elle était pire : partielle, intermittente et difficile à reproduire.

La solution n’a pas été d’abandonner la mise en cache. La solution a été de la contraindre. Ils ont séparé les caches par suite (Bookworm vs Bullseye), imposé des lignes de dépôts cohérentes, et utilisé le pinning pour que « le plus récent » ne signifie pas « le mauvais ». Performance revenue. Bon sens aussi.

Mini-story 3: The boring correct practice that saved the day

Celui-ci est volontairement peu sexy. Une organisation financière faisait tourner un cluster Proxmox pour VDI et quelques applications legacy. Pas d’abonnement, mais ils traitaient les mises à jour comme des changements de production : montées de version nœud par nœud, dépôts cohérents, et règle qu’aucune nouvelle ligne de dépôt n’entre en production sans ticket.

Un jour, un cycle de mise à jour de routine a coïncidé avec un vendor poussant un paquet cassé dans un dépôt tiers qu’ils utilisaient pour un agent de supervision unique. Ce dépôt n’était pas censé influencer Proxmox, mais il aurait pu si les priorités APT le permettaient.

Ils ont été protégés par deux choix ennuyeux. D’abord, ce dépôt tiers était piné bas, donc il ne pouvait pas remplacer les paquets système de base. Ensuite, ils ont toujours exécuté une simulation de dist-upgrade dans la revue de changement, et la simulation montrait le résolveur voulant supprimer un meta-paquet Proxmox. C’est le type d’alerte qu’on traite comme une alarme incendie, pas comme une suggestion.

Ils ont corrigé la ligne du dépôt et ont procédé. Pas d’incident, pas d’héroïsme, pas d’astreinte le week-end. Juste un rappel que l’excellence opérationnelle ressemble souvent à « rien ne s’est passé ».

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: `apt update` shows `401 Unauthorized` for enterprise

Cause racine : Le dépôt enterprise est activé sans jeton d’abonnement.

Correction : Commentez /etc/apt/sources.list.d/pve-enterprise.list ou supprimez le fichier. Activez uniquement no-subscription pour les nœuds non abonnés.

2) Symptom: “Release file changed” or “repository does not have a Release file”

Cause racine : Mauvais nom de suite (bullseye vs bookworm), ou une ligne obsolète laissée après une tentative de montée de version majeure.

Correction : Vérifiez la version majeure PVE et la version Debian, puis assurez-vous que toutes les lignes correspondent. Nettoyez les sources obsolètes dans sources.list.d.

3) Symptom: dist-upgrade wants to remove `proxmox-ve`

Cause racine : Dépôts mixtes ou dérive de dépendances (souvent depuis Debian testing/sid, ou des dépôts tiers qui surchargent les dépendances).

Correction : Retirez les dépôts fautifs ; effacez les holds ; relancez apt-cache policy proxmox-ve et assurez-vous que les candidats proviennent du dépôt Proxmox correct.

4) Symptom: Proxmox UI works, but VM starts fail with odd qemu errors

Cause racine : Versions de qemu-server et pve-qemu-kvm décalées en raison de mises à jour partielles ou d’origines mixtes.

Correction : Vérifiez apt-cache policy pour les paquets qemu. Alignez les dépôts ; exécutez un dist-upgrade complet ; redémarrez si des mises à jour de noyau/qemu le nécessitent.

5) Symptom: Ceph cluster starts complaining after “repo cleanup”

Cause racine : Les paquets Ceph proviennent maintenant du mauvais dépôt (Debian main ou une autre série Ceph) ou le dépôt a été retiré alors que les paquets restent.

Correction : Ré-ajoutez la série correcte du dépôt Ceph fournie par Proxmox pour votre version PVE ; vérifiez avec apt-cache policy ceph-common ; mettez à niveau Ceph uniquement avec une procédure de rolling planifiée.

6) Symptom: “You have held broken packages” during upgrade

Cause racine : Paquets en hold, versions pinées, ou état de mise à niveau partielle.

Correction : Inspectez les holds avec apt-mark showhold. Enlevez les holds intentionnels. Utilisez la simulation pour voir ce qui veut changer. Corrigez les dépôts avant de forcer des installations.

7) Symptom: Node upgrades but cluster tools misbehave (corosync warnings, quorum weirdness)

Cause racine : Mise à niveau d’un nœud vers une série majeure non alignée ou récupération de paquets liés au cluster depuis des sources différentes.

Correction : Gardez les nœuds du cluster sur la même série majeure en fonctionnement normal. Si vous effectuez une montée de version majeure, suivez un chemin de mise à niveau rolling planifié et gardez les dépôts cohérents par phase.

Blague #2 : Mélanger Bullseye et Bookworm, c’est comme fusionner deux organigrammes — soudain tout le monde dépend de « Depends », et personne n’approuve le changement.

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

Checklist A: Convert a standalone node to no-subscription safely (PVE already installed)

Snapshot your current state (human-readable): exportez les sources et les versions.
- Exécutez pveversion -v et sauvegardez la sortie.
- Exécutez grep sur les sources APT et sauvegardez la sortie.
Désactivez le dépôt enterprise en le commentant, pas en le supprimant (sauf si la conformité exige la suppression).
Activez le dépôt no-subscription pour la suite correcte (bullseye pour PVE7, bookworm pour PVE8).
Exécutez apt update et assurez-vous qu’il n’y a pas d’erreurs d’auth ou de fichier Release.
Inspectez les origines candidates pour pve-manager, proxmox-ve, pve-kernel, qemu-server.
Simulez un dist-upgrade. Si des suppressions sont proposées, arrêtez et corrigez les dépôts.
Effectuez la mise à niveau pendant une fenêtre de maintenance si des changements de noyau/qemu sont présents.
Redémarrez si un nouveau noyau a été installé. Vérifiez uname -r ensuite.
Post-check : vérifiez les services Proxmox et le démarrage des VM.

Checklist B: Cluster-aware repo change (because one node is never “just one node”)

Confirmez le quorum (pvecm status).
Choisissez un ordre : mettez à niveau les nœuds non critiques en premier ; conservez au moins N-1 de capacité pour le HA quand possible.
Assurez des sources APT identiques entre les nœuds pour la même release PVE. Les différences deviennent des incidents plus tard.
Un nœud à la fois : changement de dépôt, apt update, simulation, mise à niveau, redémarrage, validation.
Validez les fonctions du cluster : migrations, gestionnaire HA, connectivité stockage, stabilité corosync.

Checklist C: If Ceph is involved, treat repos as part of the storage platform

Vérifiez la santé Ceph (ceph -s) avant de toucher aux paquets.
Vérifiez l’origine des paquets Ceph (apt-cache policy ceph-common).
Alignez la série du dépôt Ceph sur tous les nœuds qui exécutent des démons Ceph.
Ne mélangez pas « mise à niveau Proxmox » et « mise à niveau Ceph » dans un même changement non borné. Séparez-les sauf si vous avez un runbook combiné testé.

FAQ

1) Is the no-subscription repository “unsafe”?

Non. Il est moins retardé que l’enterprise, ce qui augmente la vitesse des changements et donc le risque si vous ne gérez pas les mises à jour. La sécurité vient de votre processus : staging, simulation, suites cohérentes et redémarrages quand nécessaire.

2) Can I enable both enterprise and no-subscription and let APT choose?

Ne le faites pas. APT choisira selon les numéros de version et les priorités. Ce « choix » n’est pas une politique ; c’est un accident en attente d’arriver. Choisissez un canal.

3) Will disabling the enterprise repo remove the subscription banner?

Ça change les conditions qui déclenchent certains avertissements, mais la bannière concerne fondamentalement le statut d’abonnement. Votre objectif doit être un chemin de mise à niveau propre, pas une UI tranquille.

4) Why does Proxmox care so much about Debian suite alignment?

Parce que les paquets Proxmox sont construits contre les bibliothèques et l’outillage d’une release Debian spécifique. Mélanger les suites revient à mélanger libc, OpenSSL, composants systemd, et piles Python. Parfois ça passe — jusqu’au moment où ça casse.

5) I upgraded Debian to Bookworm. Can I keep PVE 7 repos temporarily?

C’est un état de mise à niveau partielle. Ça peut démarrer, mais ce n’est pas une politique stable. Alignez les dépôts Proxmox sur la version PVE que vous voulez exécuter, et suivez une vraie procédure de montée de version PVE plutôt que d’improviser.

6) Do I need the Ceph repo if I don’t run Ceph?

Non. Si vous n’utilisez pas les paquets Ceph, n’activez pas les dépôts Ceph « au cas où ». Chaque dépôt activé est une pièce mobile supplémentaire dans la résolution des dépendances.

7) What’s the safest way to spot a mixed-suite system?

Utilisez apt-cache policy sur des paquets core (libc6, systemd, pve-manager) et vérifiez les noms de release dans la sortie. Exportez aussi toutes les lignes deb depuis sources.list*. Les suites mixtes apparaissent rapidement.

8) Should I use `apt full-upgrade` or `apt dist-upgrade` on Proxmox?

Ils ont le même objectif (autoriser les changements de dépendances). L’important est de simuler d’abord et d’interpréter les suppressions proposées comme un signe d’alerte. Choisissez celui que votre équipe standardise, mais soyez cohérent.

9) Can I “fix” a broken upgrade by forcing packages with `dpkg --force`?

Vous pouvez, et vous pouvez aussi réparer une fuite avec du chewing-gum. Si les dépendances sont cassées parce que les dépôts sont faux, forcer les paquets rend généralement la récupération future plus difficile. Corrigez d’abord les sources et la politique.

10) How do I keep multiple Proxmox nodes consistent over time?

Standardisez les fichiers de dépôt, auditez-les périodiquement et traitez les changements de dépôts comme des changements de configuration. En pratique : gérez /etc/apt/sources.list.d/ via de l’automatisation, et exécutez des vérifications périodiques comparant les sorties de grep et apt-cache policy entre les nœuds.

Conclusion : étapes suivantes à faire dès aujourd’hui

Exécuter Proxmox sans abonnement n’est pas un péché. L’exécuter avec des dépôts chaotiques l’est. Si vous voulez des mises à niveau propres, choisissez une voie (enterprise ou no-subscription), alignez les suites Debian avec les versions majeures PVE, et ne « réparez » jamais une erreur d’auth en ajoutant des dépôts aléatoires.

Étapes suivantes :

Sur un nœud, exportez toutes les sources APT et confirmez que vous n’avez qu’un canal Proxmox activé.
Exécutez apt-cache policy pve-manager et confirmez que le candidat provient du dépôt et de la suite attendus.
Simulez un dist-upgrade. Si la simulation veut supprimer des paquets Proxmox principaux, considérez cela comme un défaut de configuration, pas comme une étape d’upgrade.
Si en cluster, effectuez les changements nœud par nœud avec vérifications de quorum et validations post-redémarrage.