Upgrading openSUSE with zypper


The following updates have been applied:

  • General improvements

With no doubt, an installation from scratch allows to get rid of all misconfigurations, packages installed once and never used, and broken or unneeded dependencies that most of the times we accumulate from time to time while playing new applications or system settings, upgrading openSUSE Leap through zypper instead, might perform enough well and, at the same time, avoiding to repeat the standard, several, boring configuration steps, to save time.

The procedure I am going to illustrate is inspired by the System Upgrade strategy described in the official documentation, what I introduced is the use of the zypper-upgraderepo plugin that I wrote to make things easier and added some personal considerations to overcome common problems.

Zypper or not

The usual installation process consists on

  1. Download and write the ISO;
  2. reboot from the USB key/CD/DVD support;
  3. prepare the disk and configure the option needed to start the installation;
  4. select and install the packages (only for the DVD version);
  5. apply other configurations and install other software (only for live CD version) post installation.

Upgrading through the zypper command line requires:

  1. Fix the repo’s URLs references;
  2. download the newer version of all and only already installed packages without select them again, at least in most cases;
  3. execute the upgrade;
  4. reboot.

Every time an upgrade doesn’t bring too many radical changes and the system itself is pretty stable to don’t require a cleanup, there is no reason to don’t give a try to zypper.

Update the system

Before to start upgrading it’s always a good practice to update the system.

Those who feel confused should be aware of that difference:

This is the complete procedure which allows to switch a versioned distribution from the actual to the newer version (i.e. from openSUSE 42.3 to openSUSE 15.0, from openSUSE 15.0 to openSUSE 15.1, and so on…).
This is the regular action performed almost daily to keep the packages updated with their latest versions.

Keeping a system updated is always recommended, some of these updates might be important for a smoother upgrade later:

$ sudo zypper update

When some error raises complaining about a repository suddenly missing, use zypper-upgraderepo to understand if it is available at least for the next version, in that case you can ignore any error from that repository and keep it enabled, its packages will be upgraded anyway.

Update the repo’s URLs

The first step is to check whether or not all the repositories currently used are enabled for the new version, this operation can be achieved either:

  1. Checking and updating hand by hand all the repositories;
  2. Using the zypper-upgradrepo gem or zypper plugin.

When the number of repositories is low, the first option is acceptable, otherwise the second is the best choice. The plugin version is only an interface for the gem itself.

To install the plugin a couple of commands are needed (please check the proper version of your distribution first):

$ sudo zypper addrepo https://download.opensuse.org/repositories/home:/FabioMux/openSUSE_Leap_15.0/home:FabioMux.repo
$ sudo zypper install zypper-upgraderepo-plugin

Then let’s check how many repositories are ready to be upgraded:

$ zypper upgraderepo --check-next

As the picture shows, some repository is not yet available, thus we have two options:

  1. Waiting for all the repositories to be available;
  2. disable the unavailable repositories and go on.

The second option is feasible only when:

  • The repository to disable is no longer used,
  • the packages installed are few in number or rarely used that a further reinstall it’s not a problem.

To know which packages are installed from a specific repository:

$ zypper packages -i -r REPO_NUMBER

To disable a repository:

$ sudo zypper mr --disable REPO_NUMBER

Sometimes an alternative URL is suggested, in that case we can override the URL with:

$ zypper upgraderepo --check-next --override-url REPO_NUMBER,URL

Once the list is ready we proceed with a backup:

$ zypper upgraderepo --backup ~

And then the upgrade:

$ sudo zypper upgraderpo --upgrade

Of course when some URL override is needed, we can append one or more -–override-url option as seen before for the –check-next command:

$ sudo zypper upgraderepo --upgrade --override-url REPO_NUMBER,URL [--override-url REPO_NUMBER2,URL2 …]

The zypper-upgraderepo wiki page illustrate more options available by this tool that might come in handy.

Upgrade the system

The next step is to gather all the packages needed to upgrade our system, technically we are switching the vendor of our repos from the current version to the newer, adjusting all the dependencies.

I prefer to split this process into two steps:

  1. Download all the packages on the cache,
  2. apply the upgrade from the cached packages.

That way we can store all the packages on our disk and be sure that all them satisfy the required dependencies although we plan to execute the real upgrade hours later. Otherwise nothing stop them to be updated in their repositories also during the upgrade process, making it fail.

To download all the packages:

$ sudo zypper dup --download-only

Conflicts with new and obsolete packages will be solved now and in case of an unresolvable situation, zypper will ask how to proceed.

Once all the packages are downloaded let’s close our KDE/Gnome session, switch to the terminal console pressing CTRL+ALT+F1 and login as root user.

At this point switching to the runlevel 3 will reduce the risk of instability for a large number of binaries that will be substituted:

# init 3

Finally, we can upgrade using all the downloaded packages without connect again to remote servers:

# zypper --no-refresh dup

Last but not least a reboot to clean the memory from old applications loaded:

# reboot now

Final thoughts

Most of the times, after an upgrade, there is nothing else to do than enjoy the new distribution, but often with new features come also little glitches due to configuration changes in user space, packages not correctly upgraded, tweaks to apply again.

A summary of all the problem I met and how I fixed them will be matter of next articles!

Creative Commons License This work is licensed under a Creative Commons Attribution-NoCommercial-ShareAlike 4.0 International License

This article covers a personal project, further info is provided at the Zypper-Upgraderepo project page.

Leave a Comment