Mettre à jour Ubuntu 24.04 vers 26.04 LTS sur un serveur

Read this article in English

Reconstruire un serveur à partir du code est plus propre que de le mettre à niveau. Mais beaucoup d'équipes ont encore une machine avec des années de tâches cron et une unité systemd oubliée. Pour celles-là, la mise à niveau en place d'une LTS à l'autre reste l'option réaliste. Ce guide décrit cette procédure pour la 26.04 « Resolute Raccoon », à partir de la documentation officielle et des notes de version. Nous avons aussi fait la mise à niveau complète dans un conteneur Ubuntu 24.04.5 jetable le 24 octobre 2026 : les numéros de version ci-dessous sont ceux que nous avons vus, pas des suppositions.

Dernière vérification : 24 octobre 2026, d'après les notes de version d'Ubuntu 26.04, la documentation Ubuntu Server et la liste de diffusion ubuntu-announce.

Peut-on passer d'Ubuntu 24.04 à 26.04 dès maintenant ?

Oui. La mise à niveau directe de la 24.04 LTS vers la 26.04.1 LTS est ouverte depuis le 29 septembre 2026. Ubuntu n'ouvre les mises à niveau d'une LTS à l'autre qu'après la première version intermédiaire (point release). La 26.04.1 est sortie le 27 août 2026, puis Canonical a encore attendu quelques semaines pour rétroporter des correctifs de régressions dans rust-coreutils.

Date	Événement
23 avr. 2026	Sortie d'Ubuntu 26.04 LTS
27 août 2026	Sortie de la 26.04.1. Mise à niveau possible seulement avec do-release-upgrade -d
29 sept. 2026	Mises à niveau depuis la 24.04 LTS ouvertes à tous : do-release-upgrade
mai 2029	Fin de la maintenance de sécurité standard de la 24.04 LTS
mai 2031	Fin de la maintenance standard de la 26.04 LTS (Ubuntu Pro/ESM la prolonge jusqu'à 10 ans)

Rien ne presse donc : la 24.04 est maintenue jusqu'en mai 2029. Les raisons de migrer maintenant sont pratiques : des noyaux et des outils plus récents, et une mise à niveau faite à votre rythme plutôt qu'à la fin du support. Évitez simplement le vendredi après-midi.

Peut-on passer directement de 22.04 à 26.04 ?

Non. Il faut d'abord passer de 22.04 à 24.04, puis de 24.04 à 26.04. Ubuntu ne prend en charge que le passage à la LTS suivante, et les notes de version de la 26.04 le disent clairement : depuis 22.04 ou 25.04, passez d'abord à 24.04 LTS ou 25.10. Chaque saut est une mise à niveau complète, avec son redémarrage et ses vérifications. Enchaîner deux sauts dans la même fenêtre de maintenance est possible, mais nous ne le ferions pas sur une machine importante.

Que vérifier avant la mise à niveau ?

Une sauvegarde ou un snapshot récent, une 24.04 entièrement à jour, assez d'espace disque, cgroup v2, la liste des dépôts tiers et un moyen d'accéder à la machine si SSH ne répond plus. Cinq minutes de vérifications évitent une nuit de restauration.

1. Snapshot ou sauvegarde

Sur une VM ou une instance cloud, prenez un snapshot du disque juste avant de commencer. C'est votre vrai plan de retour, car il n'existe pas de rétrogradation prise en charge. Sur du matériel physique, assurez-vous d'avoir une sauvegarde testée de /etc, des données applicatives et des bases. Pour les bases, un dump logique (pg_dumpall, mysqldump) en plus de la sauvegarde des fichiers vaut le coup.

2. Vérifier que le système tourne en cgroup v2

systemd 259, livré avec la 26.04, a complètement supprimé la prise en charge de cgroup v1. Les notes de version sont explicites : les installations Ubuntu qui tournent en cgroup v1 ne pourront pas être mises à niveau vers la 26.04 LTS. Les conteneurs qui exigent cgroup v1, par exemple des versions d'Ubuntu antérieures à 18.04, ne tourneront pas sur un hôte 26.04.

stat -fc %T /sys/fs/cgroup

cgroup2fs signifie que tout va bien. tmpfs indique une hiérarchie v1 ou hybride, souvent forcée par un paramètre noyau comme systemd.unified_cgroup_hierarchy=0 dans /etc/default/grub. Retirez-le, lancez sudo update-grub, redémarrez et testez vos conteneurs en cgroup v2 avant de continuer.

3. Mettre la 24.04 entièrement à jour

La documentation Ubuntu Server demande un système à jour, mises à jour progressives (phased updates) comprises, car elles peuvent bloquer l'outil de mise à niveau :

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
[ -f /run/reboot-required ] && echo "redémarrer d'abord" || echo "pas de redémarrage nécessaire"

Si un redémarrage est demandé, faites-le maintenant, pas au milieu de la mise à niveau.

4. Vérifier l'espace disque et le réglage Prompt

df -h / /boot
grep -i '^Prompt' /etc/update-manager/release-upgrades

La mise à niveau télécharge plusieurs centaines de mégaoctets sur un serveur minimal, et bien plus sur une machine chargée. Gardez quelques Go libres sur / et de la place sur /boot pour le nouveau noyau. La ligne Prompt doit valoir lts sur un serveur LTS, ce qui est la valeur par défaut en 24.04. Avec never, l'outil ne proposera rien.

5. Lister les dépôts tiers et les paquets bloqués

ls /etc/apt/sources.list.d/
apt-mark showhold

L'outil désactive les dépôts tiers et les PPA pendant la mise à niveau. Il ne supprime pas les logiciels installés depuis ces sources, mais vous devrez réactiver chaque dépôt avec le nouveau nom de code (resolute) ensuite. Les paquets bloqués (hold) peuvent faire échouer le calcul de la mise à niveau. Débloquez-les, ou sachez pourquoi ils le sont.

6. Prévoir un accès si SSH tombe

Gardez sous la main la console du cloud, l'IPMI/iDRAC ou la console de secours de l'hébergeur. Notez aussi qu'OpenSSH 10.2 ne prend plus en charge DSA. Si quelqu'un se connecte encore avec une clé ssh-dss, remplacez-la avant la mise à niveau :

sudo grep -rl 'ssh-dss' /root/.ssh /home/*/.ssh 2>/dev/null

Comment lancer la mise à niveau d'un serveur en SSH ?

Lancez sudo do-release-upgrade depuis votre session SSH et acceptez le démarrage d'un démon SSH supplémentaire sur le port 1022. L'outil se relance lui-même dans GNU screen : une connexion coupée ne l'interrompt pas. Ce second point est peu connu : inutile de démarrer tmux vous-même.

Vérifiez d'abord que la nouvelle version est visible. Voici la sortie réelle sur notre système de test en 24.04.5 :

$ do-release-upgrade -c
Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Puis lancez-la :

sudo do-release-upgrade

Ce qui se passe ensuite, dans l'ordre :

1. Avertissement SSH. L'outil détecte la session SSH, demande s'il doit continuer et propose de démarrer un sshd supplémentaire sur le port 1022, en secours. Acceptez. Si un pare-feu protège le serveur, ouvrez le port 1022 pour votre IP le temps de l'opération.
2. Dépôts tiers désactivés, puis un résumé : nombre de paquets installés, mis à jour et supprimés, et volume à télécharger. Lisez la liste des paquets « no longer supported » : elle indique ce qui ne recevra plus de mises à jour de sécurité.
3. Téléchargement et installation. Comptez de quelques minutes sur une VM minimale à une heure ou plus sur un gros serveur. Notre conteneur minimal a mis environ deux minutes et demie : c'est un minimum, pas une référence.
4. Questions sur les fichiers de configuration pour chaque fichier que vous avez modifié et que le paquet modifie aussi (voir la section suivante).
5. Paquets obsolètes : l'outil propose de supprimer les paquets qui n'existent plus en 26.04. Lisez la liste avant d'accepter.
6. Redémarrage. Le système n'est pas mis à niveau tant qu'il n'a pas redémarré sur le nouveau noyau.

Si la connexion SSH coupe, reconnectez-vous et rattachez-vous à la session screen de l'outil :

sudo screen -list
sudo screen -d -r

Les journaux sont dans /var/log/dist-upgrade/ (main.log, apt.log, apt-term.log, history.log). Gardez-les jusqu'à ce que vous soyez sûr que le serveur va bien.

Peut-on la lancer sans interaction ?

Oui, avec sudo do-release-upgrade -f DistUpgradeViewNonInteractive. C'est ce que nous avons utilisé pour le test en conteneur. Sur un vrai serveur, nous le déconseillons : le mode non interactif tranche à votre place les conflits de fichiers de configuration, et vous perdez la possibilité de relire la liste des suppressions. Réservez-le aux systèmes jetables, et pré-remplissez les choix avec un outil de gestion de configuration si vous mettez à niveau un parc.

Comment répondre aux questions sur les fichiers de configuration ?

Appuyez sur D pour voir le diff. Gardez votre version (N, choix par défaut) pour les fichiers que vous avez personnalisés volontairement, et prenez celle du mainteneur (Y) pour les fichiers que vous n'aviez pas l'intention de modifier. Les deux choix laissent une copie : si vous gardez la vôtre, le nouveau fichier est enregistré en .dpkg-dist. Si vous prenez le nouveau, l'ancien est enregistré en .dpkg-old.

Un choix raisonnable pour les fichiers courants :

Fichier	Choix habituel	Pourquoi
/etc/ssh/sshd_config	Garder le vôtre, puis reporter les nouveautés à la main	Vos réglages d'authentification et de port priment. Mieux : placez vos changements dans /etc/ssh/sshd_config.d/*.conf
/etc/sudoers	Garder le vôtre si vous l'avez modifié, sinon le nouveau	Préférez les fichiers de /etc/sudoers.d/
/etc/default/grub	Garder le vôtre	Paramètres noyau choisis volontairement
/etc/nginx/nginx.conf, /etc/apache2/apache2.conf	Garder le vôtre	Configuration applicative
Fichiers que vous ne reconnaissez pas	Prendre le nouveau	En général une valeur par défaut que personne n'a voulu changer

Après la mise à niveau, repérez ce qu'il reste à fusionner :

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.ucf-dist'

Quels changements de la 26.04 peuvent casser un serveur ?

Les changements les plus susceptibles de toucher un serveur sont sudo-rs, les coreutils en Rust, OpenSSH 10.2, systemd 259 (plus de cgroup v1, dernière version compatible avec les scripts SysV), Python 3.14, ainsi que quelques valeurs par défaut de bases de données et de serveurs web. Voici ce que nous avons vu avant et après sur notre système de test, puis le détail.

Composant	24.04 LTS	26.04 LTS	Points d'attention
Noyau (GA)	6.8	7.0	Modules hors arbre (DKMS) à recompiler
sudo	sudo 1.9.15	sudo-rs (l'original reste dispo en sudo.ws)	Fonctions sudoers inhabituelles, sudo-ldap supprimé
coreutils	GNU 9.4	uutils en Rust (cp, mv, rm restent GNU)	Scripts qui dépendent d'options ou de formats propres à GNU
OpenSSH	9.6p1	10.2p1	DSA supprimé, avertissement si l'échange de clés n'est pas post-quantique
systemd	255	259	Plus de cgroup v1, scripts SysV dépréciés
Python	3.12	3.14	Les virtualenvs créés en 3.12 cassent
APT	2.7 / 2.8	3.1	Nouveau solveur, apt history-list
MySQL	8.0	8.4 LTS	Comptes mysql_native_password verrouillés
PostgreSQL	16	18	Changement de version majeure ; huge pages avec Linux 7.0
PHP	8.3	8.5	Dépréciations, JIT avec mod-php d'Apache
Synchronisation de l'heure	systemd-timesyncd	chrony (nouvelles installations seulement)	Les systèmes mis à niveau gardent timesyncd

sudo devient sudo-rs

sudo est désormais fourni par sudo-rs, une réécriture en Rust. L'original reste disponible sous le nom sudo.ws. Sur notre système mis à niveau, sudo --version affichait sudo-rs 0.2.13-0ubuntu1.2, et /usr/bin/sudo est un lien du système d'alternatives. Ubuntu affirme que le changement « devrait être invisible pour la plupart des utilisateurs ». Testez quand même votre automatisation : become d'Ansible, utilisateurs de déploiement avec des règles NOPASSWD, tout ce qui analyse la sortie de sudo. Le paquet sudo-ldap a été supprimé, donc un sudo basé sur LDAP doit passer par PAM. En cas de problème, et le temps de corriger, vous pouvez revenir en arrière :

sudo update-alternatives --set sudo /usr/bin/sudo.ws         # revenir au sudo d'origine
sudo update-alternatives --set sudo /usr/lib/cargo/bin/sudo  # repasser à sudo-rs

Les coreutils sont en Rust (presque tous)

ls --version affichait sur la machine mise à niveau ls (uutils coreutils) 0.10.0. Ubuntu précise que rust-coreutils « n'est pas encore totalement compatible ». La distribution garde cp, mv et rm en version GNU à cause de bugs ouverts, et les notes de version listent une série de CVE connues. Les outils GNU restent accessibles avec le préfixe gnu (par exemple gnuls). Notre conseil : lancez les tests de vos scripts shell, en particulier ceux qui analysent la sortie de ls, date, stat ou sort. Vous pouvez aussi revenir entièrement aux outils GNU :

sudo apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

OpenSSH 10.2

La prise en charge de DSA a disparu et aucune clé d'hôte DSA n'est plus générée. Le client avertit désormais quand une connexion négocie un échange de clés qui n'est pas post-quantique, et l'algorithme hybride mlkem768x25519-sha256 est disponible par défaut. sshd.service est maintenant un alias de ssh.service : les deux noms fonctionnent avec systemctl. Les victimes habituelles sont les vieux équipements embarqués et les clients qui ne connaissent que des algorithmes anciens. Testez une connexion depuis votre plus vieux bastion avant de fermer la session qui a servi à la mise à niveau.

systemd 259 : fin de cgroup v1, scripts SysV en sursis

Nous avons vu cgroup v1 dans les vérifications. Le second point concerne les vieux logiciels maison : la 26.04 est la dernière version d'Ubuntu qui exécute les scripts d'init System V via la couche de compatibilité de systemd, et systemd 260 l'a déjà supprimée. Si ls /etc/init.d/ ou systemctl list-unit-files --state=generated montre vos propres scripts, prévoyez dès maintenant des fichiers d'unité. Ils cesseront de fonctionner avec la 26.10 et la prochaine LTS.

/tmp est un tmpfs par défaut

La 26.04 utilise l'unité tmp.mount d'origine : /tmp est par défaut un tmpfs en mémoire. Les applications qui écrivent de gros fichiers temporaires (outils de sauvegarde, traitement d'images, certains imports de bases) peuvent manquer d'espace ou de mémoire. Vérifiez après le redémarrage :

findmnt /tmp

Si vous avez besoin d'un /tmp sur disque, masquez l'unité (sudo systemctl mask tmp.mount) et redémarrez, ou indiquez un autre répertoire temporaire à l'application.

Python 3.14 et vos virtualenvs

Le Python système passe de 3.12 à 3.14, et sur notre système de test l'outil a supprimé les paquets python3.12 comme obsolètes. Chaque virtualenv créé avec le Python système de la 24.04 pointe vers un binaire python3.12 qui n'existe plus. Recréez-les après la mise à niveau (python3 -m venv --clear, puis réinstallation depuis votre fichier de verrouillage), ou utilisez pour vos applications un Python que vous gérez vous-même (par exemple avec uv ou dans un conteneur).

Bases de données et serveurs web

• MySQL 8.0 vers 8.4 LTS : les comptes qui utilisent mysql_native_password sont verrouillés par défaut. Avant la mise à niveau, listez-les avec SELECT user, host FROM mysql.user WHERE plugin='mysql_native_password'; et passez-les en caching_sha2_password.
• PostgreSQL 16 vers 18 : c'est une version majeure, le répertoire de données ne se convertit pas tout seul. Avec les paquets d'Ubuntu, l'ancien cluster continue de tourner dans son ancienne version jusqu'à ce que vous le migriez (pg_upgradecluster). Les notes de version signalent aussi une régression de débit avec Linux 7.0 si les huge pages ne sont pas activées (huge_pages = on).
• Apache avec mod-php : l'unité Apache active maintenant MemoryDenyWriteExecute=yes, ce qui casse le JIT PCRE de PHP avec le message « Allocation of JIT memory failed ». Passez à php-fpm (recommandé), ou annulez ce réglage avec systemctl edit apache2.
• OpenLDAP est maintenant compilé avec OpenSSL : une ancienne chaîne de chiffrement GnuTLS comme NORMAL:%COMPAT empêche slapd de démarrer.

Docker et les autres dépôts tiers

Docker Engine prend officiellement en charge Ubuntu 26.04 (Resolute). Comme l'outil désactive les dépôts tiers, réactivez ensuite le dépôt Docker avec le nouveau nom de code. Les instructions actuelles de Docker écrivent un fichier deb822, /etc/apt/sources.list.d/docker.sources, dont la ligne Suites: est lue dans /etc/os-release. Relancer ce bloc sur le système mis à niveau donne resolute. Ensuite, sudo apt update && sudo apt full-upgrade installe la version de Docker pour la 26.04. Faites de même pour chaque dépôt d'éditeur.

Comment vérifier que la mise à niveau a réussi ?

Vérifiez la version et le noyau, cherchez les unités en échec, contrôlez les services importants et réactivez les dépôts tiers. Notre liste après mise à niveau :

cat /etc/os-release | grep PRETTY_NAME       # Ubuntu 26.04.1 LTS
uname -r                                     # un noyau 7.0 après redémarrage
systemctl --failed
journalctl -b -p err --no-pager | tail -50
sudo --version | head -1                     # sudo-rs ...
ss -tlnp                                     # vos services écoutent-ils de nouveau ?
findmnt /tmp
apt-cache policy | grep -o 'http[^ ]*' | sort -u   # quels dépôts sont actifs ?

Testez ensuite l'application depuis l'extérieur, pas depuis le serveur : un contrôle HTTP, une connexion à la base depuis le serveur applicatif, une connexion SSH avec votre clé habituelle. Décidez enfin pour la synchronisation de l'heure. Les systèmes mis à niveau gardent systemd-timesyncd, tandis que les nouvelles installations de la 26.04 utilisent chrony avec NTS. Pour passer à chrony sur un hôte mis à niveau, les notes de version indiquent :

sudo apt-mark auto systemd-timesyncd
sudo apt install chrony

Gardez le snapshot quelques jours. Ne le supprimez qu'une fois que le serveur a traversé son cycle hebdomadaire normal (sauvegardes, tâches cron, rotation des logs).

Que faire si la mise à niveau échoue en cours de route ?

Ne redémarrez pas à l'aveugle un système à moitié mis à niveau. Laissez d'abord dpkg terminer la configuration des paquets, puis corrigez l'erreur précise indiquée par les journaux. Si le système est irrécupérable, restaurez le snapshot. La séquence habituelle :

sudo dpkg --configure -a
sudo apt -f install
sudo apt full-upgrade

La cause se trouve presque toujours dans /var/log/dist-upgrade/main.log ou apt-term.log. Les plus fréquentes sont un /boot plein, un paquet bloqué ou tiers avec une dépendance impossible, ou un script de post-installation qui échoue parce qu'un service n'a pas pu démarrer. Corrigez-la, relancez les commandes ci-dessus et ne redémarrez que lorsque dpkg n'a plus rien à configurer. Il n'existe pas de moyen pris en charge de revenir à la 24.04 sur place : c'est pour cela que le snapshot de l'étape 1 n'est pas optionnel.

Mise à niveau en place ou réinstallation ?

Réinstallez quand le serveur est jetable (construit par Terraform, Ansible, cloud-init ou une chaîne d'images). Mettez à niveau en place quand c'est une machine que vous ne pouvez pas reconstruire rapidement. Une installation neuve de la 26.04 apporte aussi des valeurs par défaut qu'une mise à niveau n'applique pas, comme chrony avec NTS à la place de systemd-timesyncd. Si votre infrastructure est décrite en code, construire une nouvelle image 26.04 et remplacer les instances est en général plus rapide et plus sûr que de se connecter à chaque machine. Pour la même raison, nous ne laissons pas une automatisation, ni un assistant IA, lancer des commandes destructrices en production sans humain dans la boucle. Notre guide du serveur MCP Terraform explique où nous plaçons cette limite. Si le serveur est un nœud Kubernetes qui fait aussi tourner l'ingress-nginx retiré, prévoyez également cette migration : voir migrer d'ingress-nginx vers Gateway API.

FAQ

Pourquoi do-release-upgrade répond-il « No new release found » ?

En général parce que le serveur n'est pas entièrement à jour, que Prompt dans /etc/update-manager/release-upgrades ne vaut pas lts, ou que la vérification a eu lieu avant le 29 septembre 2026, date d'ouverture des mises à niveau depuis la 24.04. Mettez tout à jour, vérifiez le réglage et relancez do-release-upgrade -c.

Faut-il l'option -d ?

Plus maintenant. -d permettait de mettre à niveau entre la sortie de la 26.04.1 (27 août 2026) et l'ouverture générale du 29 septembre 2026. Aujourd'hui, do-release-upgrade sans option propose la 26.04.1 LTS.

Combien de temps dure la mise à niveau ?

Cela dépend du nombre de paquets installés, de la vitesse du disque et du miroir. Notre système de test minimal a terminé en deux minutes et demie environ. Un serveur avec une pile complète prend beaucoup plus longtemps. Réservez une fenêtre de maintenance d'au moins une heure, plus le temps des vérifications.

Est-ce sûr de mettre à niveau en SSH ?

Oui, si vous acceptez le démon SSH supplémentaire sur le port 1022 et gardez un accès console en secours. L'outil tourne dans GNU screen : après une déconnexion, rattachez-vous avec sudo screen -d -r.

Mes conteneurs Docker vont-ils continuer à fonctionner ?

Oui, tant que l'hôte est en cgroup v2 et que vous réactivez ensuite le dépôt Docker pour resolute. Les conteneurs basés sur de très vieilles distributions qui exigent cgroup v1 ne tourneront pas sur un hôte 26.04.

Peut-on revenir au sudo classique ou aux coreutils GNU ?

Oui. Utilisez update-alternatives --set sudo /usr/bin/sudo.ws pour sudo, et installez coreutils-from-gnu (en retirant coreutils-from-uutils) pour les coreutils. Ubuntu ne le recommande pas sur la durée, mais c'est pris en charge en 26.04.

Jusqu'à quand Ubuntu 24.04 reçoit-il des mises à jour de sécurité ?

La maintenance de sécurité standard de la 24.04 LTS se termine en mai 2029, et Ubuntu Pro la prolonge au-delà. Pour la 26.04 LTS, elle court jusqu'en mai 2031.

Sources

• ubuntu-announce : Ubuntu 26.04.1 LTS released (27 août 2026)
• ubuntu-announce : Upgrades from Ubuntu 24.04 LTS to Ubuntu 26.04.1 LTS now enabled (29 sept. 2026)
• Ubuntu : notes de version de la 26.04 LTS, résumé pour les utilisateurs de LTS, changements depuis la 25.10 et problèmes connus
• Documentation Ubuntu Server : How to upgrade your Ubuntu release, sudo-rs
• Ubuntu : cycle de publication et dates de support
• Code source d'ubuntu-release-upgrader : DistUpgradeController.py (port 1022), DistUpgradeMain.py (GNU screen)
• Documentation Docker : Install Docker Engine on Ubuntu
• OpenSSH : notes de version

Comment nous avons testé : image officielle ubuntu:24.04 (24.04.5) entièrement mise à jour, puis do-release-upgrade -c et un do-release-upgrade -f DistUpgradeViewNonInteractive complet vers la 26.04.1 LTS le 24 octobre 2026. Un conteneur n'a ni noyau, ni chargeur d'amorçage, ni vrai démarrage systemd : ce qui concerne le noyau, GRUB et le redémarrage vient de la documentation officielle, pas de notre test.

Image d'en-tête : Illustration générée avec Google Gemini pour DevOpsCompass.