Ubuntu : corriger « aucune nouvelle version trouvée »

Pourquoi do-release-upgrade indique qu’aucune nouvelle version n’a été trouvée

do-release-upgrade se terminant par No new release found. n’indique presque jamais un outil défectueux. Le chemin demandé est fermé à ce moment-là, et l’outil le signale de la manière la plus concise possible. Cinq éléments peuvent le fermer : le paramètre Prompt dans /etc/update-manager/release-upgrades, le verrou de version intermédiaire lors des mises à niveau LTS (long term support), les dépôts tiers, les paquets bloqués ou partiellement configurés, et une version qui a dépassé sa fin de support.

Vérifiez-les dans cet ordre. Pour chaque élément, une commande permet de confirmer s’il concerne votre serveur. Vous n’avez donc jamais à deviner lequel des cinq problèmes se présente.

Ce que signale réellement l’option de vérification seule

sudo do-release-upgrade -c
echo $?

-c effectue uniquement une vérification. Il lit les métadonnées de version de Canonical via HTTPS (hypertext transfer protocol secure) et affiche le résultat. Il ne télécharge aucun outil de mise à niveau et ne réécrit aucun fichier de sources. Deux résultats sont importants :

Checking for a new Ubuntu release
No new release found.

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

Le code de sortie fournit le même résultat aux scripts. Il vaut 0 lorsqu’une version est disponible et 1 lorsqu’il n’y en a aucune. C’est l’inverse de la convention habituelle du shell. Vérifiez donc attentivement ce point avant de construire une vérification autour de cette commande.

Si votre bannière de connexion affiche encore l’ancien résultat, celui-ci est mis en cache. Cette ligne provient de /etc/update-motd.d/91-release-upgrade, qui affiche un résultat enregistré au lieu d’interroger le réseau. Actualisez-le avec sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, ou fiez-vous simplement à -c. La bannière répète uniquement le résultat de la dernière vérification exécutée.

La vérification doit également pouvoir joindre changelogs.ubuntu.com. Sur un serveur placé derrière un pare-feu sortant strict ou un proxy que l’outil ne peut pas interroger, celui-ci ne peut rien détecter.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Une ligne HTTP/2 200 signifie que le serveur peut accéder aux métadonnées. Une ligne curl: (28) Connection timed out signifie que vos règles de sortie sont la véritable cause du problème. Modifier les fichiers APT (advanced package tool) ne changera pas le résultat.

Si la commande est complètement absente, elle se trouve dans ubuntu-release-upgrader-core. Les images cloud minimales omettent parfois ce paquet.

sudo apt install ubuntu-release-upgrader-core

Lire /etc/update-manager/release-upgrades avant toute modification

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Le fichier contient sa propre documentation sous forme de commentaires. Trois valeurs sont valides :

• never : ne jamais rechercher ni autoriser une mise à niveau vers une nouvelle release.
• normal : proposer la release supportée qui suit immédiatement la release en cours d’exécution.
• lts : proposer la première release LTS qui suit la release en cours d’exécution.

Prompt=never est la valeur la plus facile à diagnostiquer, car l’outil indique à la fois le fichier et le paramètre dans sa sortie :

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Les hébergeurs et les outils de gestion de configuration définissent délibérément never pour empêcher un parc de dériver entre plusieurs releases. Si vous trouvez cette valeur, c’est un choix explicite. Remplacez-la par lts sur un serveur que vous voulez maintenir sur la branche de support à long terme, puis restaurez-la ensuite si votre automatisation attend l’ancienne valeur.

Un détail de ces commentaires prend souvent les administrateurs au dépourvu. Lorsque Prompt=lts est défini et que la release en cours n’est pas elle-même une release LTS, l’outil de mise à niveau considère ce paramètre comme normal. Sur une machine en 25.10, les deux valeurs se comportent de la même manière. Sur une machine en 24.04, ce n’est pas le cas. C’est toute la différence abordée dans la section suivante.

Pourquoi une mise à niveau LTS vers LTS attend la première version intermédiaire

Prompt détermine le fichier de métadonnées que lit l’outil de mise à niveau. Les adresses se trouvent dans /etc/update-manager/meta-release :

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts lit meta-release-lts. Prompt=normal lit meta-release. Les deux fichiers décrivent chaque version dans un petit bloc de clés. L’outil de mise à niveau ne propose une version que lorsque son indicateur Supported: vaut 1. Vous pouvez les consulter directement depuis le même serveur :

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Vérification effectuée le 13 août 2026 : les deux fichiers ne donnent pas la même information pour Ubuntu 26.04. Le fichier LTS indique :

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

Le fichier standard indique :

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Cette valeur Supported: 0 dans le fichier LTS est le verrou. Un serveur 24.04 utilisant la valeur par défaut Prompt=lts lit ce fichier, ne trouve aucune version LTS plus récente marquée comme disponible et affiche No new release found. Rien ne fonctionne mal sur votre machine. Canonical n’a pas encore ouvert cette voie.

L’indicateur passe à 1 lorsque la première version intermédiaire est publiée. Ubuntu 26.04.1 est prévue pour le 27 août 2026, mais le calendrier des versions peut changer : vérifiez donc les métadonnées plutôt qu’une date de calendrier. Une version intermédiaire n’est pas une nouvelle version d’Ubuntu. C’est la même version, avec toutes les mises à jour publiées depuis son lancement intégrées à un nouveau support d’installation. Pour un serveur en fonctionnement, l’important est donc le mécanisme qu’elle active, et non le support lui-même. Ce délai est volontaire : les utilisateurs qui effectuent la mise à niveau tôt identifient les blocages, qui sont ensuite corrigés avant que la population beaucoup plus importante de serveurs LTS ne suive. Si cette date est passée lorsque vous lirez ce texte, le contenu de la version 26.04.1 et ses conséquences pour un serveur 24.04 poursuit cette explication.

Il reste donc deux options réalistes. Attendre la point release, ce qui est le bon choix pour tout serveur que vous préférez ne pas surveiller. Ou définir Prompt=normal, qui demande au même outil de cibler meta-release, où 26.04 est déjà indiqué comme pris en charge. Cette seconde méthode vous fait passer à la version 26.04 publiée, et non à une version de développement. Elle peut donc se justifier sur une machine que vous pouvez restaurer depuis un snapshot. Rétablissez la valeur lts une fois l’opération terminée. La procédure détaillée, étape par étape, se trouve dans le guide complet de mise à niveau d’un serveur de 24.04 vers 26.04. Un serveur qui utilise encore 22.04 doit effectuer une étape supplémentaire, car Prompt=lts ne propose que la prochaine version LTS. Ainsi, le passage de 22.04 à 26.04 se fait d’abord par 24.04.

Les dépôts tiers et les PPA qui bloquent la mise à niveau

Le programme de mise à niveau réécrit vos sources APT pour les faire pointer vers la nouvelle version. Il ne peut le faire que pour un dépôt qui publie des paquets pour cette nouvelle version. Tous les autres dépôts sont donc commentés. Les raisons sont affichées sur une ligne par entrée et sont explicites : was disabled (unknown mirror), was disabled (unknown dist) et was disabled (no Release file).

Un PPA compilé pour noble ne possède aucun répertoire pour resolute sur le serveur. Le programme de mise à niveau ne peut donc pas récupérer de fichier Release pour la nouvelle série et désactive l’entrée. Il s’agit généralement d’un avertissement que vous pouvez accepter. La situation devient bloquante lorsqu’un dépôt tiers fournit un paquet également fourni par la nouvelle version, car le calcul de mise à niveau dispose alors de deux candidats et ne peut pas satisfaire les deux contraintes.

Prenez cette décision vous-même avant de commencer, plutôt que de laisser l’outil la prendre pendant une longue exécution sans surveillance.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy appliqué à un nom de paquet affiche le dépôt d’origine de chaque version installée. Vous pouvez ainsi voir précisément quels paquets dépendent de la source que vous vous apprêtez à désactiver. La suppression de la source ne rétrograde aucun paquet. Un paquet installé depuis un PPA conserve donc sa version issue du PPA et peut être plus récent que la version fournie par la nouvelle release. Si nécessaire, supprimez également le paquet, puis réinstallez-le depuis l’archive après la mise à niveau. Pour un dépôt que vous prévoyez de réactiver, comme celui de Tailscale, vous devez mettre à jour son codename vers la nouvelle version avant de pouvoir réinstaller le paquet. C’est la cause de la plupart des erreurs d’installation de Tailscale sur Ubuntu.

Il existe un flag pour faire le choix inverse. La page de manuel décrit --allow-third-party ainsi : « Try the upgrade with third party mirrors and repositories enabled instead of commenting them out. » Utilisez-le uniquement après avoir vérifié que le dépôt publie déjà des paquets pour la version cible. Dans le cas contraire, vous demandez à APT de résoudre un graphe de dépendances pour une série que ce dépôt n’a jamais compilée.

Sur Ubuntu 24.04 et les versions ultérieures, la plupart des sources se trouvent dans /etc/apt/sources.list.d/ubuntu.sources au format deb822. Un même dépôt écrit à la fois dans l’ancien et dans le nouveau format constitue une erreur distincte, avec son propre message. Elle est traitée dans l’erreur d’entrée de source dupliquée au format deb822.

Les paquets conservés et à moitié configurés bloquent le calcul

Une mise à niveau de version doit déplacer presque tous les paquets du système. Si un paquet ne peut pas être mis à niveau, le calcul échoue. Le programme de mise à niveau préfère s’arrêter rapidement plutôt que de vous laisser avec un système à moitié mis à niveau. Deux commandes permettent d’en trouver la cause.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold affiche les paquets conservés, un par ligne, et n’affiche rien sur un système sain. Une conservation est une instruction manuelle qui interdit toute modification de ce paquet. Quelqu’un a peut-être bloqué un noyau ou une version de base de données, puis l’a oublié. Libérez les paquets dont vous n’avez plus besoin avec sudo apt-mark unhold suivi du nom du paquet.

dpkg --audit liste les paquets décompressés mais jamais configurés. Cet état résulte d’une installation interrompue, le plus souvent à cause d’une session interrompue. Le programme de mise à niveau essaie de corriger le problème et affiche dpkg interrupted, calling dpkg --configure -a, mais lancer vous-même la réparation permet de lire l’erreur au lieu de la voir défiler. Lorsqu’un paquet ne peut pas être réparé par l’outil, le message Package in inconsistent state s’affiche. Ce paquet doit être traité avant une nouvelle tentative.

Mettez la version actuellement utilisée à jour avant de la mettre à niveau.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

L’option relative aux mises à jour déployées progressivement est plus importante qu’il n’y paraît. Ubuntu déploie certaines mises à jour sur un pourcentage de machines à la fois. Une commande apt upgrade simple peut donc laisser correctement certains paquets en attente, et le serveur est alors moins à jour que vous ne le pensez. Cette option les installe tous. Redémarrez ensuite si un noyau a été installé avec ces mises à jour, afin d’effectuer la mise à niveau depuis le noyau que vous utilisez réellement. Un serveur qui installe déjà automatiquement ses correctifs grâce aux mises à niveau de sécurité sans surveillance a moins de travail à faire ici, même si ce mécanisme ne franchit volontairement jamais une limite de version.

Lorsque la version dépasse la fin du support standard

Une version intermédiaire d’Ubuntu est prise en charge pendant neuf mois. À la fin de cette période, son indicateur Supported: passe à 0, et la procédure normale ne permet plus de la mettre à niveau. Vérifié le 13 août 2026, meta-release indique ceci pour 25.10 :

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

L’archive est également déplacée. Les paquets d’une version en fin de vie sont supprimés de archive.ubuntu.com et conservés dans old-releases.ubuntu.com. Ainsi, apt update commence à renvoyer 404 Not Found, le système ne peut plus être mis à jour, et comme l’outil de mise à niveau exige un système à jour, rien ne peut continuer. Corrigez d’abord les sources.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Pointez à la fois archive.ubuntu.com et security.ubuntu.com vers old-releases.ubuntu.com, sans modifier votre nom de code. Seul le nom d’hôte change.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Exécutez plutôt la même commande sur /etc/apt/sources.list si votre serveur conserve encore ses sources dans ce fichier unique. L’option -i.bak crée une sauvegarde à côté du fichier original. Vous pouvez ainsi le restaurer si la modification a ciblé le mauvais fichier. Un apt update sans erreur indique ensuite que l’archive est de nouveau accessible, et do-release-upgrade pourra maintenant communiquer avec elle.

Ne surestimez pas le résultat. Ubuntu ne prend en charge qu’une seule étape de version à la fois. Un serveur qui a deux ou trois versions obsolètes de retard doit donc effectuer chaque étape successivement. Chaque étape peut échouer à cause de son propre dépôt tiers ou de son propre paquet bloqué. Sur un VPS, il est souvent plus rapide de créer un nouveau serveur avec la LTS actuelle, d’y transférer le service et de conserver l’ancien jusqu’à ce que vous ayez vérifié que tout fonctionne. Vous disposez ainsi également d’un rollback, ce qu’une mise à niveau sur place ne permet jamais. Si vous devez ensuite choisir la branche à utiliser, la différence entre les versions LTS et intermédiaires sur un serveur mérite d’être consultée avant de prendre votre décision.

Ce que fait réellement l’option de mise à niveau vers la version de développement

-d ou --devel-release demande au programme de mise à niveau de lire meta-release-development au lieu du fichier sélectionné par Prompt. La page de manuel la décrit ainsi : « Si la dernière version prise en charge est utilisée, effectuer la mise à niveau vers la version de développement. »

Vérifié le 13 août 2026, l’entrée la plus récente de ce fichier n’est pas 26.04 :

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Ainsi, -d ne fournit pas la version publiée 26.04 à un serveur 24.04. Cette option vise 26.10, une version encore en cours de préparation. Les anciens conseils recommandant d’« ajouter simplement -d » concernaient la période précédant la publication d’une LTS. Les appliquer maintenant dirige votre serveur vers une version que vous n’aviez pas l’intention d’utiliser. Si Prompt=lts est toujours présent, l’option s’arrête avec son propre message :

There is no development version of an LTS available.

La documentation Ubuntu destinée aux serveurs est claire au sujet de cette option : « l’utilisation de la version de développement (ou de l’option -d) n’est pas recommandée dans les environnements de production ». Une version de développement évolue chaque jour et ne bénéficie d’aucune garantie de support de sécurité. Un paquet fonctionnel le matin peut donc interrompre un service l’après-midi. Utilisez-la sur une machine virtuelle de test créée pour vérifier votre propre configuration. Ne l’utilisez pas sur un serveur dont dépendent d’autres utilisateurs. Si vous voulez utiliser 26.04 avant l’ouverture de la période LTS, Prompt=normal est la méthode correcte.

Effectuez la mise à niveau dans une session qu’une déconnexion SSH ne peut pas interrompre

Une mise à niveau de version remplace la majeure partie du système, notamment openssh-server et systemd. Si votre session SSH (secure shell) se coupe pendant que dpkg travaille, le processus est tué alors que certains paquets sont décompressés mais pas configurés. C’est précisément l’état qui empêche votre tentative suivante d’aboutir. Si cela vous est déjà arrivé, récupérer une mise à niveau interrompue à mi-parcours est une tâche distincte. Elle doit être effectuée avant toute nouvelle tentative. Lancez toujours la mise à niveau dans un terminal multiplexer.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Si la connexion est interrompue, reconnectez-vous et exécutez tmux attach -t upgrade. La mise à niveau a continué, car elle est un processus enfant du serveur tmux et non de votre session SSH. screen -S upgrade et screen -r upgrade fournissent la même fonction si vous préférez screen.

Le programme de mise à niveau intègre un mécanisme de sécurité pour les utilisateurs qui n’emploient pas de multiplexeur. Lorsqu’il détecte qu’il s’exécute sur SSH, il propose de démarrer un second sshd sur le port 1022. Ainsi, une session principale interrompue laisse tout de même un moyen de se connecter. Pour prendre cette décision, il parcourt ses propres processus parents à la recherche d’un processus nommé sshd. Dans tmux ou screen, ce parcours trouve à la place le serveur du multiplexeur. La proposition n’apparaît donc jamais, et le fichier PID /var/run/release-upgrader-sshd.pid n’est écrit que lorsque le daemon supplémentaire démarre réellement. Si l’invite n’apparaît pas, tout est normal. Vous bénéficiez déjà d’une meilleure protection.

Si vous acceptez la proposition, le port n’est pas ouvert automatiquement. L’outil l’indique clairement, car l’ouverture d’un port est une décision de sécurité qu’il ne peut pas prendre à votre place. Ouvrez-le pendant la durée de la mise à niveau, puis refermez-le.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

La plupart des fournisseurs de VPS exécutent un second firewall dans leur panneau de contrôle, en dehors du système d’exploitation. Le port 1022 doit également y être ouvert. Sinon, le listener de secours fonctionne, mais reste inaccessible. C’est la pire situation possible.

Quatre éléments doivent être prêts avant d’exécuter la commande :

• Créez un snapshot ou une sauvegarde complète. Une mise à niveau de version sur place ne peut pas être annulée. C’est votre seule possibilité de retour.
• Vérifiez que vous pouvez ouvrir la console de votre fournisseur avant d’en avoir besoin. Si le serveur ne redémarre pas correctement, vous n’aurez précisément plus accès à SSH. Un kernel qui ne démarre pas est un problème distinct, avec ses propres étapes de récupération, décrites dans un VPS qui ne démarre plus après une mise à jour du kernel.
• Vérifiez l’espace libre avec df -h / /boot. La mise à niveau télécharge un jeu complet de paquets, et une partition /boot contenant plusieurs anciens kernels est un emplacement fréquent de blocage.
• Lisez les notes de version des services que vous utilisez. Le passage à une version majeure de PostgreSQL ou de PHP arrive avec la nouvelle version, que vous l’ayez prévu ou non.

FAQ

Pourquoi do-release-upgrade indique-t-il qu’aucune nouvelle release n’est disponible sur Ubuntu 24.04 ?

La valeur par défaut de Prompt=lts dans /etc/update-manager/release-upgrades fait lire https://changelogs.ubuntu.com/meta-release-lts par l’outil, et Ubuntu 26.04 conserve Supported: 0 dans ce fichier jusqu’à sa première point release. L’outil de mise à niveau ne trouve donc aucune release LTS plus récente marquée comme disponible et s’arrête. Vérifiez vous-même le fichier avec curl -s https://changelogs.ubuntu.com/meta-release-lts, puis lisez le dernier bloc. Lors de la vérification du 13 août 2026, le flag était toujours 0, et Ubuntu 26.04.1 était planifié pour le 27 août 2026.

Est-il sûr de définir Prompt=normal au lieu d’attendre la point release ?

La mise à niveau vous fait passer à la version 26.04 publiée, et non à une version de développement, car Prompt=normal lit meta-release, où 26.04 porte déjà Supported: 1. Le risque concerne le moment choisi. Vous effectuez la mise à niveau avant que les problèmes rencontrés par les premiers utilisateurs aient été corrigés. Faites-le sur un serveur que vous pouvez restaurer depuis un snapshot et dont la console du fournisseur reste accessible si le reboot échoue. Rétablissez ensuite la valeur lts.

Le flag -d me fait-il passer à 26.04 ?

Non. -d lit meta-release-development, dont l’entrée la plus récente au 13 août 2026 était Ubuntu 26.10, une release encore en développement. Sur une machine LTS avec Prompt=lts, le flag affiche There is no development version of an LTS available., puis s’arrête. La documentation officielle d’Ubuntu pour les serveurs indique que la release de développement n’est pas recommandée en production. Utilisez donc Prompt=normal si vous voulez installer rapidement une version 26.04 publiée.

apt update renvoie des erreurs 404 sur une ancienne release. Comment la mettre à niveau ?

Cette release est arrivée en fin de vie. Ses paquets ont donc été déplacés de archive.ubuntu.com vers old-releases.ubuntu.com. Modifiez uniquement les noms d’hôte dans /etc/apt/sources.list.d/ubuntu.sources, ou dans /etc/apt/sources.list pour les anciennes structures, et conservez votre codename. Exécutez ensuite sudo apt update, puis sudo apt full-upgrade. Une fois le système à jour, do-release-upgrade peut le faire progresser d’une release à la fois.

Dois-je supprimer mes PPA avant d’exécuter do-release-upgrade ?

Ce n’est pas obligatoire, car l’outil de mise à niveau commente toute source qui ne publie pas de paquets pour la nouvelle release et affiche une ligne telle que was disabled (no Release file) pour chacune d’elles. Il est toutefois préférable de le faire vous-même au préalable. Vous contrôlez ainsi l’ordre des opérations et vous voyez le résultat. Exécutez apt policy sur les paquets concernés pour déterminer ceux qui proviennent de chaque PPA, puis réinstallez-les depuis l’archive si la nouvelle release ne fournit pas une version aussi récente que celle du PPA.