Cours Ubuntu 26.04 / Préparer et réaliser une mise à niveau Ubuntu LTS

Une mise à niveau Ubuntu LTS change de version du système et demande une sauvegarde restaurable, un chemin officiellement proposé et des essais de service après redémarrage. Si vous avez déjà installé Ubuntu 26.04, vous n’avez pas à changer de version pour suivre ce cours ; la procédure sert notamment à préparer la migration d’une installation 24.04 LTS existante.

Identifier la version de départ et le chemin disponible

LTS signifie Long Term Support, ou prise en charge à long terme. Une mise à jour ordinaire remplace des paquets dans la version configurée ; une mise à niveau de version coordonne un changement beaucoup plus large. Commencez par cet état des lieux, sans modifier le système :

cat /etc/os-release
uname -r
df -h / /boot
df -i / /boot
apt-mark showhold
dpkg --audit
systemctl --failed --no-pager

Relevez VERSION_ID, l’architecture, le noyau actif, l’espace et les inodes disponibles. Une sortie vide de dpkg --audit est souhaitable, mais ne prouve pas que toutes les applications fonctionnent. Documentez les services déjà en échec afin de distinguer un problème ancien d’une régression après migration.

Les notes de version Ubuntu 26.04 LTS indiquent les versions de départ prévues. Pour suivre les LTS, passez de la LTS actuelle à la suivante : par exemple 22.04 vers 24.04, puis 24.04 vers 26.04. Ne remplacez pas directement les noms de suites dans les dépôts pour sauter une étape.

Lisez aussi le récapitulatif des changements destiné aux utilisateurs LTS, notamment les composants utilisés par votre serveur. La disponibilité effective peut être retardée ou suspendue ; la date du calendrier ne remplace pas le résultat de l’outil sur votre environnement.

Préparer une base de retour et des critères d’acceptation

1. Effectuez une sauvegarde indépendante et une restauration de contrôle. Incluez les données applicatives cohérentes, les secrets nécessaires et la possibilité de déchiffrer les copies.
2. Répétez la migration sur un clone de VM isolé, sans activer les mêmes adresses ou identités en concurrence avec la production. Coupez aussi les tâches susceptibles d’envoyer des notifications ou de modifier des services externes.
3. Confirmez la console de l’hyperviseur ou du fournisseur, le démarrage de secours, l’alimentation, la fenêtre d’intervention et une personne capable de restaurer. Une seconde session SSH ne remplace pas une console indépendante.
4. Inventoriez les dépôts tiers et modifications locales, versions d’applications, pilotes et modules particuliers. Vérifiez leur compatibilité avec la destination et prévoyez le traitement des sources désactivées.

Fixez avant de commencer les fonctions attendues, le temps maximal de diagnostic et le moment où revenir à la sauvegarde. Pour un site, il peut s’agir d’une nouvelle connexion SSH, d’une réponse HTTPS avec le bon certificat et d’une lecture puis écriture applicative de test. Un simple écran de connexion n’est pas un critère suffisant pour un serveur de fichiers ou une base de données.

Un instantané ne restaure pas automatiquement les données d’une base externe ni les actions déjà envoyées à un autre système. Définissez le périmètre cohérent du retour et les changements à préserver. Une rétrogradation ordinaire de quelques paquets n’annule pas de façon fiable toute une mise à niveau du système.

Mettre la version actuelle en état de migrer

Après les sauvegardes et pendant une fenêtre adaptée, actualisez les index puis simulez le traitement des dépendances. Le manuel APT précise que dist-upgrade peut retirer des paquets pour résoudre les changements de dépendances :

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

La simulation n’installe rien. Relisez les suppressions, changements de dépendances et paquets retenus ; une simulation lancée sans privilèges peut aussi ne pas accéder à tous les paramètres locaux. L’option d’inclusion des mises à jour échelonnées suit ici la préparation décrite par le guide Ubuntu de migration ; ce n’est pas une consigne générale pour accélérer les mises à jour quotidiennes.

Si les résultats sont compris et acceptables, lancez la véritable mise à jour, sans option d’acceptation automatique :

sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
test ! -e /run/reboot-required || cat /run/reboot-required

Attendez la fin normale du gestionnaire de paquets et vérifiez son résultat. Le guide officiel Ubuntu de mise à niveau demande une version de départ à jour. Redémarrez si nécessaire, puis confirmez que cette version fonctionne encore correctement avant de modifier la génération du système.

Une absence de marqueur reboot-required ne certifie pas à elle seule que tous les processus utilisent les bibliothèques nouvelles. Résolvez les paquets en état incohérent et les retenues selon leur cause ; ne supprimez pas les fichiers de verrouillage et ne retirez pas indistinctement toutes les retenues pour satisfaire l’outil.

Vérifier l’offre de migration sans la forcer

sudo apt install update-manager-core
grep -E '^Prompt=' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Pour un plan limité aux LTS, vérifiez Prompt=lts. Si une correction est nécessaire, sauvegardez d’abord le fichier dans un nouvel emplacement privé, puis éditez uniquement ce paramètre avec sudoedit. Une sortie grep vide demande une inspection ; elle ne justifie pas l’ajout de plusieurs lignes contradictoires.

Le manuel do-release-upgrade définit -c comme une vérification de disponibilité. La commande peut contacter les services de publication, mais ne lance pas la migration. Lisez le nom exact de la version proposée et contrôlez qu’il correspond au plan.

Si aucune nouvelle version n’est proposée, consultez les avis officiels et les conditions du système, puis attendez ou préparez une nouvelle installation avec transfert des données. N’utilisez pas -d comme solution générique : cette option vise une version de développement dans les conditions prévues par l’outil. Ne contournez pas non plus un blocage en réécrivant les suites APT.

Exécuter la mise à niveau de façon interactive

Sur le clone préparé, puis dans la fenêtre retenue pour la machine réelle, lancez :

sudo do-release-upgrade

Lisez les étapes avant de confirmer les changements. Vérifiez le résumé des installations et suppressions, l’espace requis et les services concernés. Une demande de traitement d’un fichier de configuration doit être jugée par sa différence réelle : conserver systématiquement l’ancienne version peut garder un réglage incompatible, tandis que tout remplacer peut effacer une adaptation nécessaire.

Si l’outil prévoit une session de secours ou un port SSH supplémentaire, lisez sa consigne exacte et limitez les accès aux adresses d’administration nécessaires dans tous les pare-feux concernés. Ne publiez pas arbitrairement ce port à tout Internet. Gardez la console ouverte et ne comptez pas uniquement sur le terminal qui exécute la migration.

Évitez de lancer un autre gestionnaire de paquets, de forcer l’arrêt ou de couper l’alimentation pendant le traitement. Si une erreur apparaît, conservez le texte affiché et les journaux de /var/log/dist-upgrade, notamment main.log, apt.log et term.log lorsqu’ils existent. Identifiez l’étape et l’état des paquets avant de recommencer ; n’accumulez pas des commandes de réparation choisies sans diagnostic.

Le redémarrage final fait partie de la vérification. S’il ne peut pas être effectué pendant la fenêtre disponible, la migration n’est pas encore acceptée : il reste à prouver que le nouveau noyau, le stockage et les services démarrent.

Accepter la nouvelle version à partir de preuves de fonctionnement

Après redémarrage, depuis la console, reprenez les observations et comparez-les à l’état initial :

cat /etc/os-release
uname -r
systemctl --failed --no-pager
dpkg --audit
ip -br address
ip route
resolvectl status
df -h / /boot
sudo journalctl -b -p warning --no-pager

Vérifiez ensuite une nouvelle connexion SSH depuis le client prévu, les montages attendus et la résolution des noms. Pour chaque application, utilisez un test fonctionnel connu : lire puis enregistrer une donnée de test, consulter HTTPS depuis l’extérieur, ouvrir un partage avec un compte autorisé, contrôler un conteneur et son volume. Adaptez la liste au serveur ; ne créez pas de fausses alertes ou de transactions réelles pour tester un service.

Réactivez un dépôt tiers seulement si son éditeur prend en charge la nouvelle version et si vous en avez encore besoin. Examinez les fichiers de configuration laissés pour comparaison et les pilotes particuliers. Reportez le nettoyage des anciens noyaux ou paquets jusqu’à la validation du fonctionnement et des moyens de secours.

Relancez les sauvegardes et mises à jour prévues, testez leur état, puis consignez version finale, problèmes rencontrés et critères d’acceptation. Si une fonction essentielle reste inutilisable au-delà du seuil décidé, appliquez le plan de retour cohérent en préservant les modifications à récupérer ; ne tentez pas une rétrogradation improvisée de l’ensemble du système.