Ubuntu 26.04.1 : nouveautés et quand mettre à niveau

Ubuntu 26.04.1 en bref

Ubuntu 26.04.1 LTS (support à long terme) est sorti le 27 août 2026, quatre mois après la sortie d’Ubuntu 26.04 LTS, le 23 avril 2026. Il s’agit d’une mise à jour cumulative de la version existante : le même noyau Linux 7.0 et le même ensemble de paquets, avec toutes les mises à jour stables (SRU) et de sécurité publiées jusqu’au 25 août 2026 intégrées aux supports d’installation nouvellement générés. Un serveur 26.04 qui fonctionne apt full-upgrade possède déjà tous ces éléments. Cette version concerne surtout les serveurs 24.04 LTS, car c’est avec la première mise à jour intermédiaire que Canonical ouvre le chemin de mise à niveau depuis la LTS précédente. Au 18 septembre 2026, ce chemin n’est pas encore ouvert, et un fichier texte public indique le jour de son ouverture.

Ce qu’est une version corrective .1

Une version corrective est un instantané. Canonical prend l’archive 26.04 telle qu’elle se présente, avec toutes les mises à jour arrivées dans resolute-updates et resolute-security depuis avril, puis crée de nouvelles images ISO et cloud à partir de cette base. L’annonce de la version le résume en une phrase : « Cette version corrective inclut de nombreuses mises à jour et des supports d’installation mis à jour ont été fournis, afin de réduire le nombre de mises à jour à télécharger après l’installation. » La durée de support ne change pas. Les cinq ans sont toujours comptés à partir d’avril 2026 : 26.04.1 est donc pris en charge jusqu’en avril 2031, exactement comme l’image d’avril. Le fonctionnement général, notamment la raison pour laquelle les versions correctives ultérieures utilisent un kernel plus récent alors que celle-ci n’en utilise pas, est expliqué dans le fonctionnement des versions correctives d’Ubuntu. La suite porte spécifiquement sur 26.04.1.

Ce qui change dans Ubuntu 26.04.1

La liste complète figure sur la page officielle des notes de version de 26.04.1. Elle est longue, et concerne principalement le matériel des ordinateurs de bureau et des portables. Voici les éléments importants pour un serveur.

Kernel : toujours Linux 7.0, pas encore de stack HWE

26.04 LTS est sorti avec Linux 7.0, contre 6.8 dans 24.04. La version .1 reste en 7.0. Les notes listent plusieurs builds linux SRU dans la section du kernel, dont le tracker 7.0.0-15.15. Ainsi, uname -r sur une machine mise à jour affiche un numéro d’ABI (interface binaire d’application) supérieur à celui de l’image d’avril, mais appartient toujours à la même série 7.0. Il n’y a pas de kernel HWE (hardware enablement) dans 26.04.1. La page du cycle de vie du kernel Ubuntu précise le fonctionnement : « .2 et les versions ponctuelles suivantes fournissent un kernel mis à jour » pour le desktop, tandis que « les installations Server utilisent par défaut le kernel GA et proposent le kernel d’activation en option ». GA signifie general availability : c’est le kernel fourni au lancement de la version. Sur un VPS, cela signifie que vous restez en 7.0 pendant toute la durée de vie de la version, sauf si vous choisissez une autre option, et la question de savoir si un serveur doit utiliser le kernel HWE est une décision distincte que vous n’avez pas besoin de prendre aujourd’hui.

Un correctif du kernel mérite d’être mentionné. Le bug 2158267, « Une régression des performances ralentit l’inférence SDXL (environ 42x) », a été corrigé dans le kernel générique et dans la plupart des variantes cloud. Si vous exécutez des charges d’inférence sur 26.04 et qu’elles ont ralenti après une mise à jour du kernel, c’est l’entrée à consulter.

Correctifs pour les serveurs et le cloud

• openssl : une mise à jour de sécurité pour le « problème de déni de service HollowByte » (bug 2161371).
• rsync : « Correctifs de régression de la mise à jour de sécurité de mai 2026 » (bug 2155874). Si rsync ne fonctionnait plus chez vous en mai, le support .1 contient le correctif.
• exim4 : trois mises à jour de sécurité, dont une écriture d’un octet dans un buffer libéré et une divulgation d’informations dans PROXYv2.
• ca-certificates : le bundle d’autorités de certification Mozilla passe à la version 2.86.
• systemd : un délai dans cloud-init, causé par un hook de résolution de systemd-networkd, est corrigé (bug 2148619), et le composant principal n’ouvre désormais son socket netfilter que lorsque c’est nécessaire.
• libvirt et qemu : un correctif pour « l’allocation mémoire excessive lorsque physical_package_id est élevé », ainsi qu’un correctif pour une race condition entre les iothreads et les groupes de limitation.
• apparmor : une nouvelle version upstream, ainsi qu’un correctif de profil pour « les lectures de locales par uucore ». uucore est le code partagé sous rust-coreutils, et ce correctif concerne le même problème que celui qui retarde l’invite de mise à niveau depuis 24.04, présenté plus bas.
• ubuntu-meta : pollinate a été supprimé des seeds cloud-minimal, server, server-minimal et server-raspi, et curl a été ajouté explicitement à cloud-minimal et server-minimal. Ces deux changements s’appliquent au contenu d’une installation fraîche effectuée depuis le support .1.
• debootstrap : « Détecter et prendre en charge SHA512 dans les fichiers d’index Release », ce qui est utile si vous construisez des chroots ou des conteneurs à partir de l’archive 26.04.
• base-files : /etc/os-release indique désormais 26.04.1, et l’ancien bug « LTS absent de VERSION » est corrigé. La chaîne affiche donc 26.04.1 LTS (Resolute Raccoon).

Supports d’installation

Les nouvelles images ISO contiennent quatre correctifs livecd-rootfs. Celui qu’un utilisateur de VPS peut rencontrer est « fix: update nocloud password data format » (bug 2149891). Il concerne les installations unattended qui transmettent un mot de passe via la datasource NoCloud. Les autres définissent les permissions du kernel et de l’initrd à 0644 dans le répertoire casper et corrigent deux options de démarrage riscv64. Chez un provider, vous installez rarement depuis une ISO. En pratique, un template construit à partir de 26.04.1 démarre donc avec les mises à jour de sécurité publiées jusqu’au 25 August 2026 déjà appliquées.

Le release upgrader

Cinq entrées ubuntu-release-upgrader figurent dans .1, et l’une d’elles concerne toutes les machines en 26.04. Le bug 2154602, « data/release-upgrades: set Prompt=lts for resolute », corrige une erreur de la version d’avril : /etc/update-manager/release-upgrades est sorti avec Prompt=normal, le paramètre utilisé pour les versions intermédiaires. La version 1:26.04.22 le définit sur Prompt=lts. Sans ce correctif, un serveur en 26.04 se verrait proposer la version 26.10 en octobre. Les autres entrées concernent des cas particuliers du chemin depuis 24.04 (« mark libfile-libmagic-perl for install on Noble »), un cas particulier pour Raspberry Pi, un nettoyage de lint et une liste de miroirs mise à jour.

Comment un serveur 26.04 atteint 26.04.1

Il n’y a aucune mise à niveau à exécuter. La version intermédiaire correspond à l’état de l’archive, et votre serveur suit cette archive via apt. Deux commandes placent toute installation 26.04 dans le même état que le support .1, ou dans un état plus récent.

sudo apt update
sudo apt full-upgrade

Utilisez full-upgrade plutôt que upgrade. apt upgrade refuse de supprimer quoi que ce soit. Lorsqu’une mise à jour nécessite la suppression d’un ancien paquet, il affiche The following packages have been kept back et conserve l’ancienne version. full-upgrade est autorisé à supprimer des paquets et termine donc l’opération. Vérifiez ensuite la chaîne de version.

grep VERSION= /etc/os-release

Vous devriez voir VERSION="26.04.1 LTS (Resolute Raccoon)". Si la chaîne ne contient toujours pas .1, la mise à jour base-files n’a pas été appliquée. Cela signifie généralement que apt update a échoué auprès de votre miroir. Relisez la sortie de apt update. Sur une image fraîchement fournie par un hébergeur, la cause la plus fréquente est un miroir qui n’est pas encore synchronisé.

Vérifiez ensuite si le kernel a changé.

cat /var/run/reboot-required
uname -r

*** System restart required *** indique qu’un paquet nécessitant un redémarrage a été installé. Sur un serveur, il s’agit presque toujours du kernel. uname -r affiche le kernel actuellement en cours d’exécution. Le nouveau kernel ne sera actif qu’après un redémarrage. Redémarrez donc lorsque vous pouvez prévoir une minute d’interruption. Si la machine ne redémarre pas, un VPS qui ne démarre plus après une mise à jour du kernel démarre presque toujours sur le kernel précédent depuis le menu GRUB. Une fois le nouveau kernel actif, sudo apt autoremove --purge supprime les anciens. La page nettoyer les anciens kernels sur Ubuntu explique lesquels conserver.

Enfin, vérifiez que la correction de l’outil de mise à niveau a bien été appliquée.

grep -v '^#' /etc/update-manager/release-upgrades

Vous devriez voir Prompt=lts. Si vous voyez Prompt=normal, vous ou un script de provisioning avez modifié ce fichier avant .1. dpkg a donc conservé votre copie au lieu d’installer la nouvelle. Remplacez-la manuellement par lts. Cette différence détermine si votre serveur se verra proposer 26.10 le mois prochain ou la prochaine version LTS en 2028. La page pourquoi un serveur doit rester sur les versions LTS en explique la raison.

Pourquoi un serveur 24.04 indique toujours qu’il n’y a aucune mise à niveau disponible

C’est ce qui déroute le plus souvent, car 26.04.1 existe et l’outil de mise à niveau indique malgré tout qu’il n’y a rien à faire. La raison tient à un seul flag dans un fichier texte contrôlé par Canonical.

Sur un serveur 24.04, /etc/update-manager/release-upgrades contient Prompt=lts. Avec ce réglage, do-release-upgrade télécharge https://changelogs.ubuntu.com/meta-release-lts et lit la liste des releases qu’il contient. Pour chaque release plus récente que la vôtre, il vérifie un champ Supported:. Voici la boucle correspondante dans MetaRelease.py de update-manager, sous une forme abrégée :

for dist in dists:
    if dist.date > current_dist.date:
        if not dist.supported and not self.useDevelopmentRelease:
            continue
        upgradable_to = dist
        break

Une release avec Supported: 0 est ignorée comme si elle n’existait pas. Vous pouvez lire le fichier vous-même.

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A4 '^Dist: resolute'

Au 18 septembre 2026, il affiche ceci :

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

La ligne Version indique déjà 26.04.1. Le fichier a donc été mis à jour pour cette point release. Seul le flag Supported vaut encore 0. La boucle ne trouve donc aucune release pouvant faire l’objet d’une mise à niveau, new_dist reste vide et do-release-upgrade affiche le message prévu pour le cas Prompt=lts :

Checking for a new Ubuntu release
There is no development version of an LTS available.
To upgrade to the latest non-LTS development release
set Prompt=normal in /etc/update-manager/release-upgrades.

Il faut comprendre ce message comme « aucune LTS ne vous est encore proposée » et ignorer l’indication concernant Prompt=normal. Si vous le définissez, l’outil de mise à niveau lira à la place la liste des releases intermédiaires et vous proposera 25.10, une release bénéficiant de neuf mois de support. Vous devrez ensuite effectuer une deuxième mise à niveau pour atteindre 26.04. Le message plus court No new release found. correspond à la même condition sur une machine dont le fichier indique déjà Prompt=normal, et que faire lorsque do-release-upgrade ne trouve aucune nouvelle release examine ces deux messages ainsi que leurs autres causes. Un autre message mérite d’être connu. Please install all available updates for your release before upgrading. signifie que des mises à jour sont encore en attente sur 24.04. Dans ce cas, exécutez sudo apt full-upgrade avant de réessayer.

Pourquoi le flag n’a-t-il pas changé ? L’annonce de 26.04.1 indiquait : « Les utilisateurs d’Ubuntu 24.04 LTS se verront proposer une mise à niveau automatique vers 26.04.1 LTS via Update Manager quelques semaines après cette release, après l’intégration de backports prévus pour corriger des régressions dans une version récente de rust-coreutils. » 26.04 est la première LTS dans laquelle ls et les autres utilitaires système principaux proviennent de rust-coreutils au lieu de GNU coreutils. ce que changent les réécritures en Rust dans le système de base d’Ubuntu explique pourquoi une mise à niveau depuis 24.04 est le premier cas où une régression de ces composants apparaît. Canonical attend que ces correctifs soient disponibles dans resolute-updates avant d’activer la notification automatique. Le fichier passera alors à Supported: 1. À partir de ce moment, la bannière de connexion SSH sur 24.04 affichera New release '26.04.1 LTS' available. suivi de Run 'do-release-upgrade' to upgrade to it., et la même commande qui indiquait qu’il n’y avait aucune mise à niveau proposera 26.04.1 sans aucune modification de votre côté.

Si vous ne voulez pas attendre

L’annonce indique également comment contourner ce flag : do-release-upgrade -d. Le texte d’aide du flag indique : « Si vous utilisez la dernière release prise en charge, mettez à niveau vers la release de développement », ce qui semble désigner 26.10, mais ce n’est pas le cas sur une LTS. Avec Prompt=lts, -d effectue deux opérations dans le code ci-dessus. Il ajoute -development à l’URL, afin que l’outil de mise à niveau lise meta-release-lts-development, et définit useDevelopmentRelease, qui constitue la deuxième partie de la condition continue. L’instruction d’ignorer la release dans Supported: 0 ne s’applique plus, et resolute est proposée. Ce fichier répertorie la dernière LTS. Ainsi, -d exécuté sur 24.04 propose 26.04.1 plutôt que 26.10.

sudo do-release-upgrade -d

Le compromis est que vous obtenez 26.04.1 dans l’état actuel des archives, avant l’intégration des backports rust-coreutils attendus par Canonical. Sur un serveur que vous pouvez reconstruire à partir d’un snapshot, c’est un choix raisonnable. Si ce n’est pas possible, attendez le changement du flag. Dans tous les cas, prenez d’abord un snapshot et consultez le guide complet de mise à niveau de 24.04 vers 26.04 pour le fallback sur le port SSH 1022 et la gestion des dépôts tiers. Si la mise à niveau s’interrompt en cours de route, récupérer une mise à niveau de release Ubuntu ayant échoué est la page à garder ouverte.

La décision

Déjà sous 26.04 : aucune action particulière n’est nécessaire. Exécutez sudo apt update && sudo apt full-upgrade et redémarrez si /var/run/reboot-required existe. Vérifiez ensuite Prompt=lts. Vous n’étiez jamais en retard, car la version intermédiaire fait partie du flux de mises à jour que vous utilisiez déjà.

Sous 24.04 : le chemin de mise à niveau est sur le point d’être ouvert, mais il est fermé au 18 septembre 2026. Exécutez la commande curl ci-dessus une fois par semaine. Lorsque Supported: renvoie 1, planifiez la mise à niveau après avoir créé un snapshot. Si vous voulez passer à 26.04 avant cette date, do-release-upgrade -d vous donne 26.04.1 dès aujourd’hui, avec la réserve indiquée plus haut. 24.04 LTS est pris en charge jusqu’en avril 2029. Attendre encore quelques semaines l’activation du signal ne vous coûte donc rien.

Sur 22.04 ou une version intermédiaire, les notes de version précisent que « vous devez d’abord effectuer la mise à niveau vers Ubuntu 24.04 LTS ou 25.10 avant de pouvoir passer à 26.04 LTS ». Passez d’abord à 24.04, puis suivez la procédure prévue pour 24.04 ci-dessus. Pour un serveur en 22.04, le parcours en deux étapes de 22.04 vers 26.04 via 24.04 couvre les vérifications et l’instantané à effectuer entre les deux étapes, ainsi que les problèmes prévisibles liés aux PPA, à PHP, à Python, aux bases de données et à netplan.

FAQ

Ubuntu 26.04.1 est-elle une nouvelle version que je dois installer ?

Non. Ubuntu 26.04.1 LTS, publiée le 27 août 2026, correspond à l’archive 26.04 avec quatre mois de mises à jour intégrés aux nouveaux supports d’installation. Un serveur 26.04 qui exécute sudo apt update && sudo apt full-upgrade est déjà au niveau .1 ou à un niveau ultérieur, et grep VERSION= /etc/os-release affiche 26.04.1 LTS (Resolute Raccoon) une fois la mise à jour base-files appliquée. La prise en charge prend toujours fin en avril 2031, à compter de la publication d’avril 2026.

Pourquoi do-release-upgrade sur 24.04 indique-t-il qu’aucune version de développement d’une LTS n’est disponible ?

Parce que Prompt=lts fait lire meta-release-lts à l’outil de mise à niveau, et que ce fichier répertorie 26.04.1 avec Supported: 0. L’outil ignore les entrées non prises en charge, ne trouve rien de plus récent et affiche le message prévu pour le cas Prompt=lts. Canonical bascule l’indicateur sur Supported: 1 lorsque le chemin de mise à niveau est ouvert, et l’annonce de 26.04.1 associait cette ouverture aux backports corrigeant les régressions de rust-coreutils. Ne définissez pas Prompt=normal : cette option propose 25.10, une version intermédiaire.

26.04.1 inclut-elle un nouveau kernel ?

Non. 26.04.1 reste sur la série Linux 7.0 fournie avec 26.04 LTS, mise à jour par plusieurs builds SRU. Le premier kernel HWE arrive avec une version ultérieure, .2 selon le schéma habituel d’Ubuntu, et les installations serveur utilisent par défaut le kernel GA même dans ce cas. Un VPS sous 26.04 conserve le kernel 7.0, sauf si vous activez vous-même la pile HWE.

Dois-je utiliser do-release-upgrade -d pour passer de 24.04 à la nouvelle version dès maintenant ?

L’annonce le propose à ceux qui ne veulent pas attendre. -d avec Prompt=lts lit la liste de développement des LTS et ignore l’indicateur Supported: 0 ; il propose donc 26.04.1 plutôt que 26.10. Vous obtenez l’archive dans son état actuel, avant les backports de rust-coreutils attendus par Canonical. Créez d’abord un snapshot. Utilisez cette méthode sur un serveur que vous pouvez reconstruire, et attendez l’activation de l’indicateur sur un serveur que vous ne pouvez pas reconstruire.