Source : Upgrades from Debian 12 (bookworm) (en) (debian.org)

Je dispose d'une station de travail et d'un serveur fonctionnant sous Debian 12 (Bookworm). Je souhaite upgrader les 2 en Debian 13 (Trixie).

La station de travail (WS) étant physiquement accessible, je choisis de commencer par elle. En cas de problème grave (perte de connexion, boot impossible, etc.), il sera plus simple de reprendre le contrôle.

Une fois la WS complètement opérationnelle, j'effectue une mise à jour de VM du serveur tournant sur la WS.

Forte de ces deux expériences, j'effectue la mise à jour du serveur.

La mise à jour du serveur se faisant nécessairement en ssh, je choisis de faire les trois mises en jour via ssh.

La préparation vise à sauvegarder des informations système¹⁾ critiques et à procéder à un véritable nettoyage du système Debian 12 en cours d'utilisation. Ce nettoyage vise à mettre le système dans un état aussi proche que possible de l'état après une installation (clean install).

Si ce n'est déjà fait, pour chaque système, on prendra soin de documenter les particularités de configuration mises en place pour répondre aux spécificités de chaque environnement :

• dépôts non standards
• priorités de paquetages
• configurations d'applications permissives (samba, ssh…)

La mise à jour se compose d'une succession de mises à jour et se conclue par un nettoyage du système.

Une bonne pratique consiste à effectuer au moins deux mises à jours de portée différente. Une première mise à jour minimale, sans suppression de paquets. Une fois effectuée, une mise à jour complète effectuera toutes les mises à jour possibles au regard des dépôts déclarés.

Le nettoyage réitère certaines des opérations réalisées dans la phase préparatoire. Il vise à mettre le système Debian 13 issu de l'upgrade dans un état aussi proche que possible de ce qu'on aurait obtenu si on avait fait une installation à partir de zéro (clean install). Cela conduit jusqu'à débarrasser le système de scories de comptabilité Debian 12 / Debian 13 (apt sources, transitionnal packages, etc.).

Pour des tas de bonnes raisons, il est nécessaire d'enregistrer une trace automatisée des actions réalisées et de leurs résultats affichés dans le terminal. En cas de problème comme d'absence de problème, cela permet de savoir avec certitude ce que l'on a fait : comprendre les erreurs, documenter ce qui fonctionne, etc.

Les mises à jour se faisant “à distance” via ssh, il est très vivement recommandé de se prémunir de risques de coupure de connexion risquant de mettre un coup d'arrêt brutal à une action en cours de réalisation. Un des pire cas de figure est une interruption pendant le processus d'upgrade lui-même pouvant se traduire par un système incohérent jusqu'à être irrattrapable²⁾.

L'enregistrement des traces de lancement et d'exécution de commandes dans une terminal est usuellement traitée avec tee. La création de sessions indépendantes des terminaux depuis lesquels elles sont lancées est usuellement traitée en virtualisant les sessions via screen (ou tmux).

Screen (et tmux) offrent des options permettant de tracer les actions et leur résultats. Dans ces conditions, pas besoin de recourir à tee. Toutefois, que ce soit avec tee ou screen, les fichiers de traces peuvent devenir difficilement lisibles tant ils sont pollués par des séquences de caractères indésirables. Le filtre ans12txt peut grandement nettoyer les fichiers mais il n'est disponible qu'à partir de Trixie… La commande suivante permet d'effectuer un nettoyage substanciel :

cat screenlog.0 | perl -pe 's/\e([^\[\]]|\[.*?[a-zA-Z]|\].*?\a)//g' | col -b > typescript-processed

On effectue une mise à jour complète du système, comme à l'habitude de le faire.

Par précaution, on sauvegarde les données utilisatrices.

On sauvegarde également les informations système suivantes :

• /etc/
• /usr/local/
• /var/lib/dpkg/
• /var/lib/apt/extended_states
• la sortie de

  dpkg --get-selections '*'