Home

Welcome to the Zypper-Upgraderepo wiki!

Zypper-Upgraderepo is a command-line application that aims to detect, and when possible solve, the validation and upgrade problem for the configured repositories in an openSUSE Leap distribution.

While switching to a new release the repositories might not be provided for the new version, or sometimes they might change their location enough to screw up the entire upgrade process if executed only by changing the version number or using the Zypper variables without changing the overall path.

So it comes in handy, especially with a large number of repositories to check and upgrade and even more when many of them change their URL address.

Besides the main features, it evolved to solve other problems and also provides commands to:

Check and upgrade for whatever version in the list of known versions;
Backup the whole list of repositories;
Load a list of URLs for a manual override just in case the auto-discover fails;
Update the leftover repositories to the current version;
Reset the accidentally overridden repositories to the current version;
Check for the status of the current distribution;
Detect the duplicated repositories;
Detect the unused repositories.

There are also options for:

Print only invalid, enabled, or a list of repositories identified by their number/alias/name or a portion of it;
Visualize the data as a table (default), a report, or an INI file structure;
Sort the results by repository alias (default), name, priority;
Run in quiet mode displaying only error messages.

Checking repositories

With a view to a distro upgrade, the repository check operation mainly helps to discover which repositories are ready for the upgrade reporting those URLs not working as expected, i.e. Not Found or even Redirected.

Check for the current version

Warning!!! The executable name before the 1.8.0 version is zypper-upgraderepo, unfortunately, the RPM package installation introduces annoying copies of the same executable with a Ruby version appended (zypper-upgraderepo.version, zypper-upgraderepo.rubyversion, zypper-upgraderepo.rubyversion.version) interpreted by zypper itself as different subcommands. So I considered it more convenient to remove the zypper prefix from the original executable and let the sole zypper-upgraderepo-plugin package install it as a zypper plugin.

Checking the current repositories can also be useful to detect failures during a normal update process:

$ upgraderepo --check-current

A table with four columns will show:

The status;
The repository number;
The repository name;
Whether it is enabled or not;
A hint explaining, if possible, how to replace the invalid URL.

The status can be reported using one of these symbols:

[V]: Everything works as expected;
[W]: The URL has been redirected, the printed URL should be replaced with the printed one;
[E]: The URL is invalid, the application will try to find an alternative.

When the error can't be fixed either manually or with the help of this script, it's better to disable the repository before the next update starts, or even remove it if it is unneeded.

Check for the next version

Before upgrading the current system we can check the status of the repository's URLs for the next version, which are interpolated simply by replacing the current version of openSUSE Leap with the newer.

$ upgraderepo --check-next

The table's result will show the same columns seen before.

Check for the last version

Although it's not recommended to upgrade to a not consecutive version, there are situations when the only thing we can do is to save time or because the other repositories are just missing. With that option, we can check directly for the latest stable version:

$ upgraderepo --check-last

Check for a different version

Last but not least it's possible to check for one of the released versions, not necessarily the next or the last, be careful with this procedure!

$ upgraderepo --check-for 15.0

Override one or more URLs

When the checking procedure fails we can inject the suggested URL or the one discovered by ourselves, then repeat the procedure to validate the configuration and finally upgrade them.

There are two ways to override the URLs:

Using the --override-url option;
Exporting the results as an INI file, apply the changes, and reimport it with the --load-overrides option.

Using the --override-url option

To replace the invalid URLs on the fly we can make use of the --override-url option followed by the repository number and the new URL with a comma , separating them:

$ upgraderepo --check-next --override-url 4,http://domain.org/new-path/version/

Export to the INI file

When the number of failing URLs grows, there is a more comfortable way to override them:

export on an INI file the invalid repositories using the --ini option;

$ upgraderepo --check-next --only-invalid --only-enabled --ini > ~/output.ini

edit it and fix the URLs filling the url field;
```
$ vi ~/output.ini
```

load that file to the next check and upgrade procedure.

$ upgraderepo --check-next --load-overrides ~/output.ini
$ sudo upgraderepo --upgrade --load-overrides ~/output.ini

In the example below we can see an example of the ini output:

[repository_1]
name=Packman_Leap_15.2
alias=Packman_Leap_15.2
url=http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.2/
old_url=http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.1/
priority=99
enabled=Yes
status=Ok

The most important fields are those labeled as old_url and url, the former is pretty obvious, the second represents the upgraded URL. When the new version repository can't be found, the last key will be left empty, and a commented section will suggest what to do.

When an alternative URL isn't found the suggested_url field is missing, this happens when a repository, usually not critical, hasn't been upgraded by the owner, but that doesn't mean that it will never be:

[repository_5]
name=Hardware tools (openSUSE_Leap_15.2)
alias=hardware
old_url=http://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.1/
# The interpolated URL is invalid, try overriding with the one suggested
# in the fields below or find it manually starting from the old_url.
# The alternatives are:
# 1. Waiting for a repository upgrade;
# 2. Change the provider for the related installed packages;
# 3. Disable the repository putting the enabled status to 'No'.
#
url=
priority=99
enabled=Yes
status=Not Found
hint=Can't find a valid alternative, try manually!

In the example below the URL to replace has been found and a confirmation is required manually loading the file after filling the url field with the suggested_url value:

[repository_11]
name=openSUSE_Leap_15.4_Graphics
alias=openSUSE_Leap_15.4_Graphics
old_url=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.3/
# The interpolated URL is invalid, try overriding it with the one suggested
# in the fields below or find it manually starting from the old_url.
# The alternatives are:
# 1. Waiting for a repository upgrade;
# 2. Change the provider for the related installed packages;
# 3. Disable the repository putting the enabled status to 'No'.
#
url=
priority=99
enabled=Yes
status=Not Found
hint=Override with this one
suggested_url=http://download.opensuse.org/repositories/graphics/15.4/

As you can see the old_url slightly changes in the last part of its path, but that's enough to make a simple interpolation procedure fails.

For those really lazy the --solved options output the same INI file but with the url field pre-populated with the suggested_url value.

Backup

Before making any permanent change a backup is highly recommended.

The single-file backup

Zypper itself allows creating a backup in a single file:

$ zypper lr -e ~/backup.repo

And restore it with:

$ sudo zypper ar ~/backup.repo

The multiple-file backup

When, for some reason, you want to make a 1:1 backup of all the repositories installed, the --backup operation comes in help:

$ upgraderepo --backup ~

A tgz archive will be placed in the home folder with a squeezed date-time info in the filename.

To restore the archive:

$ sudo tar -xvf ~/repos-backup...tgz -C /

Upgrade

After all the repositories have been successfully checked it's time to upgrade their reference before launching the sudo zypper dup command.

Upgrade to the next version

Upgrading the repositories to the next version is as easy as typing:

$ sudo upgraderepo --upgrade

This replaces the manual editing accomplished with the zypper mr ... command, making it quicker.

Of course, to replace the failing URLs previously detected we can make use of the --override-url option again:

$ sudo upgraderepo --upgrade \
    --override-url 2,http://domain.org/correct/path/15.0/ \
    --override-url 3,http://anotherdomain.org/another-path/15.0

Or load the output file once it has been fixed using the --load-overrides option:

$ sudo upgraderepo --upgrade --load-overrides ~/output.ini

Upgrade to the last version

As seen for the --check-last operation, there is an operation that allows jumping directly to the last version without upgrading to the next.

$ sudo upgraderepo --upgrade-to-last

This practice is highly discouraged, and it is always better to upgrade version by version till the last.

Of course, --upgrade-to-last and --upgrade achieve the same task when the next version is also the last.

Upgrade to a custom version

Upgrading to a custom version is allowed by the --upgrade-to <VERSION> operation:

$ sudo upgraderepo --upgrade-to 15.0

Of course, only existing openSUSE versions will be allowed, don't forget to check the availability of the relative repositories before upgrade or downgrade!

Update

If you left some repositories behind during the upgrade, but want to re-enable and use the packages coming from it can update to the current version with the --update operation:

$ sudo upgraderepo --update

Reset

If you accidentally upgraded your repositories and forgot to create a backup of them, this operation will reset the changes to the current openSUSE Leap version:

$ upgraderepo --reset

Status

This operation has been added with the 1.6.0 release, as a help for the zypper-upgradedistro script, and calculate and print the next, last, and current openSUSE Leap version:

$ upgraderepo --status

It helps to understand either how many versions our distro is back or if it is currently aligned with the latest, stable, available version.

Duplicates

That's something I added after upgrading to the 15.6 version.

I installed as recommended a service including the same repositories I have always used, so it generated a list of duplicated repositories, with slightly different names, and addresses, but also recognized by zypper as identical.

Indeed the only difference is that the repositories coming from the service are configured to take advantage of the CDN net.

$ upgraderepo --duplicates

It only detects similar repositories, further actions are taken manually.

Unused

After an upgrade, some repositories might be left unused because the few packages provided have been included in some main repositories.

$ upgraderepo --unused

At this point, everyone can decide to disable or remove them completely. Don't forget the backup first!

Other options

From time to time other options have been added for scripting or general purposes that might be useful to know.

General options

--allow-unstable : Appends the unstable underworking release in the internal stable releases list.

--no-name : Don't change the repository name.

--no-alias : Don't change the repository alias.

--no-hint : Don't find an alternative URL.

--exit-on-fail : For scripting purposes, exit when the first error is raised emitting an error code.

--timeout <SECONDS> : Change the waiting time for the answer from the repository server before raising a timeout error.

Filtering options

--only-enabled : Check or upgrade only enabled repositories.

--only-invalid : Show only invalid repositories.

--only-protocols <PROTOCOL>[,<PROTOCOL2>,...] : Filter for a list of protocols (http, https, dir).

The --only-repo switch, from the 1.8.0 version and above, accepts not only the repository number, but also a partial reference to its name, alias (prefixed by a @), URL (prefixed by a #), or any text inside one of them (prefixed by a &).

For example, to check only for the next version of the Packman repository in our system:

$ upgraderepo --check-next --only-repo packman

If Packman is specified only as a repository alias:

$ upgraderepo --check-next --only-repo @packman

Maybe we want to check all and only the repositories from the openSUSE domain:

$ upgraderepo --check-next --only-repo '#opensuse'

View options

--sort-by-alias / --sort-by-name / --sort-by-priority : Sort the repositories by either alias (default), name, or priority.

--ini : Export the checking result as an INI file.

--solved : Same as --ini but the url field is prefilled with the suggested_url value.

--quiet : Show only an error message when something wrong happens.

--report : Show the results as a report adding other details.

Wrap up

To summarize this is the list of operations I execute to upgrade my system:

First of all, if you have unneeded repositories remove or disable them, and remove or fix also the wrong repository's URLs using the --check-current operation:
```
$ upgraderepo --check-current
```
Be sure to update the system to the latest packages:
```
$ sudo zypper up
```
If you have a brtfs filesystem Move /var/cache to a separate subvolume, otherwise go to the next step
Check for the next version repositories:
```
$ upgraderepo --check-next
```
If no error occurred then make a backup and upgrade them, otherwise try to apply a fix as discussed:
```
$ upgraderepo --backup ~
$ sudo upgraderepo --upgrade
```
I prefer to download all the packages first:
```
$ sudo zypper dup --download-only
```
Once all packages are downloaded, logout from the graphical session and login into one of the terminal sessions available (i.e. CTRL+ALT+F1), then start the third init level:
```
# init 3
```
Finish the upgrade process:
```
# zypper --no-refresh dup
```
Reboot and you are done!
```
# reboot now
```

I also created Zypper-Upgradedistro script to achieve all these steps through an interactive command-line application.

Resources

The Project page on FreeAptitude blog;
The article Under the hood of zypper-upgraderepo gem on FreeAptitude blog;
The article Upgrading openSUSE with zypper on the FreeAptitude blog;
The article zypper-upgraderepo 1.2 is out on openSUSE Lizards;
A Small tutorial on openSUSE Lizards;
The zypper-upgraderepo-plugin use this gem as zypper subcommand.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly