Debian 13 Trixie : ce qui change pour un serveur

Debian 13 « Trixie » est publiée depuis le 9 août 2025 et sa dernière version ponctuelle est la 13.6 (11 juillet 2026). Pour un serveur, trois changements comptent vraiment : /tmp devient un disque en mémoire (tmpfs), /etc/sysctl.conf n'est plus lu, et les commandes last et lastlog sont supprimées. La migration depuis Debian 12 se fait en deux temps (apt upgrade --without-new-pkgs puis apt full-upgrade), et elle peut vous couper SSH ou le réseau si vous ne préparez pas le terrain. Ce guide couvre ce qui change concrètement, la procédure de migration, et les pièges qui font tomber une production.

Ce que vous allez apprendre

Situer Debian 13 : dates de publication, durée de support, versions livrées.
Identifier les changements de Trixie qui touchent réellement un serveur, pas un poste de bureau.
Migrer une Debian 12 « Bookworm » vers Trixie en suivant la procédure officielle, dans le bon ordre.
Reconnaître les deux formats de sources APT et savoir lequel vous avez, avant de tout casser.
Anticiper les pièges qui coupent la production : SSH, noms d'interfaces réseau, chiffrement, MariaDB.
Préparer dès aujourd'hui la future Debian 14 « Forky ».

Debian 13 en bref

Avant de toucher à un serveur en production, il faut savoir combien de temps la version tiendra et ce qu'elle apporte. Debian n'est pas une distribution à cycle court : une version majeure vous engage pour cinq ans, et ce calendrier détermine quand vous devrez rejouer l'exercice.

Dates et durée de support

Debian 13.0 est sortie le 9 août 2025. Le support complet dure trois ans, jusqu'au 9 août 2028 : c'est l'équipe de sécurité Debian qui publie les correctifs. Ensuite, le relais est pris par l'équipe LTS (Long Term Support) jusqu'au 30 juin 2030, soit cinq ans de couverture au total.

Un point de vocabulaire qui fait perdre du temps à beaucoup d'administrateurs : une version ponctuelle comme la 13.6 n'est pas une nouvelle version de Debian. C'est une simple republication des images avec les paquets mis à jour depuis. Si votre serveur est en Debian 13 et que vous appliquez vos mises à jour de sécurité régulièrement, vous êtes déjà « en 13.6 » sans avoir rien fait de spécial. Rien à voir avec le saut de Bookworm vers Trixie, qui, lui, est une montée de version majeure.

Les versions livrées par Trixie

Le tableau ci-dessous compare les briques que vous manipulez le plus sur un serveur. Lisez-le comme une liste de choses à retester : chaque saut de version majeure est un risque de régression de configuration, surtout sur les serveurs web et les bases de données.

Composant	Debian 12 (Bookworm)	Debian 13 (Trixie)
Noyau Linux	série 6.1	série 6.12
systemd	252	257
OpenSSH	9.2p1	10.0p1
APT	2.6	3.0.3
nginx	1.22	1.26
Apache	2.4.62	2.4.65
PostgreSQL	15	17
MariaDB	10.11	11.8
Python	3.11	3.13
PHP	8.2	8.4
OpenSSL	3.0	3.5
glibc	2.36	2.41
Samba	4.17	4.22

Le numéro de noyau est donné en série 6.12 volontairement : le numéro mineur exact bouge à chaque version ponctuelle, ne le figez pas dans vos documents d'exploitation. Le saut PostgreSQL 15 vers 17 et MariaDB 10.11 vers 11.8 sont les deux qui demandent le plus d'attention, une base de données ne se migre pas à l'aveugle.

Les architectures matérielles

Trixie ajoute riscv64 à la liste des architectures officiellement prises en charge, une première. À l'inverse, mipsel et mips64el sont retirées, et armel vit sa dernière version : Trixie est la dernière Debian à le prendre en charge.

Le cas i386 mérite une correction, car il circule beaucoup d'approximations. i386 n'est pas supprimé de Debian 13. Ce qui disparaît, c'est le noyau officiel et l'installateur i386. L'architecture reste disponible en multiarch, c'est-à-dire pour faire tourner des binaires 32 bits sur un système amd64, ou dans un chroot. C'est même devenu sa seule raison d'être. La consigne officielle est nette : les utilisateurs de systèmes i386 ne doivent pas mettre à niveau vers Trixie, Debian recommande de réinstaller en amd64.

Ce qui change pour un serveur

Voici le cœur du sujet. La plupart des articles sur Trixie listent les nouveautés du bureau. Sur un serveur, ce sont d'autres choses qui vous réveillent la nuit : un répertoire temporaire qui mange la RAM, un tuning noyau silencieusement ignoré, et des outils d'audit qui n'existent plus.

/tmp devient un disque en mémoire

C'est le changement le plus visible. Par défaut, /tmp est monté en tmpfs, un système de fichiers en mémoire vive. Sa taille est plafonnée à 50 % de la mémoire de la machine. Attention au sens du mot plafond : c'est un maximum, pas une réservation. La RAM n'est consommée qu'à mesure que des fichiers sont écrits.

L'impact serveur est réel. Un job qui déposait un dump SQL de 40 Go dans /tmp sur une machine à 32 Go de RAM fonctionnait très bien en Bookworm ; il échouera en Trixie. Un redémarrage vide désormais /tmp intégralement, ce qui casse tout processus qui s'attendait à y retrouver un état. Vérifiez ce que vos applications y écrivent avant de migrer.

Point crucial pour une machine mise à niveau : le tmpfs ne s'applique qu'après un redémarrage. Les anciens fichiers de /tmp ne sont pas effacés, ils sont masqués par le nouveau montage. Pour les récupérer :

# Monter la racine réelle ailleurs pour voir sous le tmpfs
sudo mount --bind / /mnt
ls /mnt/tmp          # les anciens fichiers sont ici
sudo umount /mnt

Trois façons d'adapter ce comportement, selon ce que vous voulez. Pour agrandir le tmpfs, on édite l'unité systemd avec systemctl edit :

sudo systemctl edit tmp.mount

[Mount]
Options=mode=1777,nosuid,nodev,size=2G

Pour revenir à un /tmp sur disque, on masque carrément l'unité, puis on redémarre :

sudo systemctl mask tmp.mount
sudo reboot

Enfin, si votre serveur a déjà une partition /tmp déclarée dans /etc/fstab (le fichier des montages persistants au démarrage), vous n'êtes pas concerné : votre partition l'emporte, le tmpfs ne s'active pas.

Le sujet connexe est le nettoyage automatique. Sur une installation neuve, systemd-tmpfiles purge /tmp au bout de 10 jours et /var/tmp au bout de 30 jours. Sur une machine migrée, l'ancien comportement est préservé : la migration crée un fichier /etc/tmpfiles.d/tmp.conf qui neutralise le nouveau défaut. Supprimez ce fichier si vous voulez aligner votre serveur migré sur le comportement d'une installation neuve.

/etc/sysctl.conf n'est plus lu

Celui-là est vicieux, parce qu'il échoue en silence. systemd-sysctl ne lit plus /etc/sysctl.conf. Si votre serveur porte du tuning réseau ou noyau dans ce fichier (limites de connexions, somaxconn, activation du routage, paramètres TCP), ces réglages ne seront plus appliqués après la migration. Aucun message d'erreur, juste des performances qui s'effondrent ou un routage qui ne fonctionne plus.

La correction est simple, et à faire avant de redémarrer : déplacez votre configuration dans /etc/sysctl.d/, où chaque fichier .conf est chargé normalement.

# Vérifier si vous avez du tuning à récupérer
grep -v -e '^#' -e '^$' /etc/sysctl.conf

# Le déplacer dans le répertoire lu par systemd
sudo cp /etc/sysctl.conf /etc/sysctl.d/99-local.conf

# Recharger et vérifier qu'un paramètre est bien pris en compte
sudo sysctl --system
sysctl net.ipv4.ip_forward

last, lastb et lastlog sont supprimées

Trixie supprime last, lastb et lastlog. Ce n'est pas un caprice : les formats de fichiers wtmp, btmp et lastlog stockent les dates sur 32 bits et ne survivent pas à l'an 2038. Debian a préféré les retirer plutôt que de les laisser mentir.

Si vos scripts d'audit ou vos procédures de sécurité s'appuient sur ces commandes, ils casseront. Les remplacements sont dans wtmpdb, lastlog2 et util-linux :

Commande retirée	Remplacement	Usage
`last`	`wtmpdb last`	Historique des connexions
`lastb`	`lslogins --failed`	Tentatives de connexion échouées
`lastlog`	`lastlog2` ou `lslogins`	Dernière connexion par compte

La transition 64-bit time_t

C'est le chantier de fond derrière la suppression ci-dessus. Toutes les architectures sauf i386 utilisent désormais une ABI time_t sur 64 bits, ce qui règle le problème de l'an 2038 (date au-delà de laquelle un compteur de secondes 32 bits déborde).

Ce que ça implique pour vous, très concrètement : sur amd64 et arm64, il n'y a rien à faire, tous les paquets Debian ont été recompilés. Le risque réel se situe sur armhf et armel, avec des binaires tiers non recompilés : ils peuvent provoquer des pertes de données silencieuses. Si vous faites tourner du logiciel propriétaire ou compilé maison sur du matériel ARM 32 bits, c'est le point à traiter en priorité avec l'éditeur.

Le format deb822 devient la recommandation

Debian recommande désormais le format deb822 pour les dépôts APT : un fichier /etc/apt/sources.list.d/debian.sources avec des champs explicites (Types, URIs, Suites, Components, Signed-By), plutôt que le format une-ligne historique de sources.list.

Soyons précis, parce que beaucoup d'articles exagèrent : le format une-ligne est déprécié mais pas supprimé. La page de manuel de Trixie dit qu'il pourrait être retiré à terme, mais pas avant 2029. Vous n'êtes donc pas obligé de migrer vos sources aujourd'hui. C'est une bonne pratique, pas une urgence. Le détail du format et de la gestion des clés est traité dans le guide administrer les paquets avec APT.

Détail de trousseau utile en dépannage : les chemins de clés en .gpg sont maintenant des liens de compatibilité vers les nouveaux fichiers .pgp canoniques. Vos anciens Signed-By continuent donc de fonctionner.

Migrer depuis Debian 12

La montée de version Debian est réputée fiable, et elle l'est, à condition de suivre l'ordre officiel. La plupart des migrations qui tournent mal viennent d'une étape sautée en amont, pas d'un bug de Debian.

Préparer la migration

Ces vérifications ne sont pas décoratives : chacune correspond à un mode d'échec constaté. Consacrez-y le temps nécessaire, c'est là que se joue le succès de l'opération.

Partir d'une Debian 12 complètement à jour. Les sauts de version (12 vers 14, par exemple) ne sont pas pris en charge.
Fenêtre de terminal
```
cat /etc/debian_version     # doit afficher 12.x
sudo apt update && sudo apt upgrade
```
Sauvegarder ce qui compte. En plus de votre sauvegarde système habituelle, Debian demande explicitement /etc, /var/lib/dpkg, /var/lib/apt/extended_states et la liste des paquets sélectionnés.
Fenêtre de terminal
```
dpkg --get-selections '*' > /root/paquets-avant-migration.txt
sudo tar czf /root/etc-avant-migration.tar.gz /etc /var/lib/dpkg /var/lib/apt/extended_states
```
Retirer les backports et l'épinglage. Les dépôts bookworm-backports et proposed-updates doivent sortir des sources, et l'épinglage (pinning) de /etc/apt/preferences* doit être désactivé. Ils fausseraient le calcul de dépendances.
Inventorier ce qui ne vient pas de Debian. Les paquets tiers sont la première cause de migration bloquée, et les paquets obsolètes la première cause de surprise ensuite.
Fenêtre de terminal
```
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt list '?obsolete'
```
Lever les blocages et vérifier l'état de dpkg. Un paquet en hold ou une installation à moitié terminée fait échouer la montée de version.
Fenêtre de terminal
```
sudo dpkg --audit
apt-mark showhold          # lever les blocages éventuels
```
Estimer l'espace disque. Debian ne donne aucun chiffre absolu, il dépend de vos paquets. La seule exigence chiffrée concerne /boot : au moins 768 Mo, dont 300 Mo libres.
Fenêtre de terminal
```
sudo apt -o APT::Get::Trivial-Only=true full-upgrade
df -h /boot /var /
```
Travailler sous screen ou tmux. Une coupure SSH pendant un full-upgrade laisse le système dans un état intermédiaire. Un multiplexeur de terminal permet à la migration de continuer sans vous. Arrêtez aussi les superviseurs qui relancent les services tout seuls : monit est nommément cité par Debian.
Fenêtre de terminal
```
sudo systemctl stop monit    # si présent
tmux new -s migration
```

Trouver vos sources APT : les deux cas

C'est ici que la plupart des tutoriels vous mènent dans le mur. Ils vous disent d'éditer /etc/apt/sources.list et d'y remplacer bookworm par trixie. Sur une Debian 12 récente, ce fichier n'existe pas : les sources sont déjà en deb822 dans /etc/apt/sources.list.d/debian.sources. La commande sed échoue alors avec sed: can't read /etc/apt/sources.list: No such file or directory, et si vous ne lisez pas la sortie, vous croyez avoir basculé les sources alors que rien n'a changé.

Commencez donc toujours par regarder ce que vous avez réellement :

ls -l /etc/apt/sources.list 2>&1
ls -l /etc/apt/sources.list.d/

Sources deb822
Serveur hérité

Sortie observée sur la Debian 12.14 du lab :

ls: cannot access '/etc/apt/sources.list': No such file or directory
---
total 4
-rw-r--r-- 1 root root 443 Jun 23 00:00 debian.sources

Le fichier debian.sources contient des strophes de ce type :

Types: deb
URIs: http://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

La bascule consiste à changer les Suites:, pas le nom du fichier :

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
grep -E 'Suites|URIs' /etc/apt/sources.list.d/debian.sources

Résultat attendu :

URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
URIs: http://deb.debian.org/debian-security
Suites: trixie-security

Si /etc/apt/sources.list existe bien, vous êtes sur un serveur au format une-ligne historique :

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

La bascule s'y fait de la même manière, sur le bon fichier :

sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
grep -v '^#' /etc/apt/sources.list

Attention à un détail de nommage : le dépôt de sécurité de Bookworm s'appelait bookworm-security, celui de Trixie s'appelle trixie-security. Un sed global sur bookworm traite les deux d'un coup.

Une fois les sources basculées, rafraîchissez l'index. La sortie doit mentionner trixie, c'est votre confirmation que la bascule a bien été prise en compte :

sudo apt update

Get:4 http://deb.debian.org/debian trixie/main amd64 Packages [9673 kB]
Get:5 http://deb.debian.org/debian trixie-updates/main amd64 Packages [5412 B]
Get:6 http://deb.debian.org/debian-security trixie-security/main amd64 Packages [225 kB]
Fetched 10.1 MB in 2s (5165 kB/s)

Étape 1 : la mise à niveau minimale

Debian impose deux temps, et le premier n'est pas un apt upgrade nu. Le drapeau --without-new-pkgs est explicite dans les notes de publication : il met à jour les paquets déjà installés sans en installer de nouveaux ni en retirer. Cette étape prudente réduit la taille de la transaction et limite les risques d'un système à moitié migré.

sudo apt upgrade --without-new-pkgs

Étape 2 : full-upgrade

Le second temps est apt full-upgrade (et non dist-upgrade, l'ancien nom encore présent partout sur le web). Cette commande autorise les installations et les retraits de paquets, ce qui est indispensable pour faire aboutir le changement de version.

sudo apt full-upgrade

C'est l'étape longue. Elle pose des questions sur les fichiers de configuration modifiés (dpkg vous demande de garder votre version ou de prendre celle du mainteneur) : dans le doute, gardez votre version et comparez ensuite avec le fichier .dpkg-dist déposé à côté. Si la transaction bute sur un conflit, le guide réparer des dépendances cassées donne la marche à suivre.

À l'issue de l'opération, le lab affichait bien la bascule complète :

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_CODENAME=trixie
debian_version: 13.6

Et les composants avaient sauté de version comme prévu : systemd 252.39 vers 257.13, nginx 1.22.1 vers 1.26.3, APT 2.6 vers 3.0.3. Bonne nouvelle pour les serveurs web : nginx -t restait valide après migration, la configuration n'a pas été cassée par le saut 1.22 vers 1.26.

nginx version: nginx/1.26.3
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Après la migration : nettoyer et moderniser

Une migration laisse des traces. Les paquets obsolètes sont des bibliothèques de Debian 12 qui n'existent plus dans Trixie mais restent installées, faute de quelqu'un pour les retirer. Le lab en comptait 5 :

apt list '?obsolete'

libapt-pkg6.0/now 2.6.1 amd64 [installed,local]
libatm1/now 1:2.5.1-4+b2 amd64 [installed,local]
libperl5.36/now 5.36.0-7+deb12u3 amd64 [installed,local]
libunistring2/now 1.0-2 amd64 [installed,local]
perl-modules-5.36/now 5.36.0-7+deb12u3 all [installed,local]

Ce motif de recherche '?obsolete' fait partie des patterns APT, peu connus et très utiles. Complétez avec apt autoremove, qui proposera de retirer les dépendances devenues inutiles (usr-is-merged et util-linux-extra dans le lab). Relisez la liste avant de valider, autoremove est une commande qui mérite qu'on lui prête attention.

C'est aussi le moment de moderniser vos sources, si vous le souhaitez. APT 3.0 apporte apt modernize-sources, qui convertit le format une-ligne en deb822. Elle n'existe pas en Debian 12 (E: Invalid operation), elle n'est donc utilisable qu'après la migration.

sudo apt modernize-sources

La commande est interactive et demande confirmation. Répondre N donne une simulation, ce qui est le bon réflexe pour un premier passage :

This command supports the 'signed-by' and 'trusted' options. If you
have specified other options inside [] brackets, please transfer them
manually to the output files; see sources.list(5) for a mapping.

For a simulation, respond N in the following prompt.
Rewrite 1 sources? [Y/n] Y
Modernizing /etc/apt/sources.list...
- Writing /etc/apt/sources.list.d/debian.sources

Trois comportements à connaître, observés en lab. Elle écrit une strophe par ligne d'origine (elle ne fusionne pas les suites), elle sauvegarde l'original en .list.bak, et elle déduit Signed-By toute seule. Surtout, elle avertit que les options entre crochets [...] autres que signed-by et trusted ne sont pas transférées : si vos dépôts tiers portent des options comme arch=, reportez-les à la main. Sur des sources déjà en deb822, elle répond simplement All sources are modern.

Le redémarrage

Le redémarrage n'est pas une formalité : c'est lui qui active le nouveau noyau (série 6.12), le tmpfs sur /tmp, et les éventuels nouveaux noms d'interfaces réseau. C'est le moment où les problèmes non anticipés se manifestent, et où l'accès distant peut être perdu.

Avant de taper reboot, repassez sur la section suivante. Assurez-vous d'avoir un accès console (KVM, IPMI, console du fournisseur cloud) : c'est votre seul filet si le réseau ne remonte pas.

sudo reboot

# Après redémarrage, valider l'essentiel
cat /etc/debian_version      # 13.x
uname -r                     # noyau de la série 6.12
findmnt /tmp                 # doit montrer tmpfs
systemctl --failed           # aucun service en échec attendu

Les pièges qui coupent la production

Voici les scénarios qui transforment une migration de routine en incident. Ils ont un point commun : ils se préparent avant le redémarrage, et se réparent très difficilement après, parfois seulement depuis la console physique.

Le nom des interfaces réseau peut changer

C'est le piège le plus brutal : la machine redémarre, tout va bien, mais elle n'a plus de réseau. La cause est un changement de nom d'interface : votre configuration cible enp3s0 alors que le système présente désormais un autre nom, donc l'interface ne se configure pas.

Deux cas sont connus. Le pilote de carte réseau i40e (cartes Intel, très fréquent en serveur), et les firmwares qui exposent l'objet ACPI _SUN : cet objet était ignoré par systemd 252 et il est utilisé par systemd 257, ce qui suffit à changer le nom calculé.

La vérification se fait avant le redémarrage, en demandant à udev de simuler le nommage. Comparez la valeur ID_NET_NAME retournée avec le nom actuel de l'interface :

# Remplacez eth0 par le nom actuel de votre interface (ip -br link)
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Si les noms divergent, la parade est d'épingler les noms actuels avec des fichiers systemd.link, avant de migrer. Le principe et la configuration des interfaces sont détaillés dans la section réseau et le guide NetworkManager.

Le chiffrement de disque

Si votre serveur utilise des systèmes de fichiers chiffrés, le montage automatique au démarrage est désormais assuré par un paquet séparé, systemd-cryptsetup. S'il n'est pas installé, la machine redémarre et ne monte plus les volumes chiffrés, ce qui bloque le démarrage ou fait échouer les services qui en dépendent.

sudo apt install systemd-cryptsetup

Faites-le avant le redémarrage. C'est une ligne de commande qui vous épargne un déplacement en salle machine.

MariaDB : l'arrêt propre est obligatoire

Le saut MariaDB 10.11 vers 11.8 est un changement de version majeure, et la récupération après crash entre versions majeures ne fonctionne pas. Autrement dit : si le serveur MariaDB n'a pas été arrêté proprement avant la migration, il ne redémarrera pas, et vous devrez restaurer depuis une sauvegarde.

La procédure est donc stricte : arrêter le service, puis vérifier dans les journaux que l'arrêt s'est bien terminé avant de lancer le full-upgrade.

sudo service mariadb stop
sudo journalctl -u mariadb -n 20 | grep -i "Shutdown complete"

Ne migrez pas tant que la mention Shutdown complete n'apparaît pas. La lecture des journaux systemd est ici votre garde-fou, pas une option.

OpenSSH n'accepte plus les clés DSA

Trixie livre OpenSSH 10.0p1, qui n'accepte plus les clés DSA. Un compte de service ou un automate qui s'authentifie encore avec une clé DSA sera refusé après la migration, sans préavis. Ces clés sont anciennes et faibles, leur retrait est une bonne nouvelle, mais il faut avoir fait le tour de son parc avant.

ssh-keygen -t ed25519 -C "compte-sauvegarde@srv-prod-01"

Générez et déployez les clés Ed25519 de remplacement avant de migrer, pendant que l'ancienne authentification fonctionne encore.

ping échoue pour les utilisateurs normaux

Symptôme déroutant : après migration, ping fonctionne en root mais échoue pour un utilisateur normal. La cause est le paramètre net.ipv4.ping_group_range, désormais fourni par le paquet linux-sysctl-defaults. C'est un cas particulier du problème sysctl.conf évoqué plus haut, et il se règle de la même manière, dans /etc/sysctl.d/.

RabbitMQ n'a pas de chemin de migration direct

Si vous exploitez RabbitMQ, arrêtez-vous ici : il n'existe pas de chemin de migration direct depuis Bookworm. Par ailleurs, les files HA (mirrored queues) ne sont plus prises en charge, il faut passer aux quorum queues. Cette migration se planifie comme un chantier applicatif à part entière, indépendamment de la montée de version de l'OS.

Le message « System is tainted: unmerged-bin »

Au démarrage, votre serveur migré peut afficher System is tainted: unmerged-bin. La consigne officielle de Debian est claire : ignorez ce message. Ne cédez pas à la tentation de fusionner manuellement /usr/bin et /usr/sbin, cela casserait les mises à niveau suivantes. C'est un avertissement cosmétique, pas un défaut à corriger.

Dépannage

Ce tableau regroupe les symptômes les plus fréquents après une migration vers Trixie. Cherchez-y d'abord avant de partir en investigation : dans la grande majorité des cas, le coupable est un des changements de comportement documentés plus haut, pas un bug.

Symptôme	Cause probable	Solution
`sed: can't read /etc/apt/sources.list`	Sources déjà en deb822	Éditer `/etc/apt/sources.list.d/debian.sources` (champs `Suites:`)
Pas de réseau après reboot	Nom d'interface changé (`i40e`, ACPI `_SUN`)	Accès console, `ip -br link` pour le nouveau nom, puis épingler avec un fichier `systemd.link`
Tuning noyau sans effet	`/etc/sysctl.conf` n'est plus lu	Déplacer les réglages dans `/etc/sysctl.d/99-local.conf`, puis `sudo sysctl --system`
`/tmp` plein alors que le disque est libre	`/tmp` en tmpfs, plafonné à 50 % de la RAM	`systemctl edit tmp.mount` pour agrandir, ou `systemctl mask tmp.mount` pour revenir au disque
Fichiers disparus de `/tmp` après reboot	tmpfs monté par-dessus l'ancien répertoire	`sudo mount --bind / /mnt`, récupérer dans `/mnt/tmp`, puis `sudo umount /mnt`
`last: command not found`	Commande supprimée (incompatible 2038)	`wtmpdb last`, `lastlog2`, `lslogins --failed`
`ping` refusé pour un utilisateur normal	`net.ipv4.ping_group_range` (paquet `linux-sysctl-defaults`)	Régler le paramètre dans `/etc/sysctl.d/`
MariaDB ne redémarre pas	Arrêt non propre avant un saut de version majeure	Restaurer depuis la sauvegarde ; prévenir avec `service mariadb stop` + `Shutdown complete` vérifié
Connexion SSH par clé refusée	Clé DSA, refusée par OpenSSH 10	Générer une clé `ed25519` et la déployer
Volume chiffré non monté	Paquet `systemd-cryptsetup` absent	`apt install systemd-cryptsetup` puis redémarrer
`System is tainted: unmerged-bin`	Répertoires `/usr/bin` et `/usr/sbin` non fusionnés	Ignorer, ne surtout pas fusionner à la main
`apt modernize-sources` : `E: Invalid operation`	Commande d'APT 3.0, absente de Debian 12	L'exécuter seulement après la migration

Anticiper Debian 14 « Forky »

Debian publie ses avertissements de dépréciation une version à l'avance. Traiter ces points dès maintenant, pendant que Trixie les prend encore en charge, vous évitera de les découvrir dans l'urgence lors du prochain saut.

Quatre points concernent directement les serveurs :

sudo-ldap sera retiré. Si votre élévation de privilèges passe par LDAP, migrez vers libnss-sudo. Ne pas le faire, c'est perdre sudo sur toute la flotte au prochain reboot.
lxd n'est plus mis à jour. Le successeur soutenu par Debian est incus, un fork de LXD. Planifiez la bascule de vos conteneurs système.
isc-dhcp est obsolète. Le remplaçant est Kea, du même éditeur (ISC). Si vous exploitez un serveur DHCP, c'est le moment de préparer la conversion de configuration.
GSS-API d'OpenSSH sort des paquets principaux. Si vous vous authentifiez en Kerberos via SSH, installez openssh-server-gssapi dès Trixie.

À retenir

Debian 13 « Trixie » est publiée depuis le 9 août 2025, supportée jusqu'au 9 août 2028, puis en LTS jusqu'au 30 juin 2030.
Une version ponctuelle (13.6) n'est pas une nouvelle version : vos mises à jour quotidiennes vous y amènent déjà.
Sur un serveur, les trois changements qui mordent sont /tmp en tmpfs (50 % de la RAM), /etc/sysctl.conf ignoré (échec silencieux) et la suppression de last/lastlog.
i386 n'est pas supprimé : il perd son noyau et son installateur, mais reste en multiarch. Les machines i386 ne doivent pas être migrées, il faut les réinstaller en amd64.
La migration se fait en deux temps : apt upgrade --without-new-pkgs puis apt full-upgrade. Jamais l'un sans l'autre.
Vérifiez où sont vos sources APT avant tout : sur une Debian 12 récente, /etc/apt/sources.list n'existe plus, tout est en deb822.
Trois précautions avant de redémarrer : OpenSSH à jour, noms d'interfaces vérifiés avec udevadm, systemd-cryptsetup installé si vous chiffrez.
MariaDB exige un arrêt propre confirmé par Shutdown complete dans les journaux : la récupération après crash entre versions majeures ne fonctionne pas.
Le format une-ligne des sources est déprécié mais pas supprimé : rien avant 2029. apt modernize-sources convertit, mais après la migration seulement.

Prochaines étapes

Administrer les paquets avec APT Dépôts deb822, clés GPG, patterns de recherche et dépannage APT en profondeur.

Choisir une distribution serveur Les familles Debian et Red Hat, leurs cycles de vie et le bon choix selon le contexte.

Réparer des dépendances cassées Quand un full-upgrade laisse dpkg dans un état incohérent, la marche à suivre.

Gérer les services systemd systemctl edit, mask, et le fonctionnement des unités sous systemd 257.

Mises à jour de sécurité La routine du quotidien, à distinguer d'une montée de version majeure.

Réseau sous Linux Nommage des interfaces, configuration persistante et diagnostic après migration.