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 opensuse.org; unfortunately, I can't find the exact URL anymore, because opensuse.org'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.
OS=openSUSE
SERVER=http://download.opensuse.org
NEW_VER=12.1
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.
| Attachment | Size |
|---|---|
| suse_upgrade.sh_.gz | 1.42 KB |
Neue Version mit vereinfachter Nutzung
Das im Text besprochene Skript wurde durch eine neue Version ersetzt.
Im Gegensatz zur Beschreibung ist es nun nicht mehr nötig, die Datei für jedes neue Upgrade zu editieren.
Dies wird zum einen dadurch erreicht, dass die alte, vorhandene und die neue, zu installierende Version des Betriebssystems über zwei Kommandozeilenparameter anzugeben sind, also z. B.:
suse_upgrade.sh 13.1 13.2
Zum anderen entfällt das umständliche Eintragen aller neuen Repositories, indem einfach bei den URLs der vorhandenen Repositories die alte Versionsnummer durch die neue ausgetauscht wird. Das dazu verwendete Verfahren ist in der openSUSE Support Database (SDB) im Beitrag SDB:System upgrade beschrieben. Es funktioniert so, dass im Verzeichnis /etc/zypp/repos.d, in dem zypper die Repository-Informationen speichert, in allen Dateien der fragliche Versions-String ersetzt wird. Die entsprechende Zeile des neuen Skripts sieht so aus:
sed -i "s/${OLD_VER}/${NEW_VER}/g" /etc/zypp/repos.d/*
Dabei enthalten OLD_VER und NEW_VER die über die Kommandozeile übergebenen Parameterwerte. (Tatsächlich bedeutet die Auswertung innerhalb eines regulären Ausdrucks, dass etwa für "13.1" auch Strings wie "13x1" ersetzt würden, das hat bei mir aber noch nie zu Problemen geführt.) Auf diese Weise sind nicht nur die vorhanden Repositories in neuer Version verfügbar, sondern es bleiben auch zusätzliche Daten wie Prioritäten sowie Aktualisierungs- und Aktivierungsinformationen erhalten.
Mit diesem Verfahren ergibt sich zwar eine neue Systemabhängigkeit des Skripts, die vorher nicht da war, aber es vereinfacht die Anwendung erheblich und reduziert mögliche Fehlerquellen durch falsches Eingeben von neuen Repository-URLs. Zur Sicherheit legt das Skript vor Ausführung obigen Befehls eine Kopie des alten Repository-Verzeichnisses unter /etc/zypp/repos.d~ an. Es sei noch angemerkt, dass das Skript nur die Inhalte, nicht aber die Namen der Dateien in /etc/zypp/repos.d ändert; man sollte sich also nicht dadurch verwirren lassen, dass dort Dateinamen mit alten Versionsnummern auftauchen, es kommt nur auf die Inhalte an.
Abschließend ist noch zu erwähnen, dass das Skript seine Aktionen in ~/suse_upgrade2.log protokolliert.
New Version with Simplified Usage
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.:
suse_upgrade.sh 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.