Ubuntu 24.04 vers 26.04 LTS : mettre à niveau un VPS ou un serveur dédié avec do-release-upgrade

Ubuntu 26.04 LTS « Resolute Raccoon » est sortie le 23 avril 2026. Comme à chaque nouvelle version LTS, Canonical n'a pas proposé tout de suite la mise à niveau aux serveurs restés en Ubuntu 24.04 LTS « Noble Numbat » : la règle est d'attendre la première point release. La 26.04.1 est parue le 27 août 2026, et l'équipe de publication d'Ubuntu a officiellement ouvert le chemin de mise à niveau depuis la 24.04 le 29 septembre 2026, le temps de rétroporter des correctifs de régressions de rust-coreutils. Depuis, la commande do-release-upgrade propose Ubuntu 26.04.1 à n'importe quel serveur en 24.04, sans option à forcer.

Ce tutoriel est le pendant de notre guide pour migrer un VPS de Debian 12 vers Debian 13, cette fois pour les VPS Ubuntu et les serveurs dédiés. Il s'adresse à celles et ceux qui administrent un serveur en production (site web, base de données MySQL ou PostgreSQL, panel Pterodactyl, serveur de jeu Minecraft) et veulent passer d'Ubuntu 24.04 à Ubuntu 26.04 sans mauvaise surprise : le calendrier, ce qui change vraiment dans la distribution, l'audit à faire avant, la mise à niveau en SSH avec do-release-upgrade, puis les vérifications et les réparations après le redémarrage.

Sources : notes de version d'Ubuntu 26.04 LTS et leur résumé pour les utilisateurs de la 24.04 LTS, annonce de l'ouverture des mises à niveau (29 septembre 2026), documentation Ubuntu Server sur la mise à niveau de version, cycle de vie des versions d'Ubuntu et index des paquets Ubuntu, consultés le 10 novembre 2026.

Ubuntu 26.04.1 : pourquoi la mise à niveau depuis la 24.04 a ouvert fin septembre

Une point release (version intermédiaire numérotée .1, .2…) n'apporte pas de nouvelles fonctionnalités : c'est une image d'installation rafraîchie qui regroupe tous les correctifs, mises à jour de sécurité et paquets publiés depuis la sortie initiale. Un serveur déjà installé en 26.04 la reçoit par un simple apt full-upgrade. Pour un serveur en 24.04, elle a un autre rôle : la documentation d'Ubuntu Server indique que les mises à niveau d'une LTS vers la LTS suivante ne sont proposées qu'après la première point release. Plusieurs mois de correctifs s'accumulent ainsi avant que les machines de production ne soient invitées à migrer.

Le décalage entre le 27 août et le 29 septembre a une explication publique : dans son annonce de la 26.04.1, Canonical précisait que l'offre automatique de mise à niveau arriverait quelques semaines plus tard, après le rétroportage de correctifs pour des régressions d'une version récente de rust-coreutils, la réécriture en Rust des commandes de base (ls, cat, cp…) adoptée par Ubuntu. C'est un bon indicateur de l'endroit où se trouvent les risques de cette migration.

Faut-il migrer tout de suite ? Non. Ubuntu 24.04 LTS reçoit des correctifs de sécurité standard jusqu'en mai 2029 (et jusqu'en mai 2034 avec l'Expanded Security Maintenance d'Ubuntu Pro). Rien n'oblige à passer en 26.04 cette semaine. En revanche, la mise à niveau est désormais officiellement supportée : c'est le bon moment pour la tester sur une copie du serveur, puis la planifier dans une fenêtre de maintenance, loin d'un événement sur votre serveur de jeu ou d'un pic de trafic.

Ce qui change entre Ubuntu 24.04 et Ubuntu 26.04 pour un serveur

Deux ans séparent les deux LTS. Le tableau ci-dessous compare les composants qui comptent sur un serveur, avec les numéros de version publiés dans les notes de version d'Ubuntu et dans l'index des paquets noble (24.04) et resolute (26.04).

sudo-rs, rust-coreutils, Chrony : les changements qui surprennent les administrateurs

Les montées de version de PHP ou de PostgreSQL sont classiques. Ubuntu 26.04 ajoute des changements plus inhabituels, dans des outils que chaque script d'administration appelle sans y penser.

sudo-rs remplace sudo

sudo-rs, une réimplémentation de sudo en Rust, est le fournisseur sudo par défaut. Le sudo historique est toujours disponible sous le nom sudo.ws. Canonical précise que sudo-rs n'est pas un remplaçant parfait : la journalisation des entrées-sorties et sudoreplay ne sont pas pris en charge, et le paquet sudo-ldap est supprimé (l'authentification LDAP passe désormais par PAM). Si vos règles dans /etc/sudoers.d/ sont simples (un groupe d'administrateurs, un utilisateur de déploiement autorisé à redémarrer un service), vous ne verrez pas la différence. Si elles utilisent des options avancées, testez-les juste après la mise à niveau, avant de fermer votre session root.

rust-coreutils fournit les commandes de base

Les commandes de base viennent désormais de rust-coreutils (projet uutils). Canonical reconnaît qu'elles ne sont pas encore totalement compatibles avec les versions GNU et continue de livrer les versions GNU, accessibles avec le préfixe gnu (par exemple gnuls). En raison de bugs non résolus, cp, mv et rm restent ceux de GNU. Les scripts de sauvegarde, les tâches cron et les scripts de démarrage de serveurs de jeu qui analysent la sortie de ls, date ou sort sont les premiers à tester. En cas de problème, les notes de version donnent la commande pour revenir entièrement aux outils GNU :

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

Chrony et NTS pour l'heure du serveur

Sur les nouvelles installations, Chrony remplace systemd-timesyncd et utilise NTS (Network Time Security, du NTP authentifié et chiffré) vers les serveurs de temps d'Ubuntu. Sur un serveur mis à niveau, vous pouvez basculer vous-même avec sudo apt-mark auto systemd-timesyncd puis sudo apt install chrony. Si votre pare-feu filtre aussi le trafic sortant, NTS a besoin du port TCP 4460 (établissement des clés, RFC 8915) en plus du port UDP 123 de NTP.

Les autres ruptures à connaître

• cgroup v1 supprimé : systemd 259 ne gère plus que cgroup v2. Ubuntu utilise cgroup v2 par défaut depuis longtemps, mais un serveur où quelqu'un a ajouté systemd.unified_cgroup_hierarchy=0 à la ligne de démarrage du noyau (vieux réglage pour d'anciennes versions de Docker ou de LXC) doit être corrigé avant la mise à niveau ;
• scripts System V : Ubuntu 26.04 est la dernière version à accepter les scripts d'init de /etc/init.d/ sans unité systemd native. Ils fonctionnent encore, mais c'est le moment de les convertir en services systemd ;
• apt-key supprimé : les vieux scripts d'installation qui ajoutent une clé de dépôt avec apt-key add échouent. La vérification des signatures passe directement par gpgv ; une clé de dépôt tiers se déclare avec l'option signed-by ;
• OpenSSH 10.2 : la prise en charge des signatures DSA est supprimée et aucune clé d'hôte DSA n'est plus générée. L'échange de clés hybride post-quantique mlkem768x25519-sha256 devient la valeur par défaut ;
• Dracut remplace initramfs-tools comme générateur d'initramfs. initramfs-tools reste pris en charge, et l'on peut basculer de l'un à l'autre si un script personnalisé (déverrouillage de disque chiffré à distance, par exemple) ne fonctionne pas avec Dracut.

Auditer le serveur avant la mise à niveau

Dix minutes d'inventaire évitent la plupart des pannes après la migration. Lancez ces commandes en SSH et notez les résultats : ils serviront de liste de contrôle après le redémarrage.

# Version actuelle et espace disque (comptez plusieurs Go libres)
lsb_release -a
df -h / /boot

# Paquets bloqués, qui empêcheraient la mise à niveau
apt-mark showhold

# Dépôts tiers et PPA (ils seront désactivés pendant la mise à niveau)
ls /etc/apt/sources.list.d/

# Ligne de démarrage du noyau : rien ne doit forcer cgroup v1
cat /proc/cmdline
stat -fc %T /sys/fs/cgroup    # doit afficher cgroup2fs

# Services encore lancés par des scripts System V
ls /run/systemd/generator.late/

# Règles sudo personnalisées
sudo ls /etc/sudoers.d/

Puis, selon ce qui tourne sur le serveur :

# MySQL 8.0 : comptes qui seront verrouillés en 8.4
sudo mysql -e "SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';"

# PHP-FPM : configurations qui pointent vers le socket de PHP 8.3
grep -rn "php8.3" /etc/nginx/ /etc/apache2/ 2>/dev/null

# PostgreSQL : clusters existants
pg_lsclusters

# Python : environnements virtuels à recréer après la mise à niveau
sudo find / -name pyvenv.cfg -not -path "/proc/*" 2>/dev/null

Si la requête MySQL renvoie des comptes, ce sont souvent ceux d'une application web, d'un panel ou d'un serveur de jeu (base de données d'un serveur FiveM, panel Pterodactyl). Notez-les : ils devront changer de méthode d'authentification, faute de quoi l'application perdra l'accès à sa base juste après la migration.

Sauvegarder avant de lancer do-release-upgrade

La documentation d'Ubuntu Server est sans ambiguïté : avant une mise à niveau de version, les données doivent être copiées en lieu sûr pour pouvoir être restaurées en cas de problème. Une fois le téléchargement terminé, l'opération ne peut plus être annulée, et il n'existe aucun chemin officiel pour redescendre de la 26.04 à la 24.04. Le retour arrière, c'est la sauvegarde.

Sur un VPS Ubuntu ElypseCloud, commencez par un snapshot du VPS depuis le Manager : c'est le moyen le plus rapide de revenir à l'état d'avant si la mise à niveau tourne mal. Complétez par des sauvegardes de fichiers copiées hors du serveur :

sudo tar czf /root/etc-$(date +%F).tar.gz /etc
dpkg --get-selections '*' > /root/paquets-$(date +%F).txt
sudo mysqldump --all-databases --single-transaction > /root/mysql-$(date +%F).sql
sudo -u postgres pg_dumpall > /root/postgresql-$(date +%F).sql

N'oubliez pas les données qui ne sont pas dans /etc : dossiers des mondes Minecraft, ressources d'un serveur FiveM, volumes Docker, sites web dans /var/www. Notre guide pour sauvegarder un VPS avec rsync vers un serveur distant détaille la copie hors site, et celui sur les sauvegardes MySQL avec mysqldump couvre les bases de données.

Préparer Ubuntu 24.04 : mises à jour, redémarrage et réglage du Prompt

La mise à niveau part d'une 24.04 entièrement à jour. La documentation officielle recommande d'inclure les phased updates, ces mises à jour qu'Ubuntu distribue progressivement à une fraction des machines pour détecter les régressions, afin qu'aucune ne reste en attente :

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

Si le fichier /run/reboot-required existe, redémarrez avant d'aller plus loin (ls /run/reboot-required pour le vérifier). Assurez-vous ensuite que l'outil de mise à niveau est installé et qu'il cherche bien les versions LTS :

sudo apt install ubuntu-release-upgrader-core
grep Prompt /etc/update-manager/release-upgrades

La ligne doit afficher Prompt=lts. Avec Prompt=never, aucune nouvelle version n'est jamais proposée ; avec Prompt=normal, l'outil vise la version suivante, quelle qu'elle soit. Corrigez le fichier si besoin, puis vérifiez que la 26.04 est bien proposée : l'option -c se contente de chercher une nouvelle version et d'afficher le résultat, sans rien installer.

sudo do-release-upgrade -c

Deux précautions pour une mise à niveau en SSH :

• Travaillez dans tmux ou screen : si la connexion coupe, la mise à niveau continue et vous vous rattachez à la session avec tmux attach ou screen -r ;
• Ouvrez temporairement le port 1022 : lancé en SSH, do-release-upgrade démarre un second démon SSH sur le port 1022 pour faciliter la reprise en cas d'échec, mais il n'ouvre pas le pare-feu lui-même. Avec UFW : sudo ufw allow 1022/tcp (voir notre guide pour ouvrir des ports avec UFW). Vous refermerez ce port après la migration.

Dernier filet de sécurité sur un VPS ElypseCloud : la console s'ouvre directement dans le navigateur depuis le panel, et le mode secours permet de démarrer sur un système de dépannage si le serveur ne répond plus du tout.

Lancer la mise à niveau vers Ubuntu 26.04 avec do-release-upgrade

tmux new -s upgrade
sudo do-release-upgrade

L'outil déroule ensuite plusieurs étapes interactives. Restez devant l'écran : il pose des questions tout au long de l'opération.

1. Avertissement SSH : il signale que la session tourne sous SSH et propose de démarrer le démon SSH de secours sur le port 1022. Acceptez.
2. Dépôts tiers désactivés : les PPA et dépôts d'éditeurs (Docker, nginx.org, dépôts PHP ou Node.js…) sont mis en commentaire. Les logiciels qui en proviennent restent installés, mais la documentation officielle les désigne comme la cause la plus fréquente des problèmes de mise à niveau.
3. Réécriture des sources Ubuntu : noble devient resolute dans les sources d'Ubuntu (/etc/apt/sources.list.d/ubuntu.sources sur une installation 24.04 standard). Contrairement à la migration Debian, vous n'avez rien à éditer à la main.
4. Résumé et téléchargement : nombre de paquets à installer, mettre à jour et supprimer, puis téléchargement. Une fois celui-ci terminé, l'opération ne peut plus être annulée. La documentation prévient que téléchargement et installation peuvent prendre plusieurs heures selon la machine.
5. Fichiers de configuration modifiés : pour chaque fichier que vous avez modifié et dont le paquet livre une nouvelle version, l'outil demande quoi faire. La réponse par défaut conserve votre version. Gardez la vôtre pour /etc/ssh/sshd_config et les fichiers que vous avez personnalisés, et comparez ensuite avec la nouvelle version, que dpkg dépose à côté sous l'extension .dpkg-dist. Certains fichiers, comme celui de GRUB, peuvent nécessiter la version du mainteneur pour démarrer correctement.
6. Suppression des paquets obsolètes : elle est facultative. Si un cluster PostgreSQL 16 tourne sur le serveur, répondez non : postgresql-16 n'existe plus dans Ubuntu 26.04 et ses binaires sont nécessaires pour migrer vos bases vers PostgreSQL 18. Vous ferez le ménage plus tard.
7. Redémarrage : le système n'est pas considéré comme mis à niveau tant que ce redémarrage n'a pas eu lieu.

En cas de problème, le journal principal se trouve dans /var/log/dist-upgrade/main.log, avec les autres journaux de la mise à niveau dans le même répertoire.

Après le redémarrage : vérifier le système

Reconnectez-vous en SSH sur le port habituel, puis contrôlez la version et l'état des services :

lsb_release -a          # Ubuntu 26.04.1 LTS, nom de code resolute
uname -r                # noyau 7.0
systemctl --failed      # aucune unité en échec attendue
sudo sshd -t            # configuration SSH valide
sudo ufw delete allow 1022/tcp

Vérifiez ensuite les nouveaux composants un par un :

# Quel sudo est actif, et vos droits fonctionnent-ils ?
update-alternatives --display sudo
sudo -l

# Quelle implémentation des commandes de base est installée ?
dpkg -l coreutils-from-uutils coreutils-from-gnu

# Quel générateur d'initramfs ?
dpkg -l dracut initramfs-tools

# Heure synchronisée ?
timedatectl

Si une règle sudo ne fonctionne plus et bloque votre exploitation, vous pouvez revenir temporairement au sudo historique avec sudo update-alternatives --set sudo /usr/bin/sudo.ws. Canonical le déconseille : corrigez plutôt la règle, puis repassez sur sudo-rs. Profitez de ce passage pour relire votre configuration SSH avec notre guide pour sécuriser SSH sur un VPS Linux.

Remettre en route les services : dépôts tiers, PHP, bases de données, Docker

Dépôts tiers

Repérez les dépôts désactivés ou encore configurés pour la 24.04 :

grep -rn "noble" /etc/apt/sources.list.d/

Pour chaque dépôt, vérifiez d'abord que l'éditeur publie des paquets pour resolute, puis remplacez noble par resolute, réactivez la source et lancez sudo apt update. Docker, par exemple, liste Ubuntu Resolute 26.04 (LTS) parmi les versions prises en charge par Docker Engine. Pour un dépôt qui ne publie pas encore de paquets 26.04, laissez-le désactivé plutôt que de forcer les paquets de la 24.04.

PHP 8.3 vers PHP 8.5

Ubuntu 26.04 fournit PHP 8.5, avec un service php8.5-fpm qui écoute sur /run/php/php8.5-fpm.sock. Un bloc nginx qui pointe encore vers php8.3-fpm.sock renvoie une erreur 502. Installez les modules dont vos applications ont besoin, puis mettez à jour le serveur web :

sudo apt install php8.5-fpm php8.5-mysql php8.5-curl php8.5-mbstring php8.5-xml
# nginx : remplacer php8.3-fpm.sock par php8.5-fpm.sock, puis
sudo nginx -t && sudo systemctl reload nginx
# Apache avec PHP-FPM
sudo a2disconf php8.3-fpm; sudo a2enconf php8.5-fpm; sudo systemctl reload apache2

Avant de migrer, vérifiez que vos applications (CMS, panel, outils maison) annoncent leur compatibilité avec PHP 8.5. Pour une configuration PHP-FPM propre, voyez notre guide pour installer PHP-FPM de façon sécurisée.

MySQL 8.4 et mysql_native_password

C'est le changement le plus susceptible de couper une application. Avec MySQL 8.4, les comptes qui s'authentifient avec mysql_native_password sont verrouillés par défaut. La solution recommandée par Ubuntu est de passer chaque compte repéré pendant l'audit en caching_sha2_password. Attention : cette commande redéfinit le mot de passe, reprenez exactement celui que l'application utilise.

ALTER USER 'utilisateur'@'hote' IDENTIFIED WITH caching_sha2_password BY 'mot-de-passe';

En dépannage, vous pouvez réactiver l'ancienne méthode en ajoutant mysql_native_password=ON sous [mysqld] dans /etc/mysql/mysql.conf.d/mysqld.cnf. Ubuntu prévient que cette option ne fonctionnera plus avec les futures versions qui livreront MySQL 9.7 ou plus : ne la gardez pas. MariaDB, qui passe de 10.11 à 11.8, n'est pas concerné par ce verrouillage, mais le dump fait avant la migration reste indispensable. Notre guide pour installer MySQL sur un VPS Linux rappelle la gestion des utilisateurs.

PostgreSQL 16 vers PostgreSQL 18

Après la mise à niveau, PostgreSQL 18 est installé, mais vos bases restent dans le cluster 16 tant que vous ne les migrez pas. Les outils postgresql-common d'Ubuntu s'en chargent :

pg_lsclusters
# Si un cluster 18 main vide a été créé, supprimez-le d'abord :
sudo pg_dropcluster 18 main --stop
# Migrer le cluster 16 vers la dernière version installée :
sudo pg_upgradecluster 16 main
# Après vérification des bases dans le cluster 18 :
sudo pg_dropcluster 16 main

Par défaut, pg_upgradecluster procède par dump et restauration. Le nouveau cluster reprend le port d'origine, l'ancien passe sur un port libre en démarrage manuel. Ne supprimez le cluster 16, puis le paquet postgresql-16 avec sudo apt autoremove, qu'après avoir vérifié vos données. Pour la sécurisation des accès, voyez notre guide pour installer PostgreSQL sur un VPS Linux.

Python 3.12 vers Python 3.14

Le paquet python3.12 n'existe plus dans Ubuntu 26.04. Les environnements virtuels créés sous la 24.04 pointent vers un interpréteur disparu et doivent être recréés à partir de leur fichier de dépendances :

rm -rf venv
python3 -m venv venv
./venv/bin/pip install -r requirements.txt

Docker, Pterodactyl et serveurs de jeu

Réactivez le dépôt Docker avec la suite resolute, puis vérifiez que le démon tourne et utilise cgroup v2 :

docker info | grep -i cgroup
docker ps -a

Les images de conteneurs embarquent leur propre système de base : un serveur de jeu conteneurisé sous Pterodactyl ou Docker Compose est peu touché par la mise à niveau de l'hôte, une fois le démon Docker et Wings redémarrés (systemctl status wings). Voir nos guides pour installer Docker sur un VPS et installer un panel Pterodactyl.

Pour un serveur Minecraft installé directement sur l'hôte, attention au Java par défaut : Ubuntu 26.04 passe à OpenJDK 25. C'est ce qu'exige Minecraft 26.x, mais un serveur resté en 1.21.x a besoin de Java 21, qui reste disponible (sudo apt install openjdk-21-jre-headless). Appelez alors le binaire par son chemin complet, /usr/lib/jvm/java-21-openjdk-amd64/bin/java, dans l'unité systemd du serveur. Notre guide Minecraft 26.x et Java 25 détaille la cohabitation des deux versions.

Ubuntu 24.04 vers 26.04 ou Debian 12 vers 13 : ce qui diffère

Si vous administrez un parc mixte, les deux migrations se ressemblent sur le fond (sauvegarde, mise à jour préalable, dépôts tiers, vérifications) mais pas sur la mécanique.

Les deux distributions sont de bons choix pour un serveur ; notre comparatif pour choisir une distribution Linux pour un VPS aide à trancher pour une nouvelle machine.

En résumé : la checklist de migration Ubuntu 24.04 vers 26.04

1. Tester la mise à niveau sur une copie du serveur si l'application est critique.
2. Auditer : comptes MySQL en mysql_native_password, sockets PHP 8.3, clusters PostgreSQL, venv Python, règles sudo, dépôts tiers, ligne de démarrage du noyau.
3. Sauvegarder : snapshot du VPS, puis /etc, bases de données et données applicatives copiées hors du serveur.
4. Mettre la 24.04 entièrement à jour (phased updates compris) et redémarrer si nécessaire.
5. Vérifier Prompt=lts, ouvrir le port 1022, lancer sudo do-release-upgrade dans tmux.
6. Garder vos fichiers de configuration personnalisés, refuser la suppression des paquets obsolètes si PostgreSQL 16 tourne, redémarrer.
7. Vérifier version, noyau, services, SSH, sudo, puis refermer le port 1022.
8. Réparer : dépôts tiers, PHP-FPM 8.5, comptes MySQL, cluster PostgreSQL, venv, Docker et Java des serveurs de jeu.
9. Réactiver les mises à jour de sécurité automatiques et revoir la sécurisation SSH, UFW et Fail2ban du serveur.

Préparée de cette façon, la mise à niveau d'Ubuntu 24.04 vers 26.04 LTS donne un serveur maintenu jusqu'en mai 2031 en support standard, avec un noyau 7.0, OpenSSL 3.5 et OpenSSH 10.2. Rien ne presse tant que la 24.04 est maintenue, mais le chemin est officiellement ouvert depuis le 29 septembre : autant le planifier plutôt que de le subir en 2029.