Mise à jour de Fedora Linux à l’aide du plugin DNF

Michael Wu, Anthony McGlone, L'équipe Fedora Docs Version F38, F39, F40 Last review: 2024-04-25

La commande dnf system-upgrade (intégrée à DNF5 et au plugin dnf-plugin-system-upgrade pour le gestionnaire de paquets DNF4) sert à mettre à jour votre système vers la dernière version de Fedora Linux. Pour Fedora Silverblue et Fedora CoreOS, utilisant tous deux rpm-ostree, référez-vous à la documentation rpm-ostree pour connaître les détails.

Il s’agit de la méthode de mise à jour en ligne de commande recommandée. La mise à jour se déroule de la manière suivante :

  1. Les paquets sont téléchargés alors que le système s’exécute normalement.

  2. Le système redémarre dans un environnement spécial (implémenté sous la forme d’une cible systemd) pour les installer.

  3. Une fois la mise à jour terminée, le système redémarre dans la nouvelle version de Fedora Linux.

Exécution de la mise à jour du système

Effectuez une sauvegarde de vos données avant de démarrer la mise à jour de votre système. Toute mise à jour du système peut présenter des risques. Par précaution, téléchargez l’image Live Fedora Workstation. Elle vous sera utile si quelque chose venait à mal se passer.

  1. Pour mettre à jour votre version de Fedora Linux à partir de la ligne de commande, exécutez :

    sudo dnf upgrade --refresh

    et redémarrez votre ordinateur.

    Important : N’ignorez pas cette étape. Les mises à jour du système servent à récupérer les clés de signature des nouvelles versions de Fedora et permettent fréquemment de résoudre des problèmes liés au processus de mise à jour de Fedora.

  2. Téléchargez les paquets mis à jour :

    sudo dnf system-upgrade download --releasever=41

    Modifiez la valeur de --releasever si vous souhaitez mettre à jour vers une autre version de Fedora. Les utilisateur·rices souhaitent généralement mettre à jour vers la dernière version stable disponible (Fedora 41), mais il peut néanmoins être intéressant de mettre à jour vers Fedora Linux 40 – par exemple si vous utilisez actuellement une version de Fedora antérieure à la version 40. La mise à jour du système n’est prise en charge et testée qu’entre un maximum de deux versions (par exemple, de la 39 à la 41). Si vous êtes encore sur une version très ancienne, nous vous recommandons donc de mettre à jour Fedora par incréments de deux versions (en savoir plus).

    Vous pouvez également utiliser la valeur 42 pour mettre à jour vers une version Branched, ou rawhide pour mettre à jour vers Fedora Rawhide. Notez qu’aucune de ces deux versions n’est considérée comme stable. Pour connaître les détails relatifs au processus de mise à jour et les problèmes courants avec ces deux versions, consultez les sections appropriées des pages mentionnées précédemment.

  3. Si certains de vos paquets comportent des dépendances non résolues, la mise à jour ne pourra pas continuer tant que vous n’aurez pas ajouté l’option --allowerasing. Cela se produit fréquemment avec des paquets installés à partir de dépôts tiers n’ayant pas encore publié un dépôt mis à jour. Observez bien la sortie de la commande et examinez les paquets allant être supprimés. Aucun d’entre eux ne devrait être essentiel au bon fonctionnement du système, mais certains pourraient être importants dans vos travaux quotidiens.

    • Si vous observez des dépendances non satisfaites, vous pouvez parfois obtenir plus de détails en ajoutant l’option --best à la ligne de commande.

    • Si vous souhaitez installer ou supprimer des paquets manuellement avant d’exécuter dnf system-upgrade download à nouveau, il est conseillé d’effectuer ces opérations en définissant l’option --setopt=keepcache=1. Sinon, le cache des paquets sera supprimé à l’issue de chacune de vos opérations et vous devrez retélécharger l’ensemble des paquets.

  4. Lors de l’importation de la nouvelle clé GPG, on vous demande de vérifier l’empreinte de la clé. Pour ce faire, référez-vous à la page https://fedoraproject.org/fr/security.

  5. Déclenchez le processus de mise à jour. Cela redémarrera votre machine (immédiatement !, sans compte à rebours ni confirmation, donc fermez les autres programmes et enregistrez votre travail) dans le processus de mise à jour qui s’exécutera dans une console :

    sudo dnf system-upgrade reboot
  6. Une fois le processus de mise à jour achevé, votre système redémarrera une seconde fois dans la nouvelle version de Fedora Linux.

Tâches optionnelles à l’issue de la mise à jour

Voici certaines des tâches que vous pouvez effectuer à l’issue d’une mise à jour réussie.

Mettre à jour les fichiers de configuration du système

La plupart des fichiers de configuration sont stockés dans le répertoire /etc. Si vous avez modifié les fichiers de configuration des paquets, RPM crée de nouveaux fichiers portant l’extension .rpmnew (pour les nouveaux fichiers de configuration) ou .rpmsave (pour la sauvegarde de votre ancien fichier de configuration). Vous pouvez rechercher ces fichiers manuellement ou utiliser l’outil rpmconf qui simplifie ce processus. Pour installer rpmconf, saisissez :

sudo dnf install rpmconf

Une fois l’installation terminée, saisissez :

sudo rpmconf -a

Certains paquets tiers déposent des fichiers de configuration modifiés dans /etc/yum.repos.d/. La restauration de la version originale de ces fichiers pourrait désactiver les mises à jour de certains logiciels. Assurez-vous d’examiner avec soin les fichiers de configuration dans ce répertoire.

Pour plus d’informations, vous pouvez vous référer aux pages man (man rpmconf).

Si vous utilisez rpmconf pour mettre à jour les fichiers de configuration du système fournis avec les paquets mis à jour, certains fichiers de configuration peuvent être modifiés. À l’issue de la mise à jour, nous vous conseillons de vérifier au minimum les fichiers /etc/ssh/sshd_config, /etc/nsswitch.conf et /etc/ntp.conf. Par exemple, si OpenSSH est mis à jour, alors la configuration par défaut de sshd_config est rétablie. Cette configuration par défaut est issue du paquet et n’active pas l’authentification par clé publique et permet l’authentification par mot de passe.

Mettre à jour le bootloader GRUB sur les systèmes BIOS

Les paquets RPM GRUB des systèmes avec un micrologiciel BIOS sont mis à jour régulièrement. Néanmoins, le bootloader installé ou intégré n’est jamais mis à jour automatiquement. Il est souhaitable de le mettre à jour lors du passage d’une version de Fedora Linux à une autre.

Trouvez le nœud de périphérique fournissant le répertoire /boot/ :

sudo mount | grep "/boot "
/dev/sda4 on /boot type ext4 (rw,relatime,seclabel)

Ici, le nœud de périphérique est /dev/sda4. Réinstallez le bootloader en spécifiant le nœud de périphérique en omettant le nombre :

sudo grub2-install /dev/sda

La sortie correcte devrait être :

Installing for i386-pc platform.
Installation finished. No error reported.

Nettoyer les paquets abandonnés

À chaque nouvelle version de Fedora, des paquets sont abandonnés. Plusieurs raisons peuvent expliquer cela : les paquets deviennent obsolète, ils sont abandonnés upstream ou il n’y a plus personne pour s’occuper de la maintenance. Fedora ne distribue alors plus ces paquets ; néanmoins, ils restent sur votre système. Ils ne recevront plus de mises à jour, il est donc hautement recommandé de les supprimer.

Si vous passez d’une version à la suivante (par exemple, de Fedora Linux 40 à 41), exécutez les commandes suivantes :

sudo dnf install remove-retired-packages
remove-retired-packages

Si vous sautez une version (par exemple en passant de Fedora Linux 39 à 41), vous devez fournir la version de Fedora précédente à remove-retired-packages :

sudo dnf install remove-retired-packages
remove-retired-packages 39
Les mises à jour de Fedora de plus de deux versions à la fois ne sont pas prises en charge.

Nettoyer les anciens paquets

Vous pouvez connaître les paquets en double (avec plusieurs versions installées) avec :

sudo dnf repoquery --duplicates

Et vous pouvez les supprimer avec :

sudo dnf remove --duplicates

Avant toute chose, exécutez sudo dnf upgrade, car cette liste est valide uniquement si votre système est entièrement à jour. Sinon, la liste que vous obtiendrez contiendra des paquets qui ne font plus partie des dépôts car une mise à jour de ces paquets les remplace. Cette liste peut aussi contenir des paquets installés à partir de dépôts tiers qui peuvent ne pas être à jour.

Pour les paquets provenant des dépôts officiels, la dernière version doit être installée. Toutefois, certains paquets encore présents sur votre système peuvent ne plus être présents dans les dépôts. Pour obtenir une liste de ces paquets, exécutez :

sudo dnf list --extras

Si vous trouvez un paquet dont vous n’avez pas besoin, vous pouvez le supprimer avec :

sudo dnf remove $(sudo dnf repoquery --extras --exclude=kernel,kernel-\*)

Vous pouvez supprimer en toute sécurité les paquets qui ne sont plus utilisés avec :

sudo dnf autoremove

DNF décide qu’un paquet n’est plus nécessaire si vous ne lui avez pas demandé explicitement de l’installer et que rien d’autre ne le requiert. Cela ne signifie néanmoins pas que le paquet n’est pas utile ou que vous ne l’utilisez pas. Supprimez uniquement ce dont vous êtes sûr·e de ne pas avoir besoin.

Nettoyer les anciens noyaux

Après que vous ayez démarré sur le dernier noyau et testé le système, vous pouvez supprimer les noyaux précédents. Les anciens noyaux sont conservés même en utilisant dnf autoremove afin d’éviter les suppressions involontaires.

Une des manières les plus simples de supprimer les anciens noyaux consiste à utiliser un script qui conserve uniquement la dernière version du noyau. Le script ci-dessous fonctionne à chaque fois que Fedora met à jour le noyau et ne dépend pas d’une mise à jour du système.

#!/usr/bin/env bash

anciens_noyaux=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#anciens_noyaux[@]}" -eq 0 ]; then
    echo "Aucun ancien noyau trouve"
    exit 0
fi

if ! dnf remove "${anciens_noyaux[@]}"; then
    echo "Echec de la suppression des anciens noyaux"
    exit 1
fi

echo "Anciens noyaux supprimes"
exit 0

Nettoyer les anciennes clés de confiance pour la signature de paquets RPM

Les clés des versions antérieures de Fedora et des dépôts tiers s’accumulent au fil du temps dans la base de données RPM. Vous pouvez supprimer les clés qui ne sont plus référencées dans /etc/yum.repos.d/ avec :

sudo dnf install clean-rpm-gpg-pubkey
sudo clean-rpm-gpg-pubkey

Après une mise à jour, certains liens symboliques brisés pourraient demeurer dans le système de fichiers. Vous pouvez nettoyer ces liens symboliques en installant l’utilitaire symlinks et en les supprimant.

sudo dnf install symlinks

Une fois l’utilitaire installé, vous pouvez rechercher les liens symboliques brisés comme indiqué ci-dessous. -r signifie « récursif ».

sudo symlinks -r /usr | grep dangling

Après avoir passé en revue la liste des liens symboliques brisés, vous pouvez les supprimer comme indiqué ci-dessous. -d signifie « delete » (supprimer).

sudo symlinks -r -d /usr

Mettre à jour le noyau de secours

Le noyau et l’initramfs de secours sont générés par Anaconda durant l’installation du système. L’initramfs est mis à jour lors des mises à jour du noyau, mais le noyau de secours peut ne pas l’être. La mise à jour automatique du noyau de secours dépend de la configuration du système.

Si le noyau de secours est obsolète, vous pouvez utiliser les commandes suivantes pour le régénérer.

sudo rm /boot/*rescue*
sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"

Le processus de régénération du noyau de secours peut être automatisé en installant le paquet dracut-config-rescue.

sudo dnf install dracut-config-rescue

Une fois installé, le noyau de secours sera régénéré aussi longtemps que dracut sera le générateur d’initrd. Consultez /usr/lib/kernel/install.d/51-dracut-rescue.install pour connaître les détails.

Résolution des problèmes à la suite d’une mise à jour

Suivez ces étapes uniquement si vous rencontrez des problèmes avec votre système après avoir effectué une mise à jour de Fedora.

Reconstruction de la base de données RPM

Si vous observez des avertissements lors de l’utilisation d’outils RPM ou de DNF, votre base de données pourrait être corrompue. Il est possible de la reconstruire afin de voir si cela résout votre problème. Avant de commencer, assurez-vous d’avoir sauvegardé /var/lib/rpm/. Pour reconstruire la base de données, exécutez :

sudo rpm --rebuilddb

Utilisation de distro-sync pour résoudre des problèmes liés aux dépendances

L’outil de mise à jour du système utilise par défaut dnf distro-sync. Si votre système est mis à jour seulement en partie, ou que vous observez des problèmes liés aux dépendances, essayez d’exécuter manuellement une nouvelle distro-sync afin de voir si cela résout votre problème. Cette opération essaiera de faire correspondre la version des paquets installés et la version des dépôts actuellement activés, en autorisant l’installation de versions antérieures :

sudo dnf distro-sync

Vous pouvez aussi utiliser l’option --allowerasing qui supprimera les paquets avec des dépendances ne pouvant pas être satisfaites. Vérifiez toujours les paquets devant être supprimés avant de confirmer l’opération :

sudo dnf distro-sync --allowerasing

Réétiqueter les fichiers avec la dernière politique SELinux

Si vous rencontrez des avertissements relatifs à des politiques SELinux, il se peut que certains fichiers aient des autorisations SELinux incorrectes. Cela peut se produire si SELinux a été désactivé par le passé. Pour réétiqueter votre système, exécutez la commande suivante puis redémarrez :

sudo fixfiles -B onboot

Le processus de démarrage sera probablement long, car il s’agit de vérifier et de corriger les autorisations SELinux de l’ensemble des fichiers de votre système.

Foire aux questions

Comment signaler des problèmes liés à la mise à jour du système ?

  1. Consultez les Bugs courants pour savoir s’il s’agit d’un problème déjà connu par la communauté.

  2. Recherchez dans Bugzilla un bug signalé à propos de DNF5 ou du plugin DNF4.

Si vous ne trouvez pas de signalement correspondant à vos symptômes, vous pouvez en créer un nouveau depuis la page de recherche. Suivez les instructions relatives aux signalements de bug mentionnées dans le README du dépôt GitHub.

Si, après la mise à jour, vous rencontrez un problème avec un paquet spécifique, signalez le bug aux personnes développant le paquet en question.

DNF System Upgrade vérifie-t-il les logiciels exécutés ou installés pendant la mise à jour ?

Oui. Les clés de signature de paquets pour les nouvelles versions de Fedora Linux sont ajoutés aux anciennes versions pour permettre à DNF de vérifier l’intégrité des paquets téléchargés. Vous pouvez désactiver cette fonctionnalité si nécessaire, mais nous vous le déconseillons car cela vous ouvrirait à des attaques de logiciels malveillants.

Est-ce que les paquets des dépôts tiers seront mis à jour ?

Oui, s’ils sont configurés comme les dépôts DNF standards et si les numéros de version ne sont pas écrites en dur dans le fichier du dépôt (généralement stocké dans /etc/yum.repos.d/). Les dépôts tiers utilisés couramment tels que RPM Fusion devraient être compatibles. Toutefois, si vous essayez d’effectuer la mise à jour de Fedora avant ou juste après la sortie d’une nouvelle version officielle, les chemins des dépôts tiers pourraient ne pas avoir encore été mis à jour, et DNF pourrait ne pas être en mesure de trouver leurs paquets. Généralement, cela ne devrait pas empêcher le système de se mettre à jour correctement et, quoi qu’il arrive, vous pourrez mettre à jour les paquets tiers plus tard.

Puis-je mettre à jour Fedora à partir d’une version en fin de vie (EOL) ?

Il est fortement recommandé de mettre à jour les versions de Fedora en fin de vie s’exécutant sur tout système en production, ou tout système connecté à Internet.

Toute mise à jour de Fedora Linux à partir de la version 20 ou antérieure s’effectue à vos risques et périls, car DNF n’était pas l’outil de gestion de paquets par défaut. Toutefois, si vous exécutez une version de Fedora à partir de la 21 qui est en fin de vie, vous pouvez tenter de la mettre à jour, mais cette méthode n’est pas prise en charge. Vous pouvez essayer de mettre à jour en passant de version en version jusqu’à atteindre une version actuellement prise en charge, ou essayer de mettre à jour directement vers une version actuellement prise en charge. Une fois de plus, il s’agit d’une opération non prise en charge et qui est à vos risques et périls.

Puis-je mettre à jour Fedora de plusieurs versions en une seule fois (ex. 30→34) ?

Les mises à jour sont prises en charge quand il s’agit de mettre à jour vers la version de Fedora directement supérieure (par exemple de la 40 à la 41) ou en ignorant 1 version (par exemple de la 39 à la 41). Par contre, il est fortement recommandé d’effectuer la mise à jour avant que votre version de Fedora n’atteigne la fin de vie. Cela arrive généralement environ un mois après la sortie de la version N+2 (lorsque vous êtes sur la version N). Le cycle de vie des versions de Fedora est conçu spécifiquement pour permettre la présence d’une période de grâce d’un mois et de permettre aux utilisateur·rices de ne mettre à jour leurs systèmes qu’une fois par an (ou toutes les deux versions de Fedora). Vous pouvez consulter la page Releases pour connaître l’état actuel des versions de Fedora ainsi que le calendrier des mises à jour à venir. Environ un mois après la sortie de la nouvelle version, la version N-2 est alors considérée comme étant en fin de vie (EOL). La mise à jour vers une version supérieure de Fedora continuera à fonctionner après le passage en fin de vie, mais pour une durée inconnue.

Les mises à jour de Fedora de plus de deux versions ne sont pas prises en charge, et les problèmes émanant de telles mises à jour pourraient ne pas être considérés comme importants.

En effectuant une mise à jour de Fedora de plus de deux versions, il se peut que vous deviez importer la clé GPG de la version vers laquelle vous souhaitez effectuer la mise à jour. Vous pouvez l’importer avec :

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-N-primary

(avec N la version de Fedora Linux.)

Puis-je utiliser DNF System Upgrade pour passer à une préversion (ex. une version bêta) ?

Oui, mais l’opération est susceptible de ne pas fonctionner temporairement, comme tout autre aspect des préversions.