Ubuntu 24.04 → 26.04 sur serveur

Le jeudi 27 août 2026, Canonical publie Ubuntu 26.04.1, et avec elle la voie de mise à niveau LTS vers LTS depuis la 24.04 s’ouvre pour tout le monde.^[schedule] Tous les guides publiés cette semaine-là dérouleront do-release-upgrade et s’arrêteront là. Cette commande n’est pas la partie difficile. La partie difficile, c’est qu’entre Noble Numbat et Resolute Raccoon, Ubuntu a remplacé six briques du système de base dont votre automatisation dépend sans le dire, ajouté deux conditions dans lesquelles l’outil de migration refuse purement et simplement de s’exécuter, et livré deux régressions serveur connues, documentées mais presque jamais mentionnées.

Voici la checklist que j’utilise sur de vraies machines. Elle est écrite pour ceux qui exploitent Ubuntu en serveur : pas de bureau, pas de GNOME, pas de magasin de snaps. Tout ce qui est affirmé ici vient des notes de version de Canonical et des projets amont, et là où les notes officielles ne donnent pas de numéro de version — OpenSSL est le cas intéressant — je n’en ai pas inventé. Les commandes sont en lecture seule, sauf quand le commentaire dit le contraire.

Pourquoi le 27 août est la date qui compte

Ubuntu ne vous propose pas la LTS suivante le jour de sa sortie. Il attend la première version de maintenance de cette LTS, qui arrive environ quatre mois plus tard et absorbe le pire des régressions initiales. Pour la 26.04, cette version de maintenance est la 26.04.1, le 27 août 2026. D’ici là, un serveur 24.04 avec la politique standard Prompt=lts vous répondra, à juste titre, qu’il n’y a rien vers quoi migrer — ce n’est pas un bogue, et ce n’est pas quelque chose à contourner.^{[schedule][upgradedoc]}

# Ubuntu does NOT offer one LTS to the next until the first point release.
# For 26.04 that is 26.04.1, scheduled for Thursday 27 August 2026. Before that
# date `do-release-upgrade` on a 24.04 box correctly answers "No new release".

lsb_release -a
# Description:  Ubuntu 24.04.4 LTS
# Codename:     noble

# The policy that decides what you are offered. On servers it should be `lts`.
grep -v '^#' /etc/update-manager/release-upgrades
# [DEFAULT]
# Prompt=lts

# Prompt=lts     -> next LTS, but only after ITS point release. Correct for servers.
# Prompt=normal  -> every 6-month interim release. Wrong for almost all servers.
# Prompt=never   -> never offered. Use this to pin a fleet during a change freeze.

sudo do-release-upgrade -c          # -c = check only, changes nothing
# Checking for a new Ubuntu release
# No new release found.

# You CAN force it before 27 August with `-d`, which targets the development
# upgrade path. Do not do this on a production server: -d is how you end up
# being the person who finds the release-upgrader bug, and the point release
# exists precisely to absorb the first four months of regressions.

C’est aussi pour cela que le calendrier est moins pressant qu’il n’en a l’air. Ubuntu 24.04 LTS bénéficie de la maintenance de sécurité standard jusqu’en avril 2029. On ne vous pousse pas dans le vide le 27 août ; on vous ouvre une porte. La seule vraie échéance est celle que vous fixez vous-même, et la bonne consiste à passer avant la version suivante plutôt que la semaine où votre auditeur de conformité pose la question.^{[releasecycle]}

S’il vous faut davantage de temps, Ubuntu Pro prolonge la 24.04 avec la maintenance de sécurité étendue jusqu’en avril 2034. C’est une stratégie légitime pour un parc que vous gelez délibérément — un boîtier applicatif, un environnement isolé du réseau, quelque chose en cours de décommissionnement. C’est une mauvaise stratégie pour un parc sur lequel vous développez encore, parce que votre chaîne d’outils avance et que vous finissez par tout rétroporter vous-même.^[pro]

L’inventaire préalable, et pourquoi il est en lecture seule

Tout ce qui suit s’exécute sur la machine en 24.04, avant de toucher à quoi que ce soit. Rien n’est écrit. L’objectif n’est pas de produire un joli rapport : c’est de produire une sortie que vous pourrez comparer à celle du même script après la mise à niveau, pour que « ça a redémarré » devienne une affirmation réellement vérifiable.

#!/usr/bin/env bash
# noble-preflight.sh - read-only. Run it BEFORE the upgrade, save the output,
# and diff it against the same script run afterwards. Nothing here changes state.
set -uo pipefail
echo "=== identity ==="
lsb_release -ds; uname -r; systemctl --version | head -1

echo "=== 1. third-party repositories (the usual cause of a stuck upgrade) ==="
# do-release-upgrade disables these and does NOT re-enable them for you.
grep -rhs --include='*.list'    -E '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/
grep -rhs --include='*.sources' -E '^URIs' /etc/apt/sources.list.d/

echo "=== 2. packages not from the Ubuntu archive ==="
# Do NOT filter on the suite name: Docker's repo suite is literally `noble` and
# PGDG's is `noble-pgdg`, so grepping the codename hides exactly the two vendors
# you care about. Ask apt-cache policy where each package actually came from -
# in ONE invocation, because per-package calls reload the cache each time and
# turn this section into several minutes on a normal server.
#
# Set MIRROR to your own archive host if you run a local mirror, otherwise
# every package on the box gets reported as third-party and the output is noise.
# [.] rather than \. - awk processes escapes in a -v assignment and would warn.
MIRROR='archive[.]ubuntu[.]com|security[.]ubuntu[.]com|ports[.]ubuntu[.]com|archive[.]canonical[.]com'

apt-cache policy $(dpkg-query -f '${binary:Package} ' -W) 2>/dev/null | awk -v m="$MIRROR" '
  /^[a-zA-Z0-9]/ { pkg = $0; sub(/:$/, "", pkg) }
  /\*\*\*/     { getline; if ($2 !~ m && $2 != "/var/lib/dpkg/status")
                     printf "%-40s %s\n", pkg, $2 }'

echo "=== 3. held and manually installed packages ==="
apt-mark showhold
apt-mark showmanual | wc -l

echo "=== 4. locally modified config files you will be asked about ==="
# Every one of these produces a "keep or replace?" prompt mid-upgrade. Decide
# NOW, in writing, not at 02:00 with the package manager waiting on you.
debsums -ec 2>/dev/null || echo "install debsums to get this list"

echo "=== 5. services that must come back up ==="
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'

echo "=== 6. disk headroom - /boot is the one that bites ==="
df -h / /boot /var 2>/dev/null

echo "=== 7. cgroup hierarchy - a HARD upgrade blocker (see the cgroup section) ==="
stat -fc %T /sys/fs/cgroup/
# The parameter is a systemd boolean: 0/false/no/off all mean v1. Do not match
# only [01] or you will report "fine" on a host that is explicitly forced to v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline || echo "cmdline: default (v2)"

echo "=== 8. CPU capability for the AMD64v3 cloud images ==="
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo || echo "  MISSING: $f"
done

echo "=== 9. anything still using System V init scripts ==="
ls -1 /etc/init.d/ | grep -v README

Quatre de ces sections méritent leur place parce que ce sont elles qui transforment une mise à niveau de 40 minutes en mauvaise nuit :

• Les dépôts tiers. do-release-upgrade désactive tous les dépôts non-Ubuntu avant de démarrer, et ne les réactive pas ensuite. C’est le comportement correct, et cela signifie que tout ce que vous avez installé depuis un dépôt éditeur — Docker, le PGDG de PostgreSQL, Node, un agent APM — cesse de recevoir des mises à jour dès la fin de l’opération, silencieusement, jusqu’à ce que vous alliez le repointer vers la suite resolute.
• Les fichiers de configuration modifiés localement. Chacun d’eux déclenche une question interactive « conserver ou remplacer ? » au milieu de la transaction. Décidez à l’avance, par écrit. La réponse par défaut conserve votre version, ce qui est le choix sûr pour une configuration applicative et le mauvais choix pour tout ce qui touche à la sécurité et qui a bénéficié de deux ans de durcissement en amont.
• L’espace disque disponible. / a besoin de plusieurs gigaoctets libres ; un /boot séparé et trop petit est l’échec classique, parce que dracut et plusieurs noyaux vont le remplir et que la mise à niveau échoue en cours de route sur un système à moitié configuré.
• La hiérarchie cgroup et les jeux d’instructions du processeur. Les deux sont détaillés plus bas. Les deux sont des choses que vous voulez découvrir maintenant, et non depuis une console série.

Ce qui a réellement bougé entre les deux versions

Les chiffres marquants d’abord, parce qu’ils fixent les attentes pour tout le reste. Deux ans de développement Ubuntu, c’est un grand saut — ce n’est pas un service pack.^[ltssummary]

L’une de ces lignes est discrètement la plus intéressante. Passer d’OpenSSH 9.6 à 10.2 signifie que l’accord de clés hybride post-quantique mlkem768x25519-sha256 est disponible et préféré par défaut — pas garanti pour autant, puisqu’un pair resté en 9.6 négociera toujours un échange classique — et que la prise en charge de DSA a totalement disparu. OpenSSL en 26.04 gagne ML-KEM, ML-DSA et SLH-DSA, les standards du NIST. Si vous repoussiez la conversation post-quantique — celle que l’ANSSI invite à engager sans attendre —, cette mise à niveau en embarque une bonne part, que vous l’ayez planifiée ou non.^{[openssh][openssl35][fips203]}

Six valeurs par défaut qui ont changé sous vos pieds

C’est la section absente de tous les autres guides, et c’est la raison d’être de cet article. Ubuntu n’a pas seulement incrémenté des versions : la distribution a remplacé l’implémentation derrière six choses que vous tapez ou sur lesquelles vous vous appuyez tous les jours. La plupart sont des améliorations. Une seule arrêtera net la mise à niveau. Les autres se contenteront de désorienter quelqu’un de votre équipe à 3 h du matin si personne ne les a écrites quelque part.^[ltssummary]

sudo, c’est désormais sudo-rs

La ligne la plus surprenante des notes de version de la 26.04 : sudo-rs est désormais le fournisseur sudo par défaut, et le sudo original de Todd C. Miller a été renommé en paquet sudo.ws. sudo-rs est une réimplémentation à sûreté mémoire couvrant le sous-ensemble de sudoers que presque tout le monde utilise réellement. Face à quelque chose qu’il ne prend pas en charge, son comportement documenté est d’échouer en position fermée, avec une erreur explicite — et non de l’ignorer. C’est la bonne direction, et c’est aussi la raison d’auditer avant plutôt qu’après : une directive non prise en charge empêche sudo de fonctionner, sur une machine où sudo est précisément l’outil qui sert à réparer. Un petit ensemble énuméré est en revanche accepté puis ignoré — env_reset, visiblepw, verifypw, mail_badpass, always_set_home, log_denied et deux ou trois autres — et aucun de ceux-là n’assouplit les accès.^[sudors]

# 26.04 makes sudo-rs the default sudo provider. The original sudo by
# Todd C. Miller is still packaged, renamed to `sudo.ws`.

sudo --version
update-alternatives --display sudo    # which implementation is actually selected

# sudo-rs implements the sudoers subset that essentially everyone uses:
# user/group specs, host specs, NOPASSWD, Cmnd_Alias, %group, includedir.
# Its documented behaviour on something it does NOT support is to fail closed
# with a clear error, not to ignore it. That is the safe direction - but it
# means an unsupported directive stops sudo from working rather than quietly
# degrading it, so you want to find those directives before the upgrade, not
# from a locked-out root account afterwards. A short enumerated set is accepted
# and ignored instead (env_reset, visiblepw, verifypw, mail_badpass,
# always_set_home, log_denied among them); none of those loosen access.

# Resource limits and umask move to PAM; sendmail integration is simply gone.
grep -rEn 'Defaults.*(umask|rlimit|mailto|mailerpath|env_keep|logfile|SELinux|role|type)' \
     /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# Whatever you change, validate with the checker that matches your provider.
# visudo uses it automatically; run it by hand after any scripted edit.
sudo visudo -c

# --- If you find something sudo-rs will not honour ---
# Both implementations coexist; the provider is chosen through alternatives,
# so installing the package is only half the job:
sudo apt install sudo.ws
sudo update-alternatives --config sudo
# Treat this as a migration window rather than a destination: fix the sudoers
# file so you do not depend on the fallback staying available.

# --- One removal has no fallback ---
# The `sudo-ldap` package is gone. If your sudoers rules live in LDAP you must
# move that authorisation to PAM before upgrading, not after:
dpkg -l sudo-ldap 2>/dev/null | grep '^ii' && echo "ACTION REQUIRED: sudo-ldap is removed in 26.04"

Deux remarques pratiques. D’abord, les deux implémentations coexistent et le fournisseur se choisit via update-alternatives : installer sudo.ws ne fait donc que la moitié du retour en arrière. Ensuite, une suppression n’a aucune solution de repli : le paquet sudo-ldap a disparu. Si vos règles d’autorisation sudo vivent dans LDAP, il faut les déplacer vers une authentification LDAP via PAM avant la mise à niveau — sinon vous atterrissez sur un système où les règles ne sont tout simplement plus là, et, selon la façon dont vos chemins d’élévation sont câblés, peut-être sur un système que vous ne pouvez pas réparer sans accès console.

ls, sort et date sont maintenant en Rust

Deuxième surprise : les utilitaires de base proviennent maintenant de l’implémentation Rust rust-coreutils. Les binaires GNU restent installés avec le préfixe gnu — gnuls, gnudate, gnusort. À noter : cp, mv et rm sont toujours les versions GNU à l’intérieur du paquet Rust, retenues à cause de bogues non résolus. C’est le bon arbitrage, et cela veut dire que les utilitaires les plus capables de détruire des données sont précisément ceux qui n’ont pas changé. Une chose à savoir avant de se forger une opinion : les notes de version de la 26.04 divulguent vingt CVE connues visant rust-coreutils. Divulguer vaut infiniment mieux que taire, et rien là-dedans n’est alarmant — mais cela signifie que les utilitaires de base relèvent désormais de votre radar de correctifs, et non de la catégorie mentale des choses qui ne bougent jamais.^[uutils]

# Core utilities now come from rust-coreutils (the uutils project). The GNU
# binaries are still installed, prefixed with `gnu`: gnuls, gnudate, gnusort...

ls --version | head -1        # uutils
gnuls --version | head -1     # GNU

# Worth knowing before you decide: the 26.04 release notes ship a list of
# twenty known CVEs against rust-coreutils (CVE-2026-35341 through -35377).
# That is disclosed, not hidden, and none of it is a reason to panic - but it
# is a reason to keep this package on your patching radar rather than assuming
# core utilities are the boring part of the system.

# cp, mv and rm are STILL the GNU implementations inside rust-coreutils, held
# back over unresolved bugs. So the utilities most likely to destroy data are
# the ones that did not change - which is the right call, and worth knowing
# before you go hunting for a regression in the wrong place.

# Where this actually bites: scripts that parse output, or lean on a GNU-only
# flag. Behaviour is close, not identical, and error text differs.
# Test the parsers, not the interactive use:
sort --help | grep -c . ; date --help | grep -c .

# --- Reverting, if a script you cannot change depends on GNU behaviour ---
sudo apt install coreutils-from-gnu --allow-remove-essential
# ...and back again:
sudo apt install coreutils-from-uutils --allow-remove-essential
# `--allow-remove-essential` is required because coreutils is Essential:yes.
# Read that flag as the warning it is: run it from a console you can recover,
# not over the SSH session you are about to need.

chrony remplace systemd-timesyncd — mais pas chez vous

Troisième point, et celui que je vois le plus souvent oublié : chrony est désormais le démon de temps par défaut à la place de systemd-timesyncd — uniquement pour les nouvelles installations. Votre serveur mis à niveau conserve timesyncd, continue de fonctionner, et cesse discrètement de correspondre à la documentation, aux référentiels de durcissement et à toutes les procédures écrites pour la 26.04. Canonical documente la migration manuelle ; personne ne la fait à votre place.^[chrony]

# Chrony replaces systemd-timesyncd as the default time daemon - but ONLY for
# fresh installs. An upgraded 24.04 server keeps timesyncd and will not tell
# you it is now off the default path. This is the change most likely to be
# missed, because nothing breaks: you just quietly stop matching the docs.

timedatectl show --property=NTP --property=NTPSynchronized
systemctl is-active systemd-timesyncd chrony 2>/dev/null

# --- The migration Canonical documents for upgraded systems ---
sudo apt-mark auto systemd-timesyncd     # demote it to an automatic dependency
sudo apt install chrony                  # installing chrony displaces timesyncd

# Verify you have exactly one time daemon running, not zero and not two:
systemctl is-active chrony
chronyc tracking
chronyc sources -v

# --- The trap, if you had ever edited chrony.conf ---
# Ubuntu's NTS-authenticated pool now lives in a separate drop-in file. If your
# old chrony.conf still lists servers, you will poll the same pool twice.
grep -E '^(server|pool)' /etc/chrony/chrony.conf
cat /etc/chrony/sources.d/ubuntu-ntp-pools.sources
# Keep the drop-in, comment out the duplicates in chrony.conf, then:
sudo systemctl restart chrony && chronyc sources -v

La migration a un piège de l’autre côté. Le pool NTP authentifié par NTS d’Ubuntu réside désormais dans /etc/chrony/sources.d/ubuntu-ntp-pools.sources. Si vous aviez déjà édité chrony.conf en y laissant des lignes pool ou server, vous interrogerez deux fois les mêmes serveurs — ce n’est pas fatal, mais c’est le genre de chose qui produit une sortie chronyc incompréhensible six mois plus tard, quand quelqu’un enquêtera sur une dérive d’horloge.

dracut remplace initramfs-tools

Quatrième point : dracut devient l’infrastructure d’initramfs par défaut, à la place d’initramfs-tools. Les notes de version sont prudentes ici, et nous devrions l’être aussi — initramfs-tools reste pris en charge, et vous pouvez basculer d’une implémentation à l’autre. Ce dont un hôte migré hérite réellement n’est pas quelque chose à déduire d’un billet de blog, celui-ci compris. Vérifiez, puis agissez selon ce que vous trouvez :^{[dracut][dracutconf]}

• Demandez à la machine, ne le devinez pas. dpkg -l dracut initramfs-tools vous dit ce qui est installé, et dracut --version si c’est utilisable. Attention : lsinitrd n’a pas d’option --version, si bien que la ligne de commande évidente pour détecter dracut donne une réponse fausse — utilisez dracut --version à la place.
• La configuration se trouve ailleurs. Si vous basculez, /etc/initramfs-tools/ n’est plus l’endroit : dracut lit /etc/dracut.conf.d/, et tout hook personnalisé, toute liste de modules ou tout pilote forcé doit être réécrit pour lui. Cette réécriture est le vrai travail, et personne ne la fait à votre place.
• Inspectez l’image, ne la régénérez pas. Listez son contenu et confirmez que vos pilotes de stockage et de réseau sont présents — NVMe, virtio, megaraid, mpt3sas, ce dont votre matériel ou votre hyperviseur a besoin. Régénérer l’initramfs juste après une montée de version, sur un hôte que vous n’avez pas encore redémarré deux fois, est la chose la plus risquée de toute cette page.

cgroup v1 a disparu, et bloque la mise à niveau

systemd 259 dans la 26.04 n’a plus aucun cgroup v1. L’amont a supprimé les hiérarchies « legacy » et « hybride » dans systemd 258 ; seul cgroup v2 est monté au démarrage. Canonical en a fait une barrière franche plutôt qu’une surprise — dans leurs termes, « les installations Ubuntu fonctionnant en cgroup v1 ne seront pas autorisées à migrer vers Ubuntu 26.04 LTS ». Le mode de défaillance ici est donc une mise à niveau refusée, pas une machine brisée. C’est le bon dénouement, et cela vaut la peine d’être précis, parce que beaucoup d’articles consacrés à ce changement laissent entendre le contraire.^{[systemd258][cgroupv2]}

# systemd 259 in 26.04 has NO cgroup v1. The legacy and hybrid hierarchies
# were removed upstream in systemd 258; only cgroup v2 is mounted at boot.
#
# Canonical turned that into a hard gate rather than a surprise: "Ubuntu
# installations running cgroup v1 will not be allowed to upgrade to Ubuntu
# 26.04 LTS." So the failure mode is a REFUSED upgrade, not a bricked host -
# which is the good outcome, and the reason to check now is that you would
# otherwise discover it inside your maintenance window.

stat -fc %T /sys/fs/cgroup/
# cgroup2fs   -> v2, the upgrade will proceed
# tmpfs       -> v1 or hybrid, the upgrader will refuse. Fix it first.

# The parameter is a systemd boolean: 0, false, no and off all select v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline
grep -o 'systemd.legacy_systemd_cgroup_controller=[^ ]*' /proc/cmdline

# --- Fix it on 24.04, reboot, and confirm the workload still works ---
sudoedit /etc/default/grub
#   remove systemd.unified_cgroup_hierarchy=0 from GRUB_CMDLINE_LINUX*
sudo update-grub && sudo reboot
# after the reboot:
stat -fc %T /sys/fs/cgroup/     # must print cgroup2fs

# Two related consequences that are easy to miss, both from the release notes:
#   - a 26.04 CONTAINER will not run on a host still booted with cgroup v1
#   - a 26.04 HOST will not run containers that require v1 (e.g. images based
#     on Ubuntu older than 18.04). Check your base images, not just your hosts.

# --- The other systemd deadline, and it is closer than you think ---
# 26.04 is the LAST release that runs System V init scripts. systemd 260 has
# already dropped the support upstream, so the release that loses it is 26.10
# - October 2026, not some comfortable date in 2028.
ls -1 /etc/init.d/ | grep -v README
systemctl list-units --type=service --no-pager | grep -i 'LSB:'

Le motif à traquer est un paramètre de ligne de commande du noyau, généralement systemd.unified_cgroup_hierarchy=0, ajouté il y a des années pour contenter un vieux Docker, un ancien nœud Kubernetes ou un agent de supervision JVM — puis jamais retiré, parce que rien n’a jamais rappelé à personne qu’il était là. La raison de le trouver maintenant plutôt que le soir venu est simple : un refus au milieu de votre fenêtre de maintenance vous coûte quand même la fenêtre. Deux effets collatéraux passent facilement inaperçus : un conteneur 26.04 ne tournera pas sur un hôte encore démarré en cgroup v1, et un hôte 26.04 ne fera pas tourner de conteneurs exigeant v1 — tout ce qui repose sur une base Ubuntu antérieure à la 18.04, par exemple. Vérifiez vos images de base, pas seulement vos hôtes. Notez par ailleurs que la 26.04 est la dernière version à exécuter des scripts d’init System V, et cette échéance est plus proche qu’il n’y paraît : systemd 260 a déjà supprimé cette prise en charge en amont, si bien que la version qui la perd est la 26.10, en octobre 2026 — et non une date confortable en 2028.^{[since2510][mobycgroup][systemd260]}

APT 3 et la suppression d’apt-key

APT passe de 2.7 à 3.1, et le changement qui casse l’automatisation est la suppression d’apt-key. L’outil est déconseillé depuis des années et il n’y a pas de couche de compatibilité : la vérification de signature passe désormais directement par gpgv, et chaque dépôt doit nommer sa propre clé. Tout script de provisionnement qui appelle encore apt-key add échoue sur la 26.04 — et comme cet appel se situe généralement tôt dans un amorçage, il échoue avant que quoi que ce soit d’utile ne se soit produit.^{[aptsecure][aptsources]}

# APT 3 in 26.04 removes `apt-key` entirely. Verification goes straight to
# gpgv, and every repository must name its key explicitly.

apt --version                       # apt 3.1.x
command -v apt-key || echo "apt-key: gone, as expected"

# Find repositories that still rely on the deleted trusted keyring. These are
# what break: not the tool, the repositories that assumed it.
ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/ 2>/dev/null

# --- The replacement: one key per repository, referenced by path ---
# Create the directory explicitly. It exists on a normal install and does NOT
# on a minimal container image, which is exactly where bootstrap scripts run.
sudo install -m 0755 -d /etc/apt/keyrings
# Dearmor the key into its own file (note .gpg for binary, .asc for armoured):
curl -fsSL https://example.com/repo.asc \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg

# Then point the repository at it. Modern deb822 format, /etc/apt/sources.list.d/example.sources:
#   Types: deb
#   URIs: https://example.com/apt
#   Suites: resolute
#   Components: main
#   Signed-By: /etc/apt/keyrings/example.gpg
#
# Or the one-line form, if you still use it:
#   deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt resolute main

sudo apt update                     # any repo you missed fails loudly here

# --- Worth knowing about, not worth planning around ---
# APT 3 adds transaction history. It replays package operations; it does not
# restore data, and it cannot undo a release upgrade.
apt history-list
sudo apt history-undo <ID>

APT 3 apporte aussi un nouveau solveur de dépendances, qui prend le relais automatiquement quand le solveur classique ne trouve pas de solution, ainsi qu’un historique de transactions avec apt history-undo et apt history-rollback. Lisez attentivement cette fonctionnalité avant de compter dessus : elle rejoue des opérations de paquets. Elle ne restaure pas de données, elle ignore l’existence de votre base de données, et elle ne peut pas annuler une montée de version.

Python 3.12 → 3.14 traverse les « piles mortes »

Ubuntu 24.04 embarque Python 3.12 ; la 26.04 embarque la 3.14. Cette mise à niveau traverse donc la 3.13, la version qui a supprimé dix-neuf modules de la bibliothèque standard au titre du PEP 594. Il ne reste aucun avertissement de dépréciation à intercepter, puisque la période d’avertissement était celle des versions 3.11 et 3.12. Ce que vous obtenez à la place, c’est une ImportError à l’exécution, dans la tâche cron, le hook ou le gestionnaire de requête qui atteindra cet import en premier.^{[py313][pep594]}

# 24.04 shipped Python 3.12. 26.04 ships 3.14 as the system interpreter - so
# this upgrade crosses 3.13, the release that deleted nineteen standard-library
# modules under PEP 594. Nothing warns you: the import simply fails at runtime,
# in whichever cron job or handler happens to reach that line first.

python3 --version                   # Python 3.14.x

# Scan everything you own for the removed modules, before the upgrade. Note
# the module name is matched anywhere on an import line, not just directly
# after the keyword - otherwise `import os, cgi` slips straight through.
grep -rInE '^[[:space:]]*(import|from)[[:space:]].*\b(aifc|audioop|cgi|cgitb|chunk|crypt|imghdr|mailcap|msilib|nis|nntplib|ossaudiodev|pipes|sndhdr|spwd|sunau|telnetlib|uu|xdrlib)\b' \
  --include='*.py' /opt /srv /usr/local/lib /home 2>/dev/null

# The three that actually turn up on servers, and what to do about each:
#   cgi / cgitb -> old WSGI shims and form parsing. Move to the framework's
#                  parser, or `pip install standard-cgi` as a stopgap.
#   crypt       -> /etc/shadow hashing in provisioning scripts.
#                  Replace with `passlib` or a libxcrypt binding.
#   telnetlib   -> network-device automation. Replace with `netmiko`/`pexpect`,
#                  or better, stop using telnet.
# Pure-Python removals are republished on PyPI under `standard-*` names, which
# buys you a release cycle. It does not fix the code.

# Do not forget the interpreter under your virtualenvs: a venv created against
# 3.12 keeps pointing at a binary the upgrade removes. -xdev keeps this out of
# /proc, /sys and network mounts; -print0 survives paths with spaces.
find / -xdev -name pyvenv.cfg -print0 2>/dev/null \
  | xargs -0 -r grep -H 'version'   # rebuild every one of these afterwards

Trois des dix-neuf réapparaissent sur les serveurs avec une belle régularité : cgi et cgitb dans de vieilles couches WSGI et des utilitaires d’analyse de formulaires, crypt dans les scripts de provisionnement qui écrivent des empreintes dans /etc/shadow, et telnetlib dans l’automatisation d’équipements réseau. Les modules purement Python ont été republiés sur PyPI sous des noms préfixés par standard-, ce qui vous achète un cycle de version pour corriger le code proprement. Et n’oubliez pas les environnements virtuels : un venv créé contre le binaire 3.12 continue de pointer vers un interpréteur que la mise à niveau supprime.^[py314]

Votre instance cloud n’est peut-être plus prise en charge

Les images cloud d’Ubuntu 26.04 pour AMD64 sont compilées pour le niveau de micro-architecture x86-64-v3. Lisez ce mot attentivement, parce que beaucoup d’articles ne le font pas : ce sont les images préconstruites qui ont bougé, pas l’archive. Le niveau x86-64-v3, c’est la base v2 plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE et OSXSAVE — un processeur qui en est dépourvu ne peut tout simplement pas exécuter ces instructions, et aucun paramètre noyau ne l’adoucira.^{[ltssummary][x86levels]}

# Ubuntu 26.04 cloud IMAGES for AMD64 are built for the x86-64-v3
# microarchitecture level. Read that word carefully: it is the prebuilt images
# that moved, not the archive. The archive stays baseline x86-64, so an
# in-place upgrade still pulls baseline packages. What you lose on an old
# instance family is SUPPORT and a launchable image - not, by itself, the boot.
# That is a smaller problem than "it will not come back", and still one you
# want to solve before you build anything else on top of it.

# x86-64-v3 is the v2 baseline plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT,
# MOVBE and OSXSAVE. AVX2 is a decent proxy; the loop is the real check.
# Note `abm`: Linux exposes LZCNT under that capflag, and there is no `lzcnt`
# string in /proc/cpuinfo - grep for the obvious name and every host on earth
# reports a missing feature it actually has.
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo && echo "  $f yes" || echo "  $f MISSING"
done

# --- AWS: previous-generation families are out ---
# M1 M2 M3 M4 / C1 C3 C4 / R3 R4 / I2 / G3 / P2 P3 P3dn are no longer supported
# from 26.04. Note the [a-z]* before the dot: without it you miss p3dn and g3s,
# which are precisely two of the families you are hunting for.
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{Id:InstanceId,Type:InstanceType}' \
  --output text | grep -E '^\S+[[:space:]]+(m[1-4]|c[134]|r[34]|i2|g3|p[23])[a-z]*\.'
# The fix is a migration, not a config change: resize onto a current family
# (m6i/m7i, c6i/c7i, r6i/r7i) FIRST, then upgrade the OS.

# --- Google Cloud: N1 on Sandy Bridge or Ivy Bridge is out ---
gcloud compute instances list --format='table(name,zone,machineType,cpuPlatform)'

# --- Bare metal / on-prem: opt in only after you have checked every host ---
# The archive itself stays baseline x86-64; the v3 build is opt-in:
echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update && sudo apt upgrade

En pratique, la portée est plus étroite que la version paniquée, et mérite tout de même une action. Les familles AWS de génération précédente ne sont plus prises en charge à partir de la 26.04, et aucune image 26.04 n’est construite pour elles. Une mise à niveau sur place avec do-release-upgrade tire les paquets amd64 de base depuis l’archive : c’est donc un problème de support plutôt qu’automatiquement un problème de démarrage — mais faire tourner une combinaison non prise en charge, sous charge de production, sur un matériel que personne ne teste, n’est pas une position que l’on choisit délibérément. Si vous avez une M3 qui fait tourner quelque chose d’important — et un nombre surprenant de gens sont dans ce cas, précisément parce que ça marche très bien depuis dix ans — basculez d’abord sur une famille actuelle, puis migrez l’OS. Sur du matériel physique, rien ne vous force la main : l’archive reste en x86-64 de base et la variante v3 est strictement optionnelle.^[awsprev]

Service par service : ceux qui demandent une vraie migration

Les changements de version sont d’ordinaire sans histoire. Voici ceux où les mainteneurs ont modifié quelque chose qui exige une action de votre part, classés à peu près selon la gravité de l’inaction :

RabbitMQ mérite la première ligne à lui seul : à cause des « feature flags », il n’est pas directement migrable d’un bout à l’autre de ce saut, et Canonical documente des étapes manuelles. Dovecot 2.4 a réécrit intégralement le format de configuration — planifiez cela comme un chantier à part entière, pas comme un effet secondaire de la montée de version de l’OS. HAProxy passe de la série 2.x à la 3.2, qui rejette le mot-clé enabled pour les serveurs dynamiques, analyse plus strictement les URI non standard, et renomme tune.ssl.ocsp-update en tune.ocsp-update.^{[rabbitmq][dovecot24][haproxy32]}

Le reste est ordinaire mais pas automatique. PostgreSQL 18 exige pg_upgrade depuis la 16 ; MySQL 8.0 vers 8.4 LTS abandonne des options dépréciées de longue date et supprime la prise en charge du serveur 32 bits. SSSD s’exécute désormais sous un utilisateur sssd non privilégié plutôt que root : vérifiez qu’il peut toujours lire ses secrets et ses keytabs. Postfix n’est plus en chroot par défaut. Et si vous exploitez un contrôleur de domaine Active Directory Samba sans que le paquet samba-ad-dc soit explicitement installé, installez-le avant la mise à niveau — sinon la fonction de contrôleur de domaine ne survit pas, et les composants dont vous auriez besoin pour réparer sont justement ceux qui n’ont pas été installés.^{[postgres18][mysql84][sssd]}

Les deux problèmes connus qui mordent vraiment les serveurs

Canonical publie une liste de problèmes connus à côté des notes de version, et deux entrées y sont plus concrètes que presque tout ce qui a été écrit sur la 26.04. Aucune ne bloque la mise à niveau. Les deux changent le comportement de votre serveur ensuite, discrètement, d’une manière que vous attribuerez à autre chose si vous ne savez pas où regarder. La première concerne apache2 : son unité systemd positionne désormais MemoryDenyWriteExecute=yes à titre de durcissement, ce qui interdit toute mémoire à la fois inscriptible et exécutable — exactement ce dont un compilateur JIT a besoin. Sous libapache2-mod-php, cela casse le JIT de PHP, avec des Allocation of JIT memory failed dans vos journaux et une baisse de performance que personne ne rattache à une montée de version de l’OS.^{[since2510][apachebug]}

# Both of these are in Canonical's own known-issues list for 26.04, and both
# are more concrete than most of what gets written about this release. Neither
# stops the upgrade; both change how your server behaves afterwards.

# --- 1. apache2 + mod-php: the PHP JIT stops working ---
# The apache2 systemd unit now sets MemoryDenyWriteExecute=yes as hardening.
# That forbids memory that is writable and executable at once, which is exactly
# what a JIT needs. Symptom:
#   Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled.
dpkg -l 'libapache2-mod-php*' 2>/dev/null | grep '^ii'

# Recommended fix: move to php-fpm, which is not affected. Note the a2dismod -
# without it apache2 keeps loading mod_php and the JIT stays broken, which is
# the most common way this "fix" gets applied and then reported as not working.
sudo apt install php-fpm
sudo a2dismod php8.5 && sudo a2dismod mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif && sudo a2enconf php8.5-fpm
sudo systemctl restart apache2 php8.5-fpm

# If you must stay on mod-php, override the hardening deliberately - and
# understand that you are turning off a mitigation, not fixing a bug:
sudo systemctl edit apache2
#   [Service]
#   MemoryDenyWriteExecute=no
sudo systemctl restart apache2

# --- 2. PostgreSQL on the 7.0 kernel: throughput and latency regression ---
# A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
# Systems using huge pages are NOT affected, so this is a configuration
# question rather than a wait-for-a-patch question.
sudo -u postgres psql -tAc 'SHOW huge_pages;'      # want: on

# huge_pages=try (the default) silently falls back to normal pages, which is
# how you end up affected without any error telling you so.
#
# Size the pool FIRST. PostgreSQL will compute the number for you - no
# arithmetic, no guessing at shared_buffers overhead:
sudo -u postgres postgres -D /var/lib/postgresql/18/main \
     -C shared_memory_size_in_huge_pages
# 3170
grep -E 'Hugepagesize|HugePages_Total' /proc/meminfo
sudo sysctl -w vm.nr_hugepages=3170                # use YOUR number, then
                                                   # persist it in /etc/sysctl.d/
# ...and only now turn it on:
sudo -u postgres psql -c "ALTER SYSTEM SET huge_pages = 'on';"
sudo systemctl restart postgresql
# huge_pages=on means PostgreSQL REFUSES TO START if the pages are not
# available. That is the point - it fails loudly instead of quietly slowly -
# but it means you size the pool before you flip the setting, not after.

La seconde concerne PostgreSQL, et c’est celle sur laquelle je parierais qu’elle sera mal diagnostiquée. Un changement introduit dans Linux 7.0 peut provoquer une régression significative de débit et de latence — mais les systèmes qui utilisent les « huge pages » ne sont pas affectés, ce qui en fait une question de configuration plutôt qu’une attente de correctif. Le piège, c’est que la valeur par défaut huge_pages=try de PostgreSQL bascule silencieusement sur des pages normales : un serveur affecté ne signale donc strictement rien — pas d’erreur, pas d’avertissement, juste de moins bons chiffres que la semaine dernière. Positionnez huge_pages=on délibérément, et dimensionnez le pool de huge pages avant de le faire, car on signifie que PostgreSQL refuse de démarrer si les pages ne sont pas là. C’est le bon arbitrage — échouer bruyamment plutôt que ralentir en silence — mais ce n’est pas un réglage à basculer en fin de longue fenêtre de maintenance.^{[pghugepages][pgkernel][systemdexec]}

Exécuter la mise à niveau

Rien de tout cela n’est astucieux. La valeur tient entièrement à l’ordre des opérations, et au refus de sauter l’étape zéro.^[upgradedoc]

# Nothing below is clever. The value is entirely in the order and in refusing
# to skip step 0.

# --- 0. A rollback you have actually tested ---
# Snapshot the VM, or take a filesystem-level backup you have restored from at
# least once. `do-release-upgrade` has no undo, and neither does apt history.
# If you cannot roll back, you are not upgrading, you are gambling.

# --- 1. Land on a fully patched 24.04 first ---
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove
sudo reboot                        # boot the newest 24.04 kernel BEFORE upgrading
uname -r

# --- 2. Survive a dropped connection ---
# The upgrade takes 20-60 minutes and will kill your shell if the link drops
# mid-transaction. do-release-upgrade opens a standby sshd on 1022 by itself;
# run it inside tmux or screen anyway.
sudo apt install tmux
tmux new -s upgrade
# detach with Ctrl-b d, reattach after a disconnect with: tmux attach -t upgrade

# --- 3. Run it ---
sudo do-release-upgrade
# Answer the config-file prompts from the list you produced in the pre-flight.
# Default is "keep your currently-installed version" (N). For sshd_config and
# anything security-relevant, take the maintainer's version and re-apply your
# changes as a drop-in afterwards - your 2019 hardening file is not better
# than the 2026 defaults.

# --- 4. Reboot and verify, in this order ---
sudo reboot
lsb_release -ds                    # Ubuntu 26.04.1 LTS
uname -r                           # 7.x
systemctl --failed                 # must be empty
journalctl -p err -b --no-pager | head -50
ss -tlnp                           # every listener you expect, and nothing new

# --- 5. Clean up what the upgrade left behind ---
sudo apt --purge autoremove        # read the list before confirming
ls /etc/apt/sources.list.d/        # re-enable third-party repos, resolute suites
dpkg -l | grep '^rc' | wc -l       # removed-but-not-purged leftovers

Un arbitrage mérite d’être dit à voix haute, parce que la réponse par défaut n’est pas toujours la bonne. Quand la mise à niveau vous interroge sur un fichier de configuration modifié, conserver votre version est le choix sûr pour une configuration applicative et le mauvais choix pour tout ce qui touche à la sécurité. Votre durcissement de sshd_config datant de 2019 n’est pas meilleur que les valeurs par défaut de 2026 — et il ne correspond probablement plus aux règles d’hygiène informatique que recommande l’ANSSI. Mais assortissez ce conseil de la réserve qui s’impose. Accepter le sshd_config du mainteneur écarte aussi les directives Port, AllowUsers, PermitRootLogin ou un bloc Match personnalisés qui vivaient dans ce fichier, et sshd redémarre avant que vous ne les ayez réappliquées — sur la connexion même par laquelle vous migrez. Gardez ouverte la session de secours sur le port 1022, réappliquez vos vraies modifications locales sous forme de fichier additionnel dans sshd_config.d/, où la prochaine mise à niveau les laissera tranquilles, et seulement ensuite fermez le premier shell.

Vérifier ensuite, sérieusement

« Ça a démarré » n’est pas une vérification. Ce script est le pendant du script préalable — et pour être précis sur leur usage, les deux scripts affichent délibérément des sections différentes : ne comparez donc pas l’un à l’autre en bloc. Les blocs qu’il est pertinent de comparer directement sont la liste des services activés et la sortie de ss -tlnp : mêmes unités activées, mêmes ports en écoute. Si un service était activé avant et ne l’est plus, c’est là que vous l’apprenez — et non quand quelqu’un ouvrira un ticket le lundi matin.

#!/usr/bin/env bash
# noble-postflight.sh - the counterpart to the pre-flight script. The two print
# DIFFERENT sections on purpose, so do not diff them against each other
# wholesale. The blocks that are directly comparable are the enabled-services
# list and `ss -tlnp`: same units enabled, same ports listening.
# "It booted" is not a verification; "the same 41 services are enabled and
# listening on the same ports" is.
set -uo pipefail

echo "=== the defaults that changed under you ==="
sudo --version | head -1                    # sudo-rs, unless you reverted
update-alternatives --display sudo | head -2
ls --version | head -1                      # uutils, unless you reverted
systemctl is-active chrony systemd-timesyncd 2>/dev/null   # exactly one active
stat -fc %T /sys/fs/cgroup/                 # cgroup2fs

echo "=== which initramfs generator is this host ACTUALLY using? ==="
# Both are supported in 26.04 and either can be in place after an upgrade, so
# do not assume - ask. (lsinitrd has no --version; dracut does.)
dpkg -l dracut initramfs-tools 2>/dev/null | grep '^ii' || true
command -v dracut >/dev/null && dracut --version

echo "=== crypto, which moved a long way in two years ==="
ssh -V                                      # OpenSSH 10.2p1 in 26.04, from 9.6p1
ssh -Q kex | grep -c mlkem                  # post-quantum key agreement offered
# OpenSSL spells these with hyphens - ML-KEM-768, not mlkem - so grep for both
# or you will "prove" that a correctly configured box has no PQ support.
openssl list -kem-algorithms | grep -ciE 'ml-?kem'

echo "=== DSA host keys are gone; make sure nothing still expects one ==="
ls /etc/ssh/ssh_host_*_key 2>/dev/null
sudo sshd -t && echo "sshd config: valid"

echo "=== services ==="
systemctl --failed --no-pager
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'
ss -tlnp

echo "=== rebuild every virtualenv that pointed at python3.12 ==="
find / -xdev -name pyvenv.cfg 2>/dev/null

echo "=== the two server known-issues from the release notes ==="
# 1. apache2 now sets MemoryDenyWriteExecute=yes, which breaks the PHP JIT
#    under libapache2-mod-php. php-fpm is unaffected and is the recommendation.
dpkg -l libapache2-mod-php\* 2>/dev/null | grep -q '^ii' && \
  echo "mod-php present -> move to php-fpm, or: systemctl edit apache2 (MemoryDenyWriteExecute=no)"
# 2. A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
#    Systems using huge pages are not affected.
command -v psql >/dev/null && sudo -u postgres psql -tAc 'show huge_pages'
#    Anything other than `on` here is worth fixing before you call this done.

echo "=== boot integrity: inspect, do not regenerate ==="
# READ ONLY on purpose. Regenerating the initramfs immediately after a release
# upgrade is the riskiest thing you could do on this page; look first.
# /boot/initrd.img-* is mode 0600 root:root, hence the sudo on both branches.
if command -v lsinitrd >/dev/null; then
  sudo lsinitrd | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
elif command -v lsinitramfs >/dev/null; then
  sudo lsinitramfs /boot/initrd.img-"$(uname -r)" | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
else
  echo "neither lsinitrd nor lsinitramfs present - install the tool matching your generator"
fi

Deux choses que le script ne peut pas vérifier à votre place. D’abord votre configuration netplan : la 26.04 embarque Netplan 1.2, avec un systemd-networkd-wait-online personnalisé qui attend une interface routable, si bien qu’un hôte dont la carte réseau monte tardivement peut démarrer différemment d’avant. Ensuite, chaque dépôt tiers de la liste établie en amont — repointez-le vers la suite resolute avec une clé Signed-By, et confirmez qu’apt update est propre. Un parc qui a silencieusement cessé de recevoir les mises à jour de sécurité d’un éditeur est la façon la plus discrète possible pour cette migration d’avoir mal tourné.^[netplan]

Alors : maintenant, en novembre, ou en 2027 ?

Mon avis honnête, après avoir fait l’exercice sur des parcs soigneux comme sur des parcs négligés :

1. Ne migrez pas le 27 août. La version de maintenance existe pour absorber les régressions, mais celles qu’elle n’attrape pas remontent dans la quinzaine qui suit, découvertes par des gens avec plus d’appétit pour le risque qu’un parc de production ne devrait en avoir.
2. Migrez un serveur non critique début septembre. Quelque chose d’assez réel pour être instructif — un agent de build, un outil interne — mais pour lequel personne ne vous réveille. Lancez les scripts avant et après, et gardez le diff. Ce diff est votre document de migration pour tout le reste.
3. Levez d’abord partout les deux blocages de mise à niveau. Un hôte encore démarré en cgroup v1, et tout ce qui tourne sur IBM Z z14 ou antérieur, se verront refuser la migration par l’outil — trouvez-les donc avant de planifier du travail autour d’eux. Ajoutez les familles d’instances AMD64v3 à la même passe : elles ne sont pas bloquées, mais faire tourner une combinaison non prise en charge est un choix, et il doit être délibéré. Les trois se vérifient en 24.04 dès aujourd’hui, indépendamment de toute décision de migration.
4. Puis traitez le reste par lots en octobre et novembre. D’ici là, les dépôts tiers dont vous dépendez auront leurs suites resolute, ce qui supprime l’essentiel des frottements restants.

Et lisez la page des problèmes connus plutôt que le seul résumé. Elle est mise à jour après la publication, ce qui est exactement la propriété que vous attendez d’elle : le résumé vous dit ce qui était prévu, la liste des problèmes connus vous dit ce qui s’est réellement passé.^[since2510]

Si vous touchez de toute façon à l’init et à la planification des tâches, les timers systemd face à cron couvre la migration que cette version rend urgente. Le volet SSH et TLS de la mise à niveau fait l’objet de SSH et TLS post-quantiques, qui détaille ce qu’il faut vérifier sur les connexions plutôt que sur les paquets. Et si cet article vous a surtout donné envie d’avoir moins de pièces mobiles à faire évoluer, c’est précisément l’argument de les architectures cloud ennuyeuses.

Questions fréquentes

Puis-je passer d’Ubuntu 24.04 à 26.04 avant le 27 août 2026 ?

Techniquement oui, avec do-release-upgrade -d, qui vise la voie de mise à niveau de développement. Vous ne devriez pas le faire sur un serveur de production. La version de maintenance existe précisément pour absorber quatre mois de régressions post-publication, et forcer la migration en avance signifie que c’est vous qui trouverez les bogues de l’outil de montée de version. Sur un portable que vous pouvez restaurer en une heure, c’est raisonnable ; sur un serveur qui porte du trafic réel, non.

Suis-je obligé de migrer ? Jusqu’à quand la 24.04 est-elle prise en charge ?

Ubuntu 24.04 LTS bénéficie de la maintenance de sécurité standard jusqu’en avril 2029, et Ubuntu Pro prolonge cela avec l’ESM jusqu’en avril 2034. Il n’y a aucune urgence en août 2026. La raison de migrer, c’est que votre propre chaîne d’outils avance — Python plus récent, PostgreSQL plus récent, environnements d’exécution plus récents — et que rester sur place finit par vous obliger à tout rétroporter vous-même. Geler est un choix légitime pour un boîtier applicatif ou un parc en cours de décommissionnement, et un mauvais choix pour une plateforme sur laquelle vous construisez encore.

Quel est le changement le plus susceptible de me coûter une fenêtre de maintenance ?

Un paramètre noyau systemd.unified_cgroup_hierarchy=0 oublié. systemd 259 n’a plus aucun cgroup v1, et Canonical en a fait une barrière franche : un hôte encore démarré en cgroup v1 n’est pas autorisé à migrer. Vous n’obtenez pas une machine cassée — vous obtenez un refus, au moment précis où vous aviez budgété une heure d’indisponibilité. En deuxième position vient la régression PostgreSQL sur le noyau Linux 7.0, car contrairement à la première elle ne produit aucune erreur, juste de moins bons chiffres. Les deux se vérifient en moins d’une minute en 24.04, dès aujourd’hui, avant même de vous engager sur une date.

sudo-rs est-il sûr en production ?

Oui pour la configuration sudoers que possèdent réellement l’écrasante majorité des systèmes : spécifications d’utilisateurs et de groupes, spécifications d’hôtes, NOPASSWD, alias de commandes, includedir. La prudence s’impose sur les bords. sudo-rs n’implémente pas toute la gamme des entrées Defaults ; les limites de ressources et l’umask passent par PAM, et l’intégration sendmail a disparu. Face à une directive non prise en charge, son comportement documenté est d’échouer en position fermée avec une erreur explicite plutôt que de l’ignorer — c’est la direction sûre, mais cela signifie qu’une directive que vous n’avez pas vérifiée peut empêcher sudo de fonctionner sur une machine où sudo est justement l’outil qui sert à réparer. Un petit ensemble énuméré est en revanche accepté puis ignoré, et aucun de ceux-là n’assouplit les accès. Auditez le fichier avant de migrer. Si vous devez revenir en arrière, les deux implémentations coexistent : installez sudo.ws et sélectionnez-le avec update-alternatives --config sudo — installer le paquet seul ne change pas le fournisseur.

Mes conteneurs Docker fonctionneront-ils encore après la migration ?

Dans la quasi-totalité des cas oui, parce qu’Ubuntu 24.04 utilise déjà cgroup v2 par défaut et que Docker moderne prend en charge v2 depuis des années. L’exception est un hôte où quelqu’un avait positionné systemd.unified_cgroup_hierarchy=0 sur la ligne de commande du noyau pour contenter un Docker ou un nœud Kubernetes plus ancien — un tel hôte se voit purement et simplement refuser la mise à niveau. Vérifiez avec stat -fc %T /sys/fs/cgroup/ : la sortie doit être cgroup2fs. Deux limites voisines s’oublient facilement. Un conteneur 26.04 ne tournera pas sur un hôte encore démarré en cgroup v1, et un hôte 26.04 ne fera pas tourner de conteneurs exigeant v1 — les images basées sur une Ubuntu antérieure à la 18.04, par exemple. Vérifiez donc vos images de base autant que vos hôtes.

Pourquoi mon script Python ne fonctionne-t-il plus après la mise à niveau ?

Très probablement une ImportError sur un module supprimé dans Python 3.13. Ubuntu 24.04 livrait Python 3.12 et la 26.04 livre la 3.14 : cette migration traverse donc la version qui a supprimé dix-neuf modules de la bibliothèque standard au titre du PEP 594. Les trois que l’on rencontre le plus souvent sur des serveurs sont cgi, crypt et telnetlib. Les suppressions purement Python ont été republiées sur PyPI sous des noms préfixés par standard-, en dépannage. Par ailleurs, tout environnement virtuel créé contre le binaire 3.12 doit être reconstruit, car l’interpréteur qu’il désigne n’existe plus.

Dois-je migrer de systemd-timesyncd vers chrony ?

Pas strictement — timesyncd fonctionne toujours et un serveur mis à niveau le conserve. Mais chrony est la valeur par défaut des installations neuves en 26.04 : si vous ne faites rien, vos hôtes migrés et vos hôtes fraîchement construits divergent, et toute procédure ou tout référentiel de durcissement écrit pour la 26.04 cesse de correspondre. Canonical documente la migration sous la forme apt-mark auto systemd-timesyncd puis apt install chrony. Si vous migrez, vérifiez que les serveurs encore listés dans chrony.conf ne sont pas dupliqués par le fichier additionnel /etc/chrony/sources.d/ubuntu-ntp-pools.sources.

Puis-je revenir en arrière si la migration tourne mal ?

Avec aucun outil Ubuntu. do-release-upgrade n’a pas d’annulation, et le nouveau apt history-undo rejoue des opérations de paquets plutôt que de restaurer un système : il ignore vos données et ne peut pas inverser une montée de version. Votre retour arrière, c’est un instantané de machine virtuelle ou une sauvegarde au niveau du système de fichiers depuis laquelle vous avez déjà restauré au moins une fois. Si vous n’en avez pas, vous ne migrez pas : vous pariez, avec une bonne espérance de gain et une perte potentielle non bornée.

L’exécution de conteneurs sous tout cela a bougé elle aussi : ce qui casse en passant à Docker Engine 29 traite du plancher d’API, du magasin d’images et de la limite de descripteurs de fichiers qui a changé sans le moindre message d’erreur.

Sources

Chaque affirmation ci-dessus remonte à l’une de ces références. Les notes de version et le calendrier de Canonical font autorité pour tout ce qui est propre à Ubuntu ; la documentation des projets amont pour le reste. Là où les notes officielles ne donnent pas de numéro de version, cet article décrit la capacité plutôt que de deviner un chiffre.

1. Canonical — Ubuntu 26.04 LTS (Resolute Raccoon) release notes; released 23 April 2026, supported until April 2031
2. Canonical — Ubuntu 26.04 LTS summary for LTS users: the authoritative list of changes since 24.04, and the source for every default swap described here
3. Canonical — Ubuntu 26.04 LTS changes since 25.10, including the known-issues list and the cgroup v1 removal detail
4. Canonical — Resolute Raccoon release schedule; the 26.04.1 point release is listed for Thursday 27 August 2026
5. Ubuntu Server documentation — How to upgrade your release (do-release-upgrade, the -d flag, and the LTS-to-LTS point release rule)
6. Canonical — Ubuntu 24.04 LTS (Noble Numbat) release notes, the baseline this article upgrades from
7. Canonical — Ubuntu release cycle: LTS cadence, five years of standard support, ESM through Ubuntu Pro
8. Canonical — Ubuntu Pro documentation (ESM, Livepatch, and the ten-year maintenance window on 24.04)
9. Trifecta Tech Foundation — sudo-rs, the memory-safe sudo and su implementation that is now Ubuntu's default sudo provider
10. uutils/coreutils — the Rust reimplementation of the GNU core utilities shipped as rust-coreutils
11. systemd v258 release notes — removal of cgroup v1 (legacy and hybrid hierarchies) and the raised kernel baseline
12. systemd NEWS — the upstream changelog covering v256 through v259, including the System V compatibility deprecation
13. Linux kernel documentation — Control Group v2, the only hierarchy systemd still mounts
14. moby/moby #51111 — Docker's cgroup v1 deprecation discussion and support timeline
15. apt-secure(8) — repository signing after the removal of apt-key, and the Signed-By mechanism that replaces it
16. sources.list(5) — the deb822 .sources format and the Signed-By field
17. dracut(8) — the initramfs infrastructure that replaces initramfs-tools as Ubuntu's default
18. dracut.conf(5) — configuration in /etc/dracut.conf.d/, including hostonly and the drivers to force-include
19. chrony.conf(5) — the configuration file, source directories and NTS options for Ubuntu's new default time daemon
20. What's New In Python 3.13 — the release that removed the nineteen PEP 594 'dead battery' standard-library modules
21. PEP 594 — Removing dead batteries from the standard library; the full list of removed modules and their replacements
22. What's New In Python 3.14 — the interpreter Ubuntu 26.04 ships as the system Python
23. OpenSSL 3.5 series release notes — ML-KEM, ML-DSA and SLH-DSA support and the default hybrid TLS groups
24. OpenSSH release notes index — covers the 9.6 to 10.2 range that this upgrade crosses, including DSA removal
25. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), the algorithm behind the new OpenSSL and OpenSSH defaults
26. AWS — previous generation EC2 instances; the families that lose Ubuntu support because of the AMD64v3 cloud image baseline
27. x86-64 microarchitecture levels — what x86-64-v3 requires (AVX2, BMI1/2, FMA, MOVBE)
28. RabbitMQ — upgrade documentation and feature flags, the reason RabbitMQ is not directly upgradable across this release
29. Dovecot — upgrading from 2.3 to 2.4, the release that rewrote the configuration format (26.04 ships 2.4.2)
30. HAProxy 3.2 configuration manual — the breaking changes since the 2.x series shipped in 24.04
31. PostgreSQL 18 release notes — the major version 26.04 ships, requiring pg_upgrade from 16
32. MySQL 8.4 LTS release notes — the series replacing 8.0, including removed deprecated options
33. Netplan 1.2 documentation — the series shipped in Ubuntu 26.04
34. SSSD 2.10 release notes — the change that makes the daemon run as the unprivileged sssd user rather than root
35. systemd v260 release notes — System V service script support already dropped upstream, which is why 26.10 is the release that loses it
36. PostgreSQL documentation — the huge_pages configuration parameter, the documented mitigation for the Linux 7.0 regression
37. PostgreSQL documentation — configuring Linux huge pages for the server
38. LP #2144455 — apache2's MemoryDenyWriteExecute hardening breaking the PHP JIT under libapache2-mod-php
39. systemd.exec(5) — MemoryDenyWriteExecute=, the hardening directive apache2 now sets by default