From Fedora Project Wiki
No edit summary
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 la commande '''dnf system-upgrade''' =
== Qu'est-ce que la 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''' ? ==



Revision as of 17:02, 23 November 2016

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 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:
    # dnf upgrade --refresh

    Il est recommandé de redémarrer votre ordinateur ; en particulier sir 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 :
    # dnf install dnf-plugin-system-upgrade
  4. Téléchargez les paquets à jour :
    # 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ésire 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 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é.
    • Dans le cas de dépendances non satisfaites, vous pouvez obtenir plus de détails en ajoutant l'option --best à la commande.
  5. Déclenchez le processus de mise à niveau :
     # 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.

  6. 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.

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.

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.

If you attempt to upgrade across more than two releases in one operation, please also read the next answer.

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 using bare dnf or 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 dnf or 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'.

How many releases can I upgrade across at once?

The most common scenario is an upgrade across just one release (e.g. Fedora 38 to Fedora 39). 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.

Around a month after the new release comes out, the last-but-one release goes End of life, at which point the previous question applies. Still, that upgrade is still pretty likely to work successfully for some time after the release goes end-of-life.

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 previous question applies here too.

When upgrading across multiple releases, you may find you need to 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.

Can I use DNF system upgrade to upgrade to a pre-release (e.g. a 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.

Optional post-upgrade tasks

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.

Update system configuration files

Most configuration files are stored in /etc. If there are any updates to them and you touched some of those files before, RPM creates new files with either .rpmnew suffix (the new default config file), or .rpmsave 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 rpmconf. Install the package, and then use it as:

$ sudo rpmconf -a

See more information in its manual page.

Clean up old packages

You can see list of packages with broken dependencies like this:

$ sudo dnf repoquery --unsatisfied

Ideally there should be none. If there are some, consider removing them, because they are not likely to work properly anyway.

You can see duplicated packages (packages with multiple versions installed) like this:

$ sudo dnf repoquery --duplicated

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.

Some packages might stay on your system while they have been removed from the repositories. See them using:

$ sudo dnf list extras

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 sudo dnf update 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.

You can remove no-longer-needed packages using:

$ sudo dnf autoremove

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 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.

Resolving post-upgrade issues

Only follow up these steps if you have troubles with your upgraded system. It should not be needed in the vast majority of upgrades.

Rebuilding RPM database

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 /var/lib/rpm/ first. To rebuild the database, run:

$ sudo rpm --rebuilddb

Using distro-sync to resolve dependency issues

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:

$ sudo dnf distro-sync

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:

$ sudo dnf distro-sync --allowerasing

Relabel files with latest SELinux policy

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:

$ sudo touch /.autorelabel

and rebooting. The next boot will take a long time and will check and fix all SELinux labels on all your files.