Petit retour suite à la montée en version de Debian 10 Buster vers Debian 11 Bullseye.

Comme tout le monde, j'ai utilisé les commandes suivantes :

apt update
apt dist-upgrade

Une fois la dernière version de Debian 10 installée, j'ai utilisé ces commandes pour mettre à jour les dépôts :

sed -i 's/buster\/updates/bullseye-security/g;s/buster/bullseye/g' /etc/apt/sources.list
sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*

Attention à cette dernière commande qui change les dépôts annexes (nodejs, proxmox, ...).
Ensuite :

apt update
apt dist-upgrade
apt autoremove -y
apt autoclean
apt purge
reboot

Dans l'ensemble, cela s'est bien passé mais j'ai eu un certain nombre d'effets secondaires....

Conteneurs LXC :

J'ai commencé par mettre à jour mes conteneurs LXC Debian hébergés sur Proxmox 6 qui fournissent un seul service (bind, nodejs, ...).
Après le reboot, j'ai constaté un problème de réactivité (latence clavier, requêtes aux services interminables, ...)
Pour ce premier problème, j'ai constater que Debian 11 nécessitait plus de RAM que Debian 10.
Mes plus petits conteneurs sont passés de 256MB à 320MB de RAM afin de résoudre ce problème.

Le deuxième problème était le Login en TTY ou SSH qui prenait une plombe...
Le problème venait de l’utilisation des NameSpaces par systemd-logind.
Proxmox préconise d'activer le "nesting" et il est maintenant activé par défaut pour les conteneurs dans Proxmox 7.
Comme je ne suis pas encore au clair avec tous cela, j'ai préféré masquer logind dans les conteneurs pour le moment.

systemctl mask systemd-logind.service

Je vous conseille cette page du forum pour vous faire une idée :
https://forum.proxmox.com/threads/lxc-container-upgrade-to-bullseye-slow-login-and-apparmor-errors.93064/

PHP 7.3 -> 7.4 :

Lors de la montée en version certains serveurs utilisant PHP 7.3 sont passés en PHP 7.4.
Les configs n'ont pas suivis de "/etc/php/7.3/*" à "/etc/php/7.4/*".
Comme je n'avais que quelques serveurs, j'ai fait ça à la mano et c’était laborieux...

Proxmox (Mail Gateway, Backup) :

J'ai commencé par mon cluster "Proxmox Mail Gateway" en LXC sur deux sites distants, aucun problème.
Puis par mes serveurs "Proxmox Backup" en VM sur deux sites distants, aucun problème.

Proxmox VE :

J'ai commencé par mon Cluster "Domestique", 3 vielles machines gonflées à bloque pour mes tests en campagne avec la connexion qui va avec.
Sur ces machines, j'utilise la carte réseau de la carte mère pour l'accès à Proxmox.
La mise à jour s'est bien passée à l’exception des cartes réseaux supplémentaires qui changent de noms.
Sur cette infrastructure plutôt simpliste, tout peux être réglé en ssh ou https.

Puis je suis passé à mon cluster "Pro" distant (3 serveurs identiques avec 1 interface réseau sur le board et 4 interfaces réseau sur carte PCI).
J'ai commencé par le serveur de test qui utilisait pourtant ifupdown2 mais lors du reboot, plus de réponse.
J'ai checké sur le switch et les 4 interfaces supplémentaire étaient down.
Comme l'interface d'administration était sur cette carte, j'ai du aller sur site pour gérer les bridges (vmbr) avec les nouveaux noms d'interface (pour info, le nom de l'interface du board n'a pas changé).

Ensuite je suis passé au deuxième serveur qui héberge les services qui peuvent être dégradés.
Ayant appris du premier serveur, j’ai anticipé les problèmes et les évités.
Toutefois, j'avais deux conteneurs CentOS7 qui ne fonctionnaient plus et cela était clairement indiqué dans la doc de Proxmox (migration sur les cgroup v2 incompatible avec la version systemd de CentOS 7).
Pour supporter ces vieux services qui ne sont pas exposé sur internet, j'ai installé un Proxmox 6 dans une VM du Proxmox 7 afin de gérer ces 2 conteneurs.

Et pour le troisième qui devait passer comme une lettre à la poste, ce fut plus compliqué....
J'ai lancer la mise à jour en anticipant les changements de nom d'interfaces réseaux et lors du reboot, plus de réponse.
Intervention sur site et que vois-je, le nom de l'interface n'avait pas changé.
Je corrige le bridge et redémarre.
Tous semble rentré dans l'ordre, sauf que...
Mes VM restent figées au boot et même un stop dans l'interface de Proxmox prend une plombe.
Je migre une VM sur un autre serveur et elle fonctionne, je la migre à nouveau sur ce troisième serveur et je me retrouve dans la situation précédente.
Je fini par comprendre que ce serveur avait redémarrer sur un ancien Kernel.
Je nettoie l'ancien Kernel et redémarre me retrouvant sans accès réseau.
Le nom des interfaces avait changé et j'avais oublié ce problème entre temps.
Il m'aura fallu retourner sur site encore une fois mais ce fut la dernière.

Conclusion :

La montée en version est assez facile mais il vaut mieux avoir un accès physique ou virtuel à la console et prévoir un peut de temps pour gérer les imprévus.