From Fedora Project Wiki
(mise à jour)
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
<span style="font-size:20px;">Mise à niveau du système avec la commande '''dnf system-upgrade'''</span>
{{autolang}}


=Mise à niveau du système avec DNF=
== Qu'est-ce que la mise à niveau du système avec la commande « dnf-system-upgrade » ? ==


[https://github.com/rpm-software-management/dnf-plugin-system-upgrade dnf-plugin-system-upgrade] est un greffon du gestionnaire de paquets [[Dnf|dnf]] qui prend en charge les mises à niveau du système. C'est la méthode de mise à niveau recommandée depuis Fedora 21.
== Qu’est-ce que la mise à niveau du système avec la commande '''dnf system-upgrade''' ? ==


== Que fait la commande « dnf system-upgrade » ? ==
[https://github.com/rpm-software-management/dnf-plugin-system-upgrade dnf-plugin-system-upgrade] est un greffon du gestionnaire de paquets [[Dnf|dnf]] qui prend en charge les mises à niveau du système. C’est la méthode de mise à niveau en ligne de commande recommandée depuis Fedora 21.


La commande ''dnf system-upgrade'' permet de passer votre système sur une nouvelle version de Fedora, en utilisant un mécanisme similaire à celui utilisé pour la mise à jour de paquets hors ligne. Les paquets à jour sont téléchargés alors que le système continue à fonctionner normalement, puis le système redémarre dans un environnement particulier (mis en œuvre en tant que cible systemd) pour les installer. Une fois l'installation terminée, le système redémarre à nouveau sur la nouvelle version de Fedora.
== Que fait la commande '''dnf system-upgrade''' ? ==


== Comment l'utiliser ? ==
La commande '''dnf system-upgrade''' permet de passer votre système sur une nouvelle version de Fedora, en utilisant un mécanisme similaire à celui utilisé pour la mise à jour de paquets hors ligne. Les paquets à jour sont téléchargés alors que le système continue à fonctionner normalement, puis le système redémarre dans un environnement particulier (mis en œuvre en tant que cible systemd) pour les installer. Une fois l’installation terminée, le système redémarre à nouveau sur la nouvelle version de Fedora.
 
== Comment l’utiliser ? ==


<ol>
<ol>
<li> '''Back up''' your important data. Every system change is potentially risky, be prepared. In case you update your workstation, it is also wise to download a [https://getfedora.org/en/workstation/ Workstation Live image] and make sure your hardware (graphics card, wifi, etc) works well with the latest kernel and drivers.
<li> '''Faites une sauvegarde''' de vos données importantes. Tout changement sur le système est potentiellement à risques ; préparez-vous à toute éventualité ! Dans le cas où vous mettez votre station de travail à niveau, il est aussi recommandé de téléchager une [https://getfedora.org/en/workstation/ Image live de Fedora Workstation ] et de vous assurer que votre matériel (cartes graphiques, cartes wifi, etc.) fonctionne correctement avec le dernier noyau et les derniers pilotes.
<li> Update your system using the standard updater for your desktop or {{command|dnf}}:
<li> Mettez votre système à jour en utilisant le système de mise à jour standard pour votre ordinateur ou {{command|dnf}}:
<pre>$ sudo dnf upgrade --refresh</pre>
<pre>$ sudo dnf upgrade --refresh</pre>
It is recommended to reboot the computer, especially if you've just installed a new kernel.<br>
N’écrivez pas ''$'' dans ces commandes, cela indique simplement que ce que vous saisissez  est l’invite de commande d’un utilisateur non root.
 
Après la mise à jour, il est recommandé de redémarrer votre ordinateur ; en particulier si vous venez d’installer un nouveau noyau.<br>
<ul>
<ul>
<li>Please note that there is [[Common_F23_bugs#plymouth-theme-upgrade|an issue]] if you use a non-default plymouth boot theme. If you do, please follow the issue description to make sure your upgrade will not be affected.
<li>Veuillez noter qu’il y a [[Common_F23_bugs#plymouth-theme-upgrade|un problème]] lorsque vous utilisez un thème de démarrage qui n’est pas le thème plymouth par défaut. Si c’est votre cas, lisez la description du problème pour savoir s’il n’affectera pas votre mise à niveau.
<li>Double check your DNF configuration in {{filename|/etc/dnf/dnf.conf}}, if you have done any custom configuration (either manually or via third-party tool), it's recommended to revert it to default before updating and upgrading your system.
<li>Vérifiez attentivement votre configuration de DNF dans le fichier {{filename|/etc/dnf/dnf.conf}}. Si vous avez effectué des personnalisations (qu’elles soient manuelles ou par l’intermédiaire de tierces parties), il est recommandé de revenir à la configuration par défaut avant de mettre votre système à jour et à niveau.
</ul>
</ul>
<li> Install {{package|dnf-plugin-system-upgrade}} package:
<li> Installez le paquet {{package|dnf-plugin-system-upgrade}} :
<pre>$ sudo dnf install dnf-plugin-system-upgrade</pre>
<pre>$ sudo dnf install dnf-plugin-system-upgrade</pre>
<li> Download the updated packages:
<li> Téléchargez les paquets à jour :
{{#tag:pre|$ sudo dnf system-upgrade download --refresh --releasever={{FedoraVersionNumber}}}}
{{#tag:pre|$ sudo dnf system-upgrade download --refresh --releasever={{FedoraVersionNumber}}}}
Change the <code>--releasever=</code> number if you want to upgrade to a different system release. Most people will want to upgrade to the latest stable release, which is '''{{FedoraVersionNumber}}''', but if you're running Fedora {{FedoraVersionNumber|previous2}}, you might want to upgrade just to Fedora {{FedoraVersionNumber|previous}}. You can also use <code>{{FedoraVersionNumber|next}}</code> for upgrading to [[Branched]] or <code>rawhide</code> for upgrading to [[Rawhide]] (warning: those are not stable releases).
Modifiez le numéro de version <code>--releasever=</code> si vous désirez passer à une version différente. La plupart de gens désirent passer à la dernière version stable, qui est '''{{FedoraVersionNumber}}''', mais si vous utilisez actuellement Fedora {{FedoraVersionNumber|previous2}}, il se peut que vous vouliez passer à Fedora {{FedoraVersionNumber|previous}}. Vous pouvez aussi utiliser <code>{{FedoraVersionNumber|next}}</code> pour une mise à niveau vers [[Branched]] ou <code>rawhide</code> pour une mise à niveau vers [[Rawhide]] (attention : ces versions ne sont pas stables).
<ul>
<ul>
<li>If some of your packages have unsatisfied dependencies, the upgrade will refuse to continue until you run it again with an extra {{code|--allowerasing}} option. This often happens with packages installed from third-party repositories for which an updated repositories hasn't been yet published. Please study very careful the output and examine which packages are going to be removed. None of them should be essential for system functionality, but some of them might be important for your productivity.
<li>Si vous passez à Rawhide, vous devrez importer la clef GPG rpm correspondante. Cela sera le plus grand numéro de clef de version dans {{filename|/etc/pki/rpm-gpg/}}. Par exemple, si la version {{FedoraVersionNumber|next}}  est embranchée, alors vous devrez chercher {{FedoraVersionNumber|next2}}, s'il n'y a aucune version embranchée alors cela sera {{FedoraVersionNumber|next}}.
<li>In case of unsatisfied dependencies, you can sometimes see more details if you add {{code|--best}} option to the command line.
 
{{#tag:pre|$ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-{{FedoraVersionNumber|next2}}-primary}}
</ul>
<li>Si certains de vos paquets ont des dépendances non satisfaites, la mise à niveau s’arrêtera jusqu’à ce que vous la redemandiez en ajoutant l’option {{code|--allowerasing}} à la commande. Cela se produit souvent avec des paquets installés depuis des dépôts de tierces parties pour lesquels un dépôt à jour n’a pas encore été publié. Étudiez attentivement la sortie de la commande et examinez les paquets qui vont être retirés. Aucun d’entre-eux ne devrait être essentiel pour assurer le fonctionnement attendu de votre système, mais certains peuvent jouer significativement sur votre productivité.  
<li>Dans le cas de dépendances non satisfaites, vous pouvez obtenir plus de détails en ajoutant l’option {{code|--best}} à la commande.
</ul>
</ul>
<li>Trigger the upgrade process:
<li>Déclenchez le processus de mise à niveau :
<pre> $ sudo dnf system-upgrade reboot</pre>
<pre>$ sudo dnf system-upgrade reboot</pre>
This will reboot your machine immediately. The system should boot again into Fedora using the same kernel, but this time, the upgrade process appears on the boot screen.
Cela provoque un redémarrage immédiat de votre machine. Le système devrait redémarrer à nouveau sur Fedora en utilisant le même noyau, mais cette fois le processus de mise à niveau est signalé sur l’écran de démarrage.
<li> Wait for the upgrade process to complete.
<li> Attendez que le processus de mise à niveau se termine.
</ol>
</ol>


== Frequently Asked Questions ==
== Questions fréquentes ==


=== How do I report issues that I find with upgrades? ===
=== Comment puis-je signaler les anomalies rencontrées lors d’une mise à niveau ? ===
First see [[Common F{{FedoraVersionNumber}} bugs]] or [[Common F{{FedoraVersionNumber|next}} bugs]] to check if the problem is a very prominent issue we already know of. If it is not there, [https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=dnf-plugin-system-upgrade&resolution=--- search for an existing bug report]. If you do not see a report that matches your symptoms, you can file a new report from the search page. Please follow the bug reporting instructions mentioned in [https://github.com/rpm-software-management/dnf-plugin-system-upgrade this README] and in <code>man dnf.plugin.system-upgrade</code>.
En premier lieu, consultez [[Common F{{FedoraVersionNumber}} bugs]] ou [[Common F{{FedoraVersionNumber|next}} bugs]] pour vérifier que le problème n’est pas un problème important déjà connu. Si ce n’est pas le cas, [https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=dnf-plugin-system-upgrade&resolution=--- faites une recherche sur les anomalies existantes]. Si vous ne trouvez aucune anomalie qui corresponde à vos symptômes, vous pouvez remplir un rapport d’anomalie depuis la page de recherche. Suivez les instructions sur la manière de rapporter une anomalie indiquées sur ce fichier [https://github.com/rpm-software-management/dnf-plugin-system-upgrade README] et sur <code>man dnf.plugin.system-upgrade</code>.


If you hit issues after upgrade with a specific package, file a bug against the package with which you are having issues.
Si vous rencontrez des problèmes après la mise à niveau avec un paquet particulier, remplissez un rapport d’anomalie sur ce paquet.


=== Does DNF system upgrade verify the software it runs or installs during upgrade? ===
=== Est-ce que la commande '''dnf system-upgrade''' vérifie les programmes qu’elle exécute ou installe durant la mise à niveau ? ===


Yes. The package signing keys for newer Fedora releases are sent to older Fedora releases in order to allow DNF to verify the integrity of the packages it downloads. You can disable this function with the {{code|--nogpgcheck}} parameter if you need to do so for any reason (not recommended, you're then opened to attacks from malicious software).
Oui. Les clés de signature de paquets pour les versions nouvelles de Fedora sont envoyées aux anciennes versions afin de permettre à ''dnf'' de vérifier l’intégrité des paquets qu’il télécharge. Vous pouvez désactiver cette fonction avec le paramètre  {{code|--nogpgcheck}} si besoin (cela n’est pas recommandé car vous êtes sujet aux attaques par des logiciels malicieux).  


=== Will packages in third party repositories be upgraded? ===
=== Est-ce que les paquets en provenance des dépôts de tierces parties sont mis à niveau ? ===


Yes, if they are set up like regular DNF repositories and do not hard code the repository path. Commonly-used third party repositories usually work fine, but if you attempt to upgrade prior to or soon after an official Fedora release, they may not have updated their repository paths yet, and DNF may be unable to find their packages. This will usually not prevent the upgrade running successfully, though, and you can update the packages from the third-party repository later.
Oui, si ces dépôts sont configurés comme des dépôts dnf normaux et ne codent pas en dur le chemin du dépôt. Les dépôts de tierces parties d’usage courant fonctionnent en général très bien, mais si vous essayez de mettre à niveau avant, ou juste après, une nouvelle parution de Fedora, il est possible que les chemins vers ces dépôts n’aient pas encore été mis à jour et que Fedora ne parvienne pas à trouver les paquets. Cela empêche généralement la mise à niveau de Fedora, bien que vous puissiez faire la mise à jour des paquets en provenance de ces dépôts ultérieurement.  


{{anchor|eol}}
{{anchor|eol}}
=== Can I upgrade from an [[End of life]] release? ===


Note that Fedora strongly recommends against ever running an end-of-life release on any production system, or any system connected to the public internet, in any circumstances. You should never allow a production Fedora deployment to reach end-of-life in the first place.
=== Puis-je effectuer une mise à niveau à partir d’une version  [[End of life|en fin de vie ]] ? ===


With that in mind, if you do have an end-of-life release newer than Fedora 20 installed on a system you cannot just discard or re-deploy, you can attempt to upgrade it, though this is a less-tested and less-supported operation. You can try to upgrade through intermediate releases until you reach a currently-supported release, or try to upgrade to a currently-supported release in a single operation. It is not possible to state with certainty which approach is more likely to be successful.
Notez bien que Fedora vous déconseille fortement d’exécuter une version en fin de vie sur un système en production, ou sur un système connecté à l’Internet quelles qu’en soient les circonstances. D’abord et avant tout, vous ne devriez jamais permettre à un déploiement de Fedora d’atteindre la version fin de vie.


If you attempt to upgrade across more than two releases in one operation, please also read the [[#multi|next answer]].
Ceci dit, si vous êtes sur une version de fin de vie plus récente que Fedora 20, et que vous ne pouvez pas vous contenter de simplement la laisser de côter ou de la redéployer, vous pouvez essayer de la mettre à niveau bien que ce soit une opération moins testée et pour laquelle vous obtiendrez moins d’assistance. Vous pouvez essayer de monter de version en version jusqu’à atteindre la version courante, ou essayer d’atteindre la version courante en une seule opération. Il est difficile de dire avec certitude laquelle de ces deux solutions a le plus le chance d’aboutir.  


If you have Fedora 20 or earlier installed, you cannot upgrade with DNF system upgrade alone. You must upgrade at least part of the way [[Upgrading_Fedora_using_package_manager|using bare {{command|dnf}} or {{command|yum}}]]. You can either upgrade to Fedora 21 that way and then upgrade the rest of the way using DNF system upgrade, or you can attempt the entire upgrade using bare {{command|dnf}} or {{command|yum}}. Note this method is in itself not an officially recommended upgrade mechanism. To be frank, any upgrade from Fedora 20 or earlier is very much done 'at your own risk'.
Si vous essayer de mettre à niveau à travers plus de deux versions en une seule opération, lisez aussi la [[#multi|réponse suivante]].
 
Si vous utilisez Fedora 20 ou une version antérieure, vous ne pouvez pas mettre à niveau avec ''dnf system-upgrade'' seulement. Vous devez mettre à niveau au moins une partie du chemin en  utilisant [[Upgrading_Fedora_using_package_manager|la commande nue {{command|dnf}} ou {{command|yum}}]]. Vous pouvez soit mettre au niveau de Fedora 21 de cette façon et mettre le reste à niveau avec ''dnf system-upgrade'', soit essayer de mettre à niveau le tout uniquement avec la commande nue {{command|dnf}} ou {{command|yum}}. Notez que cette méthode n’est pas en soi une méthode officielle recommandée pour la mise à niveau. Pour être franc, toute mise à niveau depuis Fedora 20, ou depuis une version antérieure, se fait à vos risques et périls.


{{anchor|multi}}
{{anchor|multi}}
=== How many releases can I upgrade across at once? ===


The most common scenario is an upgrade across just one release (e.g. {{FedoraVersion|long|previous}} to {{FedoraVersion|long}}). However, for the first month or so after a new release comes out, upgrades from the last-but-one release to that release are 'supported', in the sense that we include this scenario in the [[Fedora Release Criteria]], test it for at least clean installs of supported package sets, and will treat bugs discovered in such upgrades as significant. The [[Fedora Release Life Cycle]] is specifically designed to provide this approximate one month 'grace period' so you can choose to upgrade long-lived systems only once every two releases, rather than having to do it every release.
=== De combien de versions puis-je monter en niveau en une seule opération ? ===
 
Le scénario le plus courant est de monter d’une version (p. ex. de {{FedoraVersion|long|previous}} à {{FedoraVersion|long}}). Néanmoins, durant le premier mois environ après la parution d’une nouvelle version, des mises à jour depuis l’antépénultième version sont prises en charge, dans le sens où nous incluons ce scénario dans les  [[Fedora Release Criteria| critères de parution de Fedora]], en assurons le test au moins pour des installations propres des jeux de paquets pris en charge, et regarderons les rapports d’anomalies pour de telles mises à niveau comme importants. Le [[Fedora Release Life Cycle| cycle de vie des versions de Fedora]] est spécialement conçu pour fournir cette 'durée de grâce' approximative d’un mois, de manière à ce que vous puissiez choisir de ne réaliser des mises à niveau que sur des versions à longue durée de vie, une version sur deux, plutôt que sur chacune des versions.  


Around a month after the new release comes out, the last-but-one release goes [[End of life]], at which point the [[#eol|previous question]] applies. Still, that upgrade is still pretty likely to work successfully for some time after the release goes end-of-life.
Environ un mois après la parution de la nouvelle version, l’antépénultième version passe en [[End of life| fin de vie]], point auquel la [[#eol|question précédente]] se pose. Par ailleurs, cette mise à niveau est encore susceptible de fonctionner correctement durant quelques temps après le passage en fin de vie.


Upgrades across more than two releases are not 'supported', and issues encountered in such upgrades may not be considered significant bugs. Note that any upgrade across more than two releases must by definition be an upgrade from an end-of-life release, and so the [[#eol|previous question]] applies here too.
Les mises à niveau effectuant un saut de numéro de version supérieur à 2 ne sont pas prises en charge, et les problèmes rencontrés ne seront probablement pas considérés comme importants. Notez que toute mises à niveau avec un saut de numéro de version supérieur à 2 sont par définition des mises à niveau depuis une version en fin de vie, et qu’en conséquence, la [[#eol|question précédente]] se pose également ici.


When upgrading across multiple releases, you may find you need to [[Upgrading_Fedora_using_package_manager#packagekey|import the target release package signing key manually]]. Fedora releases usually only have the package signing keys for the next two releases installed (because they go end-of-life before the N+3 release is branched). Before Fedora 22, it was not consistently the case that every release had keys for the next two releases, either. If dnf complains about a missing key, this is what you must do.
Lors d’une mise à jour sautant plusieurs numéros de version, il est possible que vous deviez [[Upgrading_Fedora_using_package_manager#packagekey|importer la clé de signature des paquets de la version cible à la main]]. Les versions de Fedora disposent en général des clés de signature des paquets pour les deux versions suivantes (parce qu’elles passent en fin de vie avant que la version N+3 ne soit ''branched''). Avant Fedora 22, ce n’était pas toujours le cas que chacune des versions disposât des clés pour les deux versions suivantes. Si ''dnf'' se plaint à propos d’une clé manquante, c’est ce que vous devez faire.


=== Can I use DNF system upgrade to upgrade to a pre-release (e.g. a Beta)? ===
=== Puis-je utiliser '''dnf system-upgrade''' pour passer au niveau d’une pré-version (p. ex. une version Beta) ? ===


Yes. It should always be possible to attempt such an upgrade. Of course, this function is as subject to temporary breakage as is any other aspect of a pre-release, and generally speaking, the earlier the release in question, the less likely it is to work without problems.
Oui. Il devrait toujours être possible d’essayer une telle mise à niveau. Bien sûr, cette fonction est sujette à des plantages temporaires comme tous les autres aspects d’une pré-version, et en général, plus la version en question est jeune, plus un fonctionnement sans problème est improbable.


== Optional post-upgrade tasks ==
== Tâches facultatives d’après mise à niveau ==


These are tasks you can do after a successful upgrade. '''They are mostly intended for power users. If you are a general user who doesn't use terminal daily, you don't need to worry about this.'''
Il y a des tâches que vous pouvez réaliser après une mise à niveau réussie. '''Elles concernent essentiellement les utilisateurs chevronnés. Si vous êtes un utilisateur de base qui ne fait pas un usage quotidien du terminal, vous pouvez les ignorer.'''


=== Update system configuration files ===
=== Mise à jour des fichiers de configuration ===


Most configuration files are stored in <code>/etc</code>. If there are any updates to them and you touched some of those files before, RPM creates new files with either <code>.rpmnew</code> suffix (the new default config file), or <code>.rpmsave</code> suffix (your old config file backed up). You can search for these files, go through the changes and make sure your custom changes are still included and the new defaults are applied as well. A tool that tried to simplify this is {{pkg|rpmconf}}. Install the package, and then use it as:
La plupart des fichiers de configuration sont stockés dans le dossier <code>/etc</code>. Si plusieurs de ces fichiers sont mis à jour et que vous les avez modifiés auparavant, RPM crée de nouveaux fichiers, soit avec le suffix  <code>.rpmnew</code> (le nouveau fichier de configuration par défaut), soit avec le suffixe <code>.rpmsave</code> (la sauvegarde de votre ancien fichier de configuration). Vous pouvez rechercher ces fichiers, examiner les changements et vous assurer que vos personnalisations sont encore incluses, et que les nouvelles valeurs par défaut sont appliquées elles aussi. Un outil qui essaye de simplifier cette tâche est {{pkg|rpmconf}}. Installez le paquet et utilisez le avec :  
$ sudo rpmconf -a
<pre>$ sudo rpmconf -a</pre>
See more information in its manual page.  
Lisez la page de manuel de ce paquet pour plus d’information.


=== Clean up old packages ===
=== Se débarrasser des paquets inutiles ===


You can see list of packages with broken dependencies like this:
Vous pouvez obtenir une liste des paquets avec des dépendances cassées avec la commande suivante :
$ sudo dnf repoquery --unsatisfied
<pre>$ sudo dnf repoquery --unsatisfied</pre>
Ideally there should be none. If there are some, consider removing them, because they are not likely to work properly anyway.
Idéalement, il ne devrait pas y en avoir. S’il en existe, envisagez de les supprimer parce qu’ils ont peu de chances de fonctionner correctement..


You can see duplicated packages (packages with multiple versions installed) like this:
Vous pouvez voir les paquets en double (les paquets installés en plusieurs versions) avec la commande suivante :
$ sudo dnf repoquery --duplicated
<pre>$ sudo dnf repoquery --duplicated</pre>
For ordinary packages, just the latest version should be installed. But there can be exceptions to the rule, only remove what you are sure you no longer need.
Pour les paquets ordinaires, seule la dernière version devrait être installée. Il existe cependant des exceptions à la règle, c’est pourquoi vous ne devez supprimer que les paquets dont vous n’avez à coup sûr plus besoin.


Some packages might stay on your system while they have been removed from the repositories. See them using:
Certains paquets peuvent subsister dans votre système alors qu’ils sont retirés des dépôts. Vous pouvez en obtenir la liste avec la commande :
$ sudo dnf list extras
<pre>$ sudo dnf list extras</pre>
If you don't use these, you can consider removing them. Please note that this list is only valid if you have a fully updated system. Otherwise you'll see all installed packages which are no longer in the repositories, because there is a newer update available. So before acting on these, make sure you have run <code>sudo dnf update</code> and generate the list of extra packages again. Also, this list might contain packages installed from third-party repositories for which an updated repository hasn't been published yet. This often involves e.g. RPM Fusion or Dropbox.
Si vous n’utilisez pas ces fichiers, vous pouvez envisager de les supprimer. Notez bien que cela n’est valide que si vous avez un système complètement à jour. Autrement vous verrez tous les paquets qui ne sont plus dans les dépôts parce qu’une nouvelle version est disponible. C’est pourquoi, avant de les supprimer, assurez-vous d’avoir exécuté la commande <code>$ sudo dnf update</code> et recherchez à nouveau cette liste de paquets. De plus, cette liste peut comprendre des paquets installés depuis de dépôts de tierces parties pour lesquels un dépôt à jour n’a pas encore été publié. Cela est souvent le cas pour des dépôts tels que  RPM Fusion ou Dropbox.


You can remove no-longer-needed packages using:
Vous pouvez retirer les paquets qui ne sont plus nécessaires avec la commande :
$ sudo dnf autoremove
<pre>$ sudo dnf autoremove</pre>
but '''beware''' that dnf decides that a package is no longer needed if you haven't explicitly asked to install it and nothing else requires it. That doesn't mean that package is not useful or that you don't use it. '''Only remove what you are certain you don't need'''. There's a known bug in PackageKit which doesn't mark packages as user-installed, see [https://bugzilla.redhat.com/show_bug.cgi?id=1259865 bug 1259865]. If you use PackageKit (or GNOME Software, Apper, etc) for installation, this output might list even important apps and system packages, so beware.
mais  '''soyez conscient''' que dnf decide qu’un paquet n’est plus nécessaire si vous n’en avez pas explicitement demandé l’installation et que rien ne le requiert plus.Cela ne signifie pas que ce paquet est inutile ou que que vous ne l’utilisez pas. '''Ne retirez que les paquets dont vous n’avez à coup sûr plus besoin.''' Il y a une anomalie connue dans PackageKit qui ne marque pas des paquets comme installés par l’utilisateur (voir [https://bugzilla.redhat.com/show_bug.cgi?id=1259865 l’anomalie 1259865]. Si vous utilisez PackageKit (ou GNOME, Apper, etc.) pour installer, cette sortie peut même lister des applications importantes et des paquets systèmes. Donc soyez en conscient et vigilant.


== Resolving post-upgrade issues ==
== Résolution des problème post-installation ==


'''Only follow up these steps if you have troubles with your upgraded system. It should not be needed in the vast majority of upgrades.'''
'''Ne suivez ces instructions que si vous rencontrez des problèmes avec votre système mis à niveau. Elles ne devraient pas être nécessaires dans la grande majorité des cas de mise à niveau.'''


=== Rebuilding RPM database ===
=== Reconstruction de la base de données RPM ===


If you see warnings when working with RPM/DNF tools, your database might have gotten corrupted for some reason. It is possible to rebuild it and see if resolves your issues. Always back up <code>/var/lib/rpm/</code> first. To rebuild the database, run:
Si vous apercevez des messages d’avertissement lorsque vous travaillez avec les outils RPM/DNF, votre base de données peut avoir été corrompue pour une raison ou pour une autre. Il est possible de la reconstruire et de voir si cela résout vous problèmes. Faites toujours une sauvegarde de <code>/var/lib/rpm/</code> avant toute chose. Pour reconstruire la base de données, exécutez :
$ sudo rpm --rebuilddb
<pre>$ sudo rpm --rebuilddb</pre>


=== Using distro-sync to resolve dependency issues ===
=== Utilisation de  ''distro-sync'' pour résoudre les problèmes de dépendances ===


The system upgrade tool uses distro-sync method by default. If your system stayed partly unupgraded or you see some package dependency issues, you might try to fix it by running another distro-sync manually. This tries to make your installed packages exactly the same version as in currently enabled repositories, even if it meant downgrading some packages:
L’outil de mise à niveau du système utilise la méthode ''distro-sync'' par défaut. Si votre système n’est pas totalement mis à jour, ou si certains paquets présentent des problèmes de dépendances, vous pouvez essayer de les résoudre en exécutant à nouveau la commande ''distro-sync'' à la main. Cela essaye de mettre vos paquets installés à exactement la même version que celles des dépôts courants, même si cela conduit à rétrograder certains paquets :  
$ sudo dnf distro-sync
<pre>$ sudo dnf distro-sync</pre>


A stronger variant also allows to remove package for which package dependencies can't be satisfied. Always carefully review which packages are going to be removed before confirming this:
Une variante plus radicale autorise également le retrait des paquets pour lesquelles certaines dépendances ne peuvent être satisfaites. Passez toujours en revue avec la plus grande attention quels paquets vont être retirés avant de confirmer cette commande:
$ sudo dnf distro-sync --allowerasing
<pre>$ sudo dnf distro-sync --allowerasing</pre>


=== Relabel files with latest SELinux policy ===
=== Ré-étiqueter les fichiers avec la dernière politique SELinux ===


If you see warnings that some actions were not allowed because of current SELinux policy, it might be a case of having some files incorrectly label with SELinux permissions. This might happen in case of some bug or if you had SELinux disabled in some point of time in the past. You can relabel the whole system by running:
Si vous apercevez des messages d’avertissement vous disant que certaines actions n’ont pas été autorisées à cause de la politique SELinux courante, il est possible que certains fichiers aient été incorrectement étiquetés avec les permissions SELinux. Cela peut se produire dans le cas de certaines anomalies ou si vous avez SELinux désactivé durant certains moments du passé. Vous pouvez ré-étiqueter le système entier en exécutant :
$ sudo touch /.autorelabel
<pre>$ sudo touch /.autorelabel</pre>
and rebooting. The next boot will take a long time and will check and fix all SELinux labels on all your files.
et en redémarrant. Le prochain redémarrage prendra beaucoup de temps et vérifiera et corrigera toutes les étiquettes SELinux de tous vos fichiers.

Latest revision as of 15:14, 3 July 2017

Mise à niveau du système avec la commande dnf system-upgrade


Qu’est-ce que la mise à niveau du système avec la commande dnf system-upgrade ?

dnf-plugin-system-upgrade est un greffon du gestionnaire de paquets dnf qui prend en charge les mises à niveau du système. C’est la méthode de mise à niveau en ligne de commande recommandée depuis Fedora 21.

Que fait la commande dnf system-upgrade ?

La commande dnf system-upgrade permet de passer votre système sur une nouvelle version de Fedora, en utilisant un mécanisme similaire à celui utilisé pour la mise à jour de paquets hors ligne. Les paquets à jour sont téléchargés alors que le système continue à fonctionner normalement, puis le système redémarre dans un environnement particulier (mis en œuvre en tant que cible systemd) pour les installer. Une fois l’installation terminée, le système redémarre à nouveau sur la nouvelle version de Fedora.

Comment l’utiliser ?

  1. Faites une sauvegarde de vos données importantes. Tout changement sur le système est potentiellement à risques ; préparez-vous à toute éventualité ! Dans le cas où vous mettez votre station de travail à niveau, il est aussi recommandé de téléchager une Image live de Fedora Workstation et de vous assurer que votre matériel (cartes graphiques, cartes wifi, etc.) fonctionne correctement avec le dernier noyau et les derniers pilotes.
  2. Mettez votre système à jour en utilisant le système de mise à jour standard pour votre ordinateur ou dnf: 
    $ sudo dnf upgrade --refresh

    N’écrivez pas $ dans ces commandes, cela indique simplement que ce que vous saisissez est l’invite de commande d’un utilisateur non root.

    Après la mise à jour, il est recommandé de redémarrer votre ordinateur ; en particulier si vous venez d’installer un nouveau noyau.

    • Veuillez noter qu’il y a un problème lorsque vous utilisez un thème de démarrage qui n’est pas le thème plymouth par défaut. Si c’est votre cas, lisez la description du problème pour savoir s’il n’affectera pas votre mise à niveau.
    • Vérifiez attentivement votre configuration de DNF dans le fichier /etc/dnf/dnf.conf. Si vous avez effectué des personnalisations (qu’elles soient manuelles ou par l’intermédiaire de tierces parties), il est recommandé de revenir à la configuration par défaut avant de mettre votre système à jour et à niveau.
  3. Installez le paquet Package-x-generic-16.pngdnf-plugin-system-upgrade : 
    $ sudo dnf install dnf-plugin-system-upgrade
  4. Téléchargez les paquets à jour : 
    $ sudo dnf system-upgrade download --refresh --releasever=39

    Modifiez le numéro de version --releasever= si vous désirez passer à une version différente. La plupart de gens désirent passer à la dernière version stable, qui est 39, mais si vous utilisez actuellement Fedora 37, il se peut que vous vouliez passer à Fedora 38. Vous pouvez aussi utiliser 40 pour une mise à niveau vers Branched ou rawhide pour une mise à niveau vers Rawhide (attention : ces versions ne sont pas stables).

    • Si vous passez à Rawhide, vous devrez importer la clef GPG rpm correspondante. Cela sera le plus grand numéro de clef de version dans /etc/pki/rpm-gpg/. Par exemple, si la version 40 est embranchée, alors vous devrez chercher 41, s'il n'y a aucune version embranchée alors cela sera 40. 
      $ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-41-primary
  5. Si certains de vos paquets ont des dépendances non satisfaites, la mise à niveau s’arrêtera jusqu’à ce que vous la redemandiez en ajoutant l’option --allowerasing à la commande. Cela se produit souvent avec des paquets installés depuis des dépôts de tierces parties pour lesquels un dépôt à jour n’a pas encore été publié. Étudiez attentivement la sortie de la commande et examinez les paquets qui vont être retirés. Aucun d’entre-eux ne devrait être essentiel pour assurer le fonctionnement attendu de votre système, mais certains peuvent jouer significativement sur votre productivité.
  6. Dans le cas de dépendances non satisfaites, vous pouvez obtenir plus de détails en ajoutant l’option --best à la commande.
  7. Déclenchez le processus de mise à niveau : 
    $ sudo dnf system-upgrade reboot

    Cela provoque un redémarrage immédiat de votre machine. Le système devrait redémarrer à nouveau sur Fedora en utilisant le même noyau, mais cette fois le processus de mise à niveau est signalé sur l’écran de démarrage.

  8. Attendez que le processus de mise à niveau se termine.

Questions fréquentes

Comment puis-je signaler les anomalies rencontrées lors d’une mise à niveau ?

En premier lieu, consultez Common F39 bugs ou Common F40 bugs pour vérifier que le problème n’est pas un problème important déjà connu. Si ce n’est pas le cas, faites une recherche sur les anomalies existantes. Si vous ne trouvez aucune anomalie qui corresponde à vos symptômes, vous pouvez remplir un rapport d’anomalie depuis la page de recherche. Suivez les instructions sur la manière de rapporter une anomalie indiquées sur ce fichier README et sur man dnf.plugin.system-upgrade.

Si vous rencontrez des problèmes après la mise à niveau avec un paquet particulier, remplissez un rapport d’anomalie sur ce paquet.

Est-ce que la commande dnf system-upgrade vérifie les programmes qu’elle exécute ou installe durant la mise à niveau ?

Oui. Les clés de signature de paquets pour les versions nouvelles de Fedora sont envoyées aux anciennes versions afin de permettre à dnf de vérifier l’intégrité des paquets qu’il télécharge. Vous pouvez désactiver cette fonction avec le paramètre --nogpgcheck si besoin (cela n’est pas recommandé car vous êtes sujet aux attaques par des logiciels malicieux).

Est-ce que les paquets en provenance des dépôts de tierces parties sont mis à niveau ?

Oui, si ces dépôts sont configurés comme des dépôts dnf normaux et ne codent pas en dur le chemin du dépôt. Les dépôts de tierces parties d’usage courant fonctionnent en général très bien, mais si vous essayez de mettre à niveau avant, ou juste après, une nouvelle parution de Fedora, il est possible que les chemins vers ces dépôts n’aient pas encore été mis à jour et que Fedora ne parvienne pas à trouver les paquets. Cela empêche généralement la mise à niveau de Fedora, bien que vous puissiez faire la mise à jour des paquets en provenance de ces dépôts ultérieurement.

Puis-je effectuer une mise à niveau à partir d’une version en fin de vie  ?

Notez bien que Fedora vous déconseille fortement d’exécuter une version en fin de vie sur un système en production, ou sur un système connecté à l’Internet quelles qu’en soient les circonstances. D’abord et avant tout, vous ne devriez jamais permettre à un déploiement de Fedora d’atteindre la version fin de vie.

Ceci dit, si vous êtes sur une version de fin de vie plus récente que Fedora 20, et que vous ne pouvez pas vous contenter de simplement la laisser de côter ou de la redéployer, vous pouvez essayer de la mettre à niveau bien que ce soit une opération moins testée et pour laquelle vous obtiendrez moins d’assistance. Vous pouvez essayer de monter de version en version jusqu’à atteindre la version courante, ou essayer d’atteindre la version courante en une seule opération. Il est difficile de dire avec certitude laquelle de ces deux solutions a le plus le chance d’aboutir.

Si vous essayer de mettre à niveau à travers plus de deux versions en une seule opération, lisez aussi la réponse suivante.

Si vous utilisez Fedora 20 ou une version antérieure, vous ne pouvez pas mettre à niveau avec dnf system-upgrade seulement. Vous devez mettre à niveau au moins une partie du chemin en utilisant la commande nue dnf ou yum. Vous pouvez soit mettre au niveau de Fedora 21 de cette façon et mettre le reste à niveau avec dnf system-upgrade, soit essayer de mettre à niveau le tout uniquement avec la commande nue dnf ou yum. Notez que cette méthode n’est pas en soi une méthode officielle recommandée pour la mise à niveau. Pour être franc, toute mise à niveau depuis Fedora 20, ou depuis une version antérieure, se fait à vos risques et périls.

De combien de versions puis-je monter en niveau en une seule opération ?

Le scénario le plus courant est de monter d’une version (p. ex. de Fedora 38 à Fedora 39). Néanmoins, durant le premier mois environ après la parution d’une nouvelle version, des mises à jour depuis l’antépénultième version sont prises en charge, dans le sens où nous incluons ce scénario dans les critères de parution de Fedora, en assurons le test au moins pour des installations propres des jeux de paquets pris en charge, et regarderons les rapports d’anomalies pour de telles mises à niveau comme importants. Le cycle de vie des versions de Fedora est spécialement conçu pour fournir cette 'durée de grâce' approximative d’un mois, de manière à ce que vous puissiez choisir de ne réaliser des mises à niveau que sur des versions à longue durée de vie, une version sur deux, plutôt que sur chacune des versions.

Environ un mois après la parution de la nouvelle version, l’antépénultième version passe en fin de vie, point auquel la question précédente se pose. Par ailleurs, cette mise à niveau est encore susceptible de fonctionner correctement durant quelques temps après le passage en fin de vie.

Les mises à niveau effectuant un saut de numéro de version supérieur à 2 ne sont pas prises en charge, et les problèmes rencontrés ne seront probablement pas considérés comme importants. Notez que toute mises à niveau avec un saut de numéro de version supérieur à 2 sont par définition des mises à niveau depuis une version en fin de vie, et qu’en conséquence, la question précédente se pose également ici.

Lors d’une mise à jour sautant plusieurs numéros de version, il est possible que vous deviez importer la clé de signature des paquets de la version cible à la main. Les versions de Fedora disposent en général des clés de signature des paquets pour les deux versions suivantes (parce qu’elles passent en fin de vie avant que la version N+3 ne soit branched). Avant Fedora 22, ce n’était pas toujours le cas que chacune des versions disposât des clés pour les deux versions suivantes. Si dnf se plaint à propos d’une clé manquante, c’est ce que vous devez faire.

Puis-je utiliser dnf system-upgrade pour passer au niveau d’une pré-version (p. ex. une version Beta) ?

Oui. Il devrait toujours être possible d’essayer une telle mise à niveau. Bien sûr, cette fonction est sujette à des plantages temporaires comme tous les autres aspects d’une pré-version, et en général, plus la version en question est jeune, plus un fonctionnement sans problème est improbable.

Tâches facultatives d’après mise à niveau

Il y a des tâches que vous pouvez réaliser après une mise à niveau réussie. Elles concernent essentiellement les utilisateurs chevronnés. Si vous êtes un utilisateur de base qui ne fait pas un usage quotidien du terminal, vous pouvez les ignorer.

Mise à jour des fichiers de configuration

La plupart des fichiers de configuration sont stockés dans le dossier /etc. Si plusieurs de ces fichiers sont mis à jour et que vous les avez modifiés auparavant, RPM crée de nouveaux fichiers, soit avec le suffix .rpmnew (le nouveau fichier de configuration par défaut), soit avec le suffixe .rpmsave (la sauvegarde de votre ancien fichier de configuration). Vous pouvez rechercher ces fichiers, examiner les changements et vous assurer que vos personnalisations sont encore incluses, et que les nouvelles valeurs par défaut sont appliquées elles aussi. Un outil qui essaye de simplifier cette tâche est rpmconf. Installez le paquet et utilisez le avec : 

$ sudo  rpmconf -a

Lisez la page de manuel de ce paquet pour plus d’information.

Se débarrasser des paquets inutiles

Vous pouvez obtenir une liste des paquets avec des dépendances cassées avec la commande suivante : 

$ sudo dnf repoquery --unsatisfied

Idéalement, il ne devrait pas y en avoir. S’il en existe, envisagez de les supprimer parce qu’ils ont peu de chances de fonctionner correctement..

Vous pouvez voir les paquets en double (les paquets installés en plusieurs versions) avec la commande suivante : 

$ sudo  dnf repoquery --duplicated

Pour les paquets ordinaires, seule la dernière version devrait être installée. Il existe cependant des exceptions à la règle, c’est pourquoi vous ne devez supprimer que les paquets dont vous n’avez à coup sûr plus besoin.

Certains paquets peuvent subsister dans votre système alors qu’ils sont retirés des dépôts. Vous pouvez en obtenir la liste avec la commande : 

$ sudo dnf list extras

Si vous n’utilisez pas ces fichiers, vous pouvez envisager de les supprimer. Notez bien que cela n’est valide que si vous avez un système complètement à jour. Autrement vous verrez tous les paquets qui ne sont plus dans les dépôts parce qu’une nouvelle version est disponible. C’est pourquoi, avant de les supprimer, assurez-vous d’avoir exécuté la commande $ sudo dnf update et recherchez à nouveau cette liste de paquets. De plus, cette liste peut comprendre des paquets installés depuis de dépôts de tierces parties pour lesquels un dépôt à jour n’a pas encore été publié. Cela est souvent le cas pour des dépôts tels que RPM Fusion ou Dropbox.

Vous pouvez retirer les paquets qui ne sont plus nécessaires avec la commande : 

$ sudo dnf autoremove

mais soyez conscient que dnf decide qu’un paquet n’est plus nécessaire si vous n’en avez pas explicitement demandé l’installation et que rien ne le requiert plus.Cela ne signifie pas que ce paquet est inutile ou que que vous ne l’utilisez pas. Ne retirez que les paquets dont vous n’avez à coup sûr plus besoin. Il y a une anomalie connue dans PackageKit qui ne marque pas des paquets comme installés par l’utilisateur (voir l’anomalie 1259865. Si vous utilisez PackageKit (ou GNOME, Apper, etc.) pour installer, cette sortie peut même lister des applications importantes et des paquets systèmes. Donc soyez en conscient et vigilant.

Résolution des problème post-installation

Ne suivez ces instructions que si vous rencontrez des problèmes avec votre système mis à niveau. Elles ne devraient pas être nécessaires dans la grande majorité des cas de mise à niveau.

Reconstruction de la base de données RPM

Si vous apercevez des messages d’avertissement lorsque vous travaillez avec les outils RPM/DNF, votre base de données peut avoir été corrompue pour une raison ou pour une autre. Il est possible de la reconstruire et de voir si cela résout vous problèmes. Faites toujours une sauvegarde de /var/lib/rpm/ avant toute chose. Pour reconstruire la base de données, exécutez : 

$ sudo rpm --rebuilddb

Utilisation de distro-sync pour résoudre les problèmes de dépendances

L’outil de mise à niveau du système utilise la méthode distro-sync par défaut. Si votre système n’est pas totalement mis à jour, ou si certains paquets présentent des problèmes de dépendances, vous pouvez essayer de les résoudre en exécutant à nouveau la commande distro-sync à la main. Cela essaye de mettre vos paquets installés à exactement la même version que celles des dépôts courants, même si cela conduit à rétrograder certains paquets : 

$ sudo dnf distro-sync

Une variante plus radicale autorise également le retrait des paquets pour lesquelles certaines dépendances ne peuvent être satisfaites. Passez toujours en revue avec la plus grande attention quels paquets vont être retirés avant de confirmer cette commande: 

$ sudo dnf distro-sync --allowerasing

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

Si vous apercevez des messages d’avertissement vous disant que certaines actions n’ont pas été autorisées à cause de la politique SELinux courante, il est possible que certains fichiers aient été incorrectement étiquetés avec les permissions SELinux. Cela peut se produire dans le cas de certaines anomalies ou si vous avez SELinux désactivé durant certains moments du passé. Vous pouvez ré-étiqueter le système entier en exécutant : 

$ sudo touch /.autorelabel

et en redémarrant. Le prochain redémarrage prendra beaucoup de temps et vérifiera et corrigera toutes les étiquettes SELinux de tous vos fichiers.

Retrieved from "https://fedoraproject.org/w/index.php?title=DNF_system_upgrade/fr&oldid=496516"