Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Relever pveversion -v et la version Debian de l’hôte. Les dépôts Debian et Proxmox doivent correspondre à cette version. Une procédure écrite pour une génération précédente n’est pas automatiquement transposable ; les changements de version majeure nécessitent le guide de migration correspondant.
Le dépôt Enterprise demande un abonnement. Le dépôt no-subscription est disponible sans cet abonnement et possède un niveau de validation différent. Désactiver un dépôt Enterprise non utilisable et ajouter le canal documenté est distinct de falsifier le statut d’un abonnement. Ne pas modifier les fichiers de l’API pour annoncer une licence active : cela fausse le diagnostic et fragilise les mises à jour.
Vérifier les sauvegardes récentes et une méthode de restauration, l’espace système et les pools, les tâches en cours, le quorum d’un éventuel cluster et l’accès à la console. Si le pare-feu est virtualisé sur cet hôte, son arrêt peut couper l’accès distant : prévoir l’intervention depuis le site ou une console indépendante.
Actualiser les index et lire les erreurs de signatures ou de dépôts. Examiner la liste des changements et la simulation de l’opération recommandée par Proxmox. Une proposition de suppression de paquets importants doit être comprise avant confirmation. Ne pas employer un script distant exécuté à l’aveugle pour répondre « oui » à toutes les options.
Appliquer les mises à jour selon la documentation de la version. Prévoir le redémarrage quand il est requis pour utiliser un nouveau noyau. Après redémarrage, vérifier version démarrée, interfaces, montages, santé des stockages, démarrage des VM/CT et services critiques vus par leurs utilisateurs.
Pour un cluster, suivre la séquence de maintenance adaptée à sa disponibilité et à son stockage. Sur un hôte unique, accepter et annoncer une interruption contrôlée plutôt que prétendre à une haute disponibilité inexistante.
À conserver : liste des paquets, date, compte intervenant, résultat des tests et éventuels écarts. Les optimisations post-installation doivent répondre à un besoin mesuré ; désactiver HA, services ou contrôles de sécurité sans analyse n’est pas une étape obligatoire.
Refresh renouvelle l’inventaire des paquets ; Upgrade exécute une mise à jour. Dans Repositories, vérifier chaque entrée : origine, suite Debian/PVE, composant, activation et état de signature. Le dépôt Enterprise nécessite le droit d’accès approprié ; le dépôt no-subscription est une alternative officielle avec un modèle de validation différent. test n’est pas un choix de production par défaut.
Ne pas mélanger des générations de distribution pour faire apparaître un paquet plus récent. Les fichiers .sources utilisent des champs tels que Types, URIs, Suites, Components et Signed-By; les anciennes entrées .list peuvent encore être présentes. Rechercher les doublons avant d’ajouter une nouvelle entrée.
| Message / situation | Cause à rechercher | Correction raisonnée |
|---|---|---|
| 401 / accès refusé | Dépôt soumis à abonnement sans droit valable | Corriger l’accès ou choisir le canal officiel adapté |
| 404 / pas de Release | Suite ou URL inexistante, dépôt abandonné | Vérifier le système et la documentation du fournisseur |
| Signature invalide / clé absente | Clé, expiration, horloge ou origine | Vérifier l’empreinte officielle ; ne pas désactiver la vérification |
| Doublon | Même source dans plusieurs fichiers | Conserver une définition cohérente |
| Nom non résolu | DNS ou réseau | Corriger la résolution, pas l’URL au hasard |
| Espace insuffisant | Racine, cache ou inodes | Libérer de façon ciblée après inventaire |
Une mise à jour majeure nécessite le guide de migration de la version et son outil de précontrôle lorsqu’il existe. Ne pas remplacer toutes les suites puis lancer une commande globale sans traiter ses avertissements.
Une tâche quotidienne de reboot n’est pas un mécanisme universel de fiabilité. Si elle existe, coordonner sauvegardes, vérifications PBS, démarrage du pare-feu et services de base. Ne pas interrompre un déplacement de disque, une restauration ou une opération de stockage. Définir une exclusion et une alerte en cas de report plutôt que forcer l’arrêt.
Les correctifs à faible risque peuvent être automatisés après simulation et tests ; un changement majeur, réseau, stockage ou base de données exige une validation adaptée. Pour une alerte de vulnérabilité, vérifier la version de paquet et le correctif rétroporté, pas uniquement la version amont affichée.
Conserver date, anciennes/nouvelles versions et résultat des tests. Une sauvegarde d’invité ne restaure pas à elle seule la configuration de l’hôte. Prévoir support d’installation, configuration et procédure de réattachement des stockages. Un retour de noyau peut être possible dans certains cas ; ne pas promettre que la désinstallation de paquets annule un changement de schéma ou de format de données.