You are here

Upgrading openSUSE from a Running System

Submitted by h2b on 27. March 2012 - 18:23
12.1 - 13.2

Want to upgrade system to new openSUSE distribution without using media like DVD, CD, USB sticks or the like. Instead, just performing an upgrade from the running system.

Update: The script talked about in the text has been replaced by a new version with simplfied usage. For details see the comment New Version with Simplified Usage.

Upgrading a system is always a potential cause of pain and damage. This is only for experienced administrators who are at least able to do a “normal” upgrade of an openSUSE system and can take appropriate measures if anything goes wrong. So, this is definitely nothing for newbies, unless you are just using the steps described below  for learning. Please regard the following warnings.

Warning: Do not use the attached script or the hints provided here if you don't know what you are doing! Check the script and the hints for obeying your needs and your personal system before. Otherwise, it can damage your system!

Regarding to the script, when you continue, in particular, after a message like "***Now disabling old repositories. Continue (y/n)?" has been shown and break the procedure afterwards, all repositories of the old system will be lost.

Moreover, when you continue with a message like "
***Finally starting the upgrade. Continue (y/n)?" and break the procedure afterwars, you will get an incomplete and definitely unusable new system.

So far for the warnings. We will develop a procedure here to upgrade openSUSE (currently to version 12.1) from a running system without media. It was inspired by a piece found at; unfortunately, I can't find the exact URL anymore, because's documentation section apparently got mixed up at last. In the end, a complete script is attached. Here we will describe some important portions.

Initially, we define some symbols: the operation system (OS) which is in question, the server that hosts the files to be loaded and the version (NEW_VER) which is to be installed.



At next, we should set a reliable starting point for the distribution upgrade. This means to do a usual update of the current version. Refreshing the current repositories and updating by zypper will do it.

zypper refresh
zypper update

Now, all old repositories have to be disabled. This is, because the upgraded system can't be got from those but have to be gotten from new repositories. Warning: Beginning at this point we are in upgrading mode and cannot cancel the procedure without problems or even damage.

zypper modifyrepo --all --disable

So, we add the new standard repositories – which are almost mandatory for the new installation. The general format for that is

zypper ar -cf -n <Name> <URI> <Alias>

where ar  means addrepo (add repository) and -cf involves checking the URI and refreshing the repository automatically. Also, you can change the priority of a reposity by

zypper mr -p <Priority> <Alias>

The default priority is 99. It is not so obvious what these priorities really do; it seams that a package of a given version would be loaded from the repository with the lowest priority number.

To be concretely, the following three repositories are standard and should be included always.

zypper ar -cf -n "${OS}-${NEW_VER} OSS" ${SERVER}/distribution/${NEW_VER}/repo/oss/ ${OS}-${NEW_VER}-oss
zypper ar -cf -n "${OS}-${NEW_VER} Non-OSS" ${SERVER}/distribution/${NEW_VER}/repo/non-oss/ ${OS}-${NEW_VER}-non-oss
zypper ar -cf -n "${OS}-${NEW_VER} Updates" ${SERVER}/update/${NEW_VER}/ ${OS}-${NEW_VER}-update


Optionally, further standard repositories (source, debug) could be added. In this case, we use the format

zypper ar -cdf -n <Name> <URI> <Alias>

where ar means addrepo and -cdf involves checking the URI, but disabling, although refreshing the repository automatically when appropriate. Exclude 'd' from "-cdf" to activate a repository. These repositories probably are useful only for developers. Also you can change the priority of a reposity as before; the default is 99 again.

Applied to the rule we have these source and debug repositories:

zypper ar -cdf -n "${OS}-${NEW_VER} Source" ${SERVER}/source/distribution/${NEW_VER}/repo/oss/ ${OS}-${NEW_VER}-source
zypper ar -cdf -n "${OS}-${NEW_VER} Debug" ${SERVER}/debug/distribution/${NEW_VER}/repo/oss/ ${OS}-${NEW_VER}-debug
zypper ar -cdf -n "${OS}-${NEW_VER} Debug Updates" ${SERVER}/debug/update/${NEW_VER}/ ${OS}-${NEW_VER}-debug-update


The script attached below includes many other repositories like openSUSE BuildServices, Packman, etc. All of these are commented out by default, so just remove the '#' sign to add a repository and switch the "-cdf" argument to "-cf" to get the appropriate activation or vice versa. Also, this is the right place to add more repositories or to uncomment or to delete existing ones according to yout needs.

Let's get a listing of the new repositories:

zypper repos --uri

Before we proceed, the new repositories should be refreshed.

zypper refresh

Now, update zypper itself to the version to be upgraded first. This is probably a good idea, however it may upgrade a considerable portion of the whole new system already. As a consequence, it may take some notable time.

zypper update zypper

Finally, start the distribution upgrade. (Takes assumably several hours!).

zypper dist-upgrade

When finished, the system should be rebooted as soon as possible.

Since the attached file is only a script, it is provided – despite the statements in the blog – under this simple licence:

This program is distributed WITHOUT ANY WARRANTY, express or implied.

Permission is granted to make and distribute verbatim copies of this document provided that the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.


Finally, note that the script is not intended for batch processing. It will ask many questions – some coming from the script itself, others induced by the zypper program called – you have to answer (usually by yes or no). So, you have to sit at your terminal and look what happens.

Binary Data suse_upgrade.sh_.gz1.42 KB



The script talked about in the text has been replaced by a new version.

In contrast to the description, now it is not required anymore to edit the file for each new upgrade.

This has been achieved – on the one hand – by entering the old existing version of the operating system and the new version to be installed as two command line arguments, e.g.: 13.1 13.2

On the other hand, the elaborate listing of all new repositories has been dropped by simply replacing the old version number by the new one in the URLs of the existing repositories. The concerning procedure is described in the openSUSE Support Database (SDB) in the article SDB:System upgrade. It works by replacing the version string in question in all files of the directory /etc/zypp/repos.d, where zypper stores the repository data. The corresponding line of the new script looks like this:

sed -i "s/${OLD_VER}/${NEW_VER}/g" /etc/zypp/repos.d/*

where OLD_VER and NEW_VER are supplying the values entered as command line arguments. (In fact, the evaluation within a regular expression means that for, e.g., "13.1" strings like "13x1" would be replaced too, but this was fine for me so far.) In this way, not only the existing repositories are available in a new version, but also additional data like priorities or refreshing and enabling settings are reobtained.

With this procedure, although there arises a new system dependency of the script, the usage is simplified considerably and possible sources of failure by entering wrong repository URLs are reduced. For safety, the script copies the old repository directory to /etc/zypp/repos.d~ before executing the statement above. By the way, the script only changes the contents of the files in /etc/zypp/repos.d, not their names; thus, don't be confused by observing file names with old version numbers, only the contents are decisive.

Finally, reference should be made to the point that the script logs its actions in ~/suse_upgrade2.log.