Comment passer de Debian 12 à Debian 13 sur un serveur de production

La réponse d’abord : oui, c’est le moment

Deux faits déterminent le moment. Premièrement, Debian 12 « bookworm » a quitté le support de sécurité standard le 10 juin 2026 ; elle est désormais maintenue par l’équipe LTS (jusqu’en juin 2028), qui couvre la plupart des paquets mais offre une garantie plus étroite que le support complet de l’équipe sécurité. Deuxièmement, Debian 13 « trixie » a près d’un an et compte déjà cinq révisions mineures (13.5 au moment de la rédaction). La phase des early adopters est terminée depuis longtemps.

La mise à niveau en elle-même, c’est du Debian classique : sans éclat et fiable. La version courte :

1. Mettez bookworm entièrement à jour, nettoyez les paquets retenus et les dépôts tiers.
2. Pointez les sources APT vers trixie.
3. apt update → apt upgrade --without-new-pkgs → apt full-upgrade → redémarrage.

Sur un serveur de production, le travail réside dans la préparation, pas dans les commandes, surtout pour une machine que vous ne joignez que par SSH. Les commandes et adresses de ce guide sont illustratives ; substituez vos propres valeurs, et lisez en parallèle les notes de publication officielles ; elles restent la source qui fait autorité, et ce guide suit leur procédure.

Ce que vous obtenez : Debian 13 en un tableau

La durée de support restante est l’autre moitié du tableau : trixie bénéficie du support de sécurité complet jusqu’à environ août 2028, et du LTS jusqu’en juin 2030, soit quatre années de correctifs de plus que la machine que vous mettez à niveau.

Liste de vérification préalable

Faites tout cela avant de toucher aux sources. Une demi-heure ici, c’est ce qui rend la mise à niveau sans histoires.

1. Se mettre à jour et auditer l’état des paquets

Les montées de version qui sautent une release ne sont pas prises en charge ; vous devez d’abord être sur la dernière révision mineure de bookworm :

apt update && apt full-upgrade    # finish updating Debian 12
dpkg --audit                      # must be silent (no broken packages)
apt-mark showhold                 # holds will sabotage the upgrade — clear them

Retirez ensuite ce qui n’a plus sa place : les dépôts tiers (désactivez-les ; rajoutez des versions compatibles trixie par la suite), tout ce qui vient de bookworm-backports (aucun chemin de mise à niveau), et les paquets que vous n’utilisez plus ; chaque paquet retiré maintenant est un paquet qui ne pourra plus entrer en conflit plus tard.

2. Sauvegarder ce qui rend la restauration possible

Une vraie sauvegarde de vos données, plus les copies peu coûteuses de l’état du système que réclament les notes de publication :

tar czf /root/pre-upgrade-etc.tar.gz /etc
cp -a /var/lib/dpkg /root/pre-upgrade-dpkg
dpkg --get-selections '*' > /root/pre-upgrade-selections.txt

Soyez honnête avec vous-même sur le retour arrière : il n’existe aucun chemin de rétrogradation pris en charge. Si la mise à niveau tourne mal de façon irrécupérable, votre seul chemin de retour est votre sauvegarde (ou le reprovisionnement suivi d’une restauration, souvent plus rapide sur un hôte à provisioning rapide). Décidez maintenant de votre plan de reprise, pas à 2 h du matin en pleine crise.

3. Spécificités des serveurs distants : la partie qui vous sauve

Ces trois éléments sont ce qui distingue « mettre à niveau un serveur en rack » de « mettre à niveau un ordinateur portable », et le premier est le piège le plus redoutable de ce cycle :

• Figez les noms de vos interfaces réseau. Les notes de publication de trixie préviennent que certaines cartes réseau (notamment sur le pilote i40e, et certains systèmes ACPI) changent de nom d’interface sous le nouveau noyau. Si votre /etc/network/interfaces indique eno1 et que le nouveau noyau l’appelle enp5s0, la machine démarre sans réseau. Sur une machine distante, c’est un serveur mort. Figez le nom à l’adresse MAC avant la mise à niveau avec un fichier systemd .link :

# /etc/systemd/network/10-persistent-eth0.link
[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
Name=eth0

(Récupérez l’adresse MAC de votre carte réseau via ip link, puis référencez ce nom figé dans votre configuration réseau.)

• Lancez la mise à niveau dans tmux ou screen. Si votre connexion SSH tombe en plein full-upgrade, une session détachée maintient la mise à niveau en vie au lieu de laisser dpkg à moitié exécuté.
• Vérifiez que l’accès console hors bande fonctionne : IPMI/KVM-over-IP. Testez la connexion avant d’en avoir besoin. Cela transforme chaque pire scénario de cet article en une réparation de dix minutes au lieu d’un reprovisionnement.

4. Vérifiez les points sensibles qui vous concernent

Extrait de la liste des problèmes connus, ceux qui mordent les serveurs :

• OpenSSH 10 supprime entièrement les clés DSA. Si une clé autorisée ou une clé d’hôte est encore en DSA (il faudrait qu’elle soit vraiment ancienne), remplacez-la par de l’Ed25519 avant la mise à niveau, sous peine d’être bloqué dehors dès la première tentative SSH après coup.
• Bases de données et messagerie : arrêtez MariaDB proprement avant la mise à niveau (la récupération après crash entre versions échoue) ; le format de configuration de Dovecot a changé de façon incompatible ; RabbitMQ n’a pas de chemin de mise à niveau direct. Si vous utilisez ces services, lisez d’abord leurs sections respectives et planifiez la migration au niveau du service.
• Racine chiffrée ? Assurez-vous que systemd-cryptsetup est installé avant le redémarrage.
• Espace disque : apt vous indique ce dont full-upgrade a besoin sur / ; vérifiez aussi que /boot dispose d’environ 300 MB libres. Des partitions boot sous-dimensionnées héritées d’anciens modèles de provisioning sont un classique qui bloque les mises à niveau.

La mise à niveau

Étape 1 : pointer APT vers trixie

Les systèmes bookworm utilisent généralement encore le format classique à une ligne. Modifiez /etc/apt/sources.list (et tout ce qui se trouve dans /etc/apt/sources.list.d/) en remplaçant bookworm par trixie. Notez la façon dont la suite de sécurité est nommée :

deb http://deb.debian.org/debian trixie main
deb http://deb.debian.org/debian trixie-updates main
deb http://security.debian.org/debian-security trixie-security main

(APT 3.0 préfère le nouveau format deb822, mais la conversion est plus propre après la mise à niveau : un changement à la fois. apt modernize-sources s’en chargera pour vous à ce moment-là.)

Étape 2 : les trois commandes

Dans votre session tmux :

apt update
apt upgrade --without-new-pkgs    # minimal upgrade first — safer ordering
apt full-upgrade                  # the real event

Cette structure en deux phases est délibérée et vient directement des notes de publication : la passe minimale met à niveau ce qu’elle peut sans rien installer ni supprimer de nouveau (des paquets « conservés » à ce stade, c’est normal), ce qui réduit le volume de changements simultanés lorsque full-upgrade prend ensuite en charge le noyau, les transitions d’ABI et les suppressions. Attendez-vous à quelques invites conffile : la réponse par défaut sûre est de conserver votre version (N) et d’examiner les différences ensuite ; full-upgrade proposera aussi de supprimer des paquets obsolètes, et cela vaut la peine de vraiment lire cette liste avant de confirmer.

Sur un serveur typique, cela télécharge quelques gigaoctets et prend entre quinze minutes et une heure selon le nombre de paquets et la vitesse du disque.

Étape 3 : redémarrer et vérifier

systemctl reboot

Confirmez ensuite les bases dès que le serveur est de retour :

cat /etc/debian_version   # expect 13.x
uname -r                  # expect a 6.12 kernel
systemctl --failed        # what didn't come up?
ss -tlnp                  # are your services listening?

S’il ne revient pas : c’est le moment de la console KVM. Les deux coupables les plus probables sur une machine distante sont le renommage d’interface (résolu par le fichier .link ci-dessus, ou réparable depuis la console) et les problèmes de bootloader/initramfs, tous deux diagnosticables hors bande.

Étape 4 : nettoyage après la mise à niveau

apt autoremove --purge     # dependencies nothing needs anymore
apt purge '?obsolete'      # packages no longer in any repo
apt modernize-sources      # optional: convert sources to deb822, now that things are stable

Changements de trixie à vérifier après la mise à niveau

Trois changements de comportement surprennent ceux qui ont fait une mise à niveau plutôt qu’une installation neuve :

• /tmp est désormais un tmpfs adossé à la RAM (jusqu’à 50 % de la RAM), activé dès votre premier redémarrage après la mise à niveau, avec nettoyage automatique : les fichiers inutilisés depuis 10 jours dans /tmp (30 dans /var/tmp) sont supprimés. Si une application écrit de gros fichiers temporaires, redirigez-la ailleurs ou revenez à un /tmp sur disque (systemctl mask tmp.mount puis redémarrage). Notez que les systèmes mis à niveau reçoivent un extrait de compatibilité pour tmpfiles.d qui préserve l’ancien comportement de nettoyage ; vérifiez /etc/tmpfiles.d/tmp.conf pour savoir dans quel régime vous êtes.
• /etc/sysctl.conf n’est plus lu. Les réglages de noyau que vous y aviez conservés cessent silencieusement de s’appliquer ; déplacez-les vers des fichiers /etc/sysctl.d/*.conf (les réglages de pare-feu et de tuning de notre liste de vérification de durcissement s’y trouvent déjà de toute façon).
• Petits outils supprimés : last/lastlog ont disparu (utilisez lslogins, wtmpdb) ; isc-dhcp-client est déprécié. Le simple ping fonctionne désormais sans privilèges. Les scripts qui supposaient la présence des anciens outils ont besoin d’un petit ajustement.

La configuration réseau côté serveur est un territoire inchangé : les installations serveur de trixie utilisent encore ifupdown par défaut (/etc/network/interfaces), donc votre configuration existante passe telle quelle, mis à part le risque de renommage.

Questions fréquentes

Combien de temps dure le processus complet ?

Prévoyez une fenêtre de maintenance d’une à deux heures pour un serveur simple : le téléchargement et l’installation des paquets prennent généralement moins d’une heure, plus un redémarrage et votre temps de vérification. La préparation (sauvegardes, audits, fixation des noms) ajoute une demi-heure en amont, mais n’a pas besoin d’entrer dans la fenêtre. Ce qui fait exploser le budget, c’est une préparation bâclée. Un paquet retenu ou un /boot plein découvert en pleine mise à niveau transforme une tâche de routine en un après-midi entier.

Puis-je passer directement de Debian 11 à 13 ?

Non. Les montées de version qui sautent une release ne sont explicitement pas prises en charge. Le chemin est 11 → 12 → 13, en terminant chaque saut (redémarrage compris) avant d’entamer le suivant. Si une machine a deux releases de retard, pesez honnêtement le reprovisionnement sous Debian 13 suivi d’une restauration des données contre deux mises à niveau sur place successives ; sur un hôte à provisioning rapide, l’installation neuve l’emporte souvent à la fois en temps et en confiance.

Est-ce sûr de faire cela par SSH ?

Oui, avec les trois précautions de la liste de vérification : travaillez dans tmux/screen (pour qu’une connexion coupée ne tue pas dpkg), figez les noms d’interface avant la mise à niveau (pour que le nouveau noyau ne puisse pas renommer votre carte réseau sous le nez de la configuration réseau), et vérifiez à l’avance que l’accès console hors bande fonctionne. Des milliers de serveurs Debian distants sont mis à niveau ainsi à chaque cycle de release ; les histoires d’horreur viennent presque toujours d’une de ces trois précautions négligée.

Dois-je convertir mes sources APT vers le nouveau format deb822 ?

Oui, à terme. C’est le défaut pour les nouvelles installations, les outils d’APT 3.0 le présupposent, et le format à une ligne est déprécié (bien qu’encore pris en charge pour des années). Mais faites-le après la mise à niveau de release, avec apt modernize-sources, pas pendant : regrouper une migration de format de configuration dans la même fenêtre de changement qu’une mise à niveau de distribution rend simplement toute panne plus difficile à attribuer.

Debian 14 arrive ; dois-je l’attendre ?

Non. « Forky » est attendue courant 2027, sans date annoncée, et l’attendre signifie faire tourner bookworm encore plus d’un an sur un support LTS qui se réduit. Passez à trixie dès maintenant, profitez du support de sécurité complet, et refaites ce même saut quand forky aura une révision mineure ou deux de maturité. Cette cadence (mettre à niveau environ un an après chaque release) est le rythme confortable pour du Debian en production.

Déployer sur Serverside

Deux choses sur notre plateforme désamorcent la peur de cette procédure : l’accès console KVM-over-IP sur chaque serveur dédié Debian (de sorte qu’un renommage d’interface ou un accroc au démarrage devient une session console, pas un ticket de support), et le provisioning en moins d’une minute sur l’ASN 55285, qui fait du filet de sécurité reprovisionnement-puis-restauration un vrai plan B rapide (et de l’installation neuve de Debian 13 le plan A facile pour les nouvelles machines).

Pour aller plus loin sur Debian et les sujets liés aux mises à niveau : comment choisir une distribution Linux, la liste de vérification de durcissement de la première heure à exécuter sur toute machine fraîchement mise à niveau, et des règles de pare-feu par défaut sensées.