DNF system upgrade/it

In other languages: English (en) français (fr) italiano (it) português (pt) [edit]

Traduzione incompleta; fare riferimento alla pagina in lingua inglese.

Cos'é il 'DNF system upgrade' ?

dnf-plugin-system-upgrade è un plugin per il manager di pacchetti dnf che gestisce gli aggiornamenti di sistema. É il metodo di aggiornamento raccomandato per le versioni di Fedora superiori alla 21.

Funzionamento

Il 'DNF system upgrade' aggiorna il sistema ad una nuova versione di Fedora usando un meccanismo simile a quello usato per gli aggiornamenti in locale (offline). I pacchetti aggiornati vengono scaricati mentre il sistema funziona normalmente, per poi riavviarsi in una modalità adatta ad installarli. Una volta terminato, il sistema si riavvìa di nuovo nella nuova Fedora.

Come si usa ?

1. Backup dei propri dati. Ogni cambiamento del sistema è potenzialmente a rischio, quindi essere prepararsi all'eventualità. Nel caso si voglia aggiornare la propria (Fedora) workstation, è ancora preferibile scaricare una immagine live della Workstation ed assicurarsi che il proprio hardware (scheda grafica, wifi, etc) funzioni bene con l'ultimo kernel disponibile.
2. Aggiornare il sistema usando gli strumenti grafici standard oppure pkcon o dnf:

   $ sudo dnf update --refresh

   É raccomandato riavviare il computer, specie se viene installato un nuovo kernel.
   Si prega di tener presente che esiste un problema se si usa un tema plymouth non predefinito.
   

   Seguire i seguenti passaggi.

3. Installare dnf-plugin-system-upgrade:

   $ sudo dnf install dnf-plugin-system-upgrade

4. Scaricare i pacchetti aggiornati:

   $ sudo dnf system-upgrade download --refresh --releasever=39

   Modificare il numero --releasever= in base al sistema a cui si vuole aggiornare. Molti utenti aggiornano all'ultimo sistema stabile disponibile, cioé 39, ma se si usa una Fedora 37, si potrebbe voler aggiornare ad una Fedora 38. Si può anche usare 40 oppure rawhide per avere una Rawhide (attenzione: queste sono versioni instabili di Fedora).

   • Se alcuni pacchetti hanno dipendenze insoddisfatte, l'aggiornamento non andrà avanti a meno che non si usi l'opzione --allowerasing. Spesso accade se si usano pacchetti provenienti da scaricamenti esterni a quelli ufficiali.
   • In caso di dipendenze insoddisfatte, si possono avere ulteriori dettagli aggiungendo l'opzione --best.
5. Innescare il processo di aggiornamento:

    $ sudo dnf system-upgrade reboot

   Il sistema verrà riavviato immediatamente, ed apparirà il processo di aggiornamento all'avvìo.

6. Attenderne il completamento.

FAQ

Come riportare eventuali bug

Innanzitutto dare uno sguardo ai Common F39 bug o Common F40 bug per controllare se il problema è già conosciuto. Se non c'é, fare una ricerca per un eventuale bug report esistente. Se non esiste ancora, se ne può aprire uno seguendo le seguenti istruzioni this README and in man dnf.plugin.system-upgrade.

If you hit issues after upgrade with a specific package, file a bug against the package with which you are having issues.

Does DNF system upgrade verify the software it runs or installs during upgrade?

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 --nogpgcheck parameter if you need to do so for any reason (not recommended, you're then opened to attacks from malicious software).

Will packages in third party repositories be upgraded?

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.

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

Please note 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 know you don't need. Please note that 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.