Update: Das im Text besprochene Skript wurde durch eine neue Version mit vereinfachter Handhabung ersetzt. Einzelheiten dazu siehe im Kommentar Neue Version mit vereinfachter Nutzung.
Die Aktualisierung eines Systems ist immer gefährlich und heikel. Diese Anleitung ist nur für erfahrene Administratoren, die ohne weiteres in der Lage sind, ein „normales” Upgrade eines openSUSE-Systems vorzunehmen, und geeignete Maßnahmen treffen können, wenn irgendetwas schief läuft. Dies ist also definitiv nichts für Anfänger, es sei denn zu Lernzwecken. Auf jeden Fall beachte man die folgenden Warnungen.
Warnung: Benutze weder das angehängte Skript noch die hier eingestellten Anweisungen, wenn Du nicht weißt, was Du tust! Prüfe zuvor das Skript und die Anweisungen, ob sie Deinen und Deines Systems Notwendigkeiten entsprechen. Anderenfalls kann Dein System ernsthaft beschädigt werden!
Bei Verwendung des Skripts ist insbesondere zu beachten, dass nach Anzeige einer Meldung wie "***Now disabling old repositories. Continue (y/n)?" bei Zustimmung und späterem Abbruch des Verfahrens alle Repositories des alten Systems verloren sind.
Außerdem wird bei Fortsetzung nach einer Meldung der Art "***Finally starting the upgrade. Continue (y/n)?" und späterem Abbruch das System unvollständig und definitiv unbrauchbar sein.
So weit die Warnungen. Wir entwickeln hier eine Prozedur, um ein openSUSE-System zu aktualisieren (derzeit auf Version 12.1), und zwar aus dem laufenden System heraus, ohne feste Installationsmedien zu benutzen. Vorlage war ein Eintrag auf opensuse.org; leider kann ich die genaue URL nicht mehr finden, weil die Dokumentationssparte auf opensuse.org in letzter Zeit ziemlich durcheinandergewirbelt wurde. Am Ende des Beitrags ist ein vollständiges Skript angehängt; hier beschreiben wir einige wichtige Teile davon..
Zunächst definieren wir einige Variablen: für das Betriebssystem (OS), um das es geht, den Server, der die benötigten Dateien zur Verfügung stellt, und die neue Version (NEW_VER), die zu installieren ist.
OS=openSUSE
SERVER=http://download.opensuse.org
NEW_VER=12.1
Als Nächstes sorgen wir dafür, dass die Distributionsaktualisierung einen zuverlässigen Ausgangspunkt hat, d. h., wir machen ein gewöhnliches Update der aktuellen Version. Dies erledigt ein Auffrischen der aktuellen Repositories und anschließendes Update mit zypper.
zypper refresh
zypper update
Jetzt müssen alle alten Repoistories deaktiviert werden, da das zu aktualisierende System nicht von diesen sondern von neuen Repositories zu laden ist. Warnung: Ab diesem Punkt startet die Aktualisierung; es ist nicht mehr möglich, das Verfahren abzubrechen, ohne Probleme zu bekommen oder sogar Zerstörungen anzurichten.
zypper modifyrepo --all --disable
Nun fügen wir die neuen Standard-Repositories hinzu; diese sind weitgehend obligatorisch für die neue Installation. Das allgemeine Format dafür ist
zypper ar -cf -n <Name> <URI> <Alias>
wobei ar für addrepo steht (füge Repository hinzu) und -cf beinhaltet Prüfung des URI sowie automatisches Auffrischen des Repositories. Außerdem lässt sich die Priorität eines Repositories ändern durch
zypper mr -p <Priority> <Alias>
Die voreingestellte Priorität ist 99. Es ist nicht so offensichtlich, was die Prioritäten eigentlich bedeuten; es scheint, dass ein Paket einer gegebenen Version vom Repository mit der niedrigsten Prioritätszahl geladen wird.
Um konkret zu werden, die folgenden drei Repositories sind Standard und sollten immer eingebunden werden:
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
Optional können weitere Standard-Repositories (source, debug) hinzugefügt werden. In diesem Fall benutzen wir das Format
zypper ar -cdf -n <Name> <URI> <Alias>
wobei ar bedeutet addrepo und -cdf beinhaltet Prüfung des URI, jedoch Deaktivierung, obwohl automatisches Auffrischen des Repositories, soweit anwendbar. Entferne 'd' von "-cdf", um ein Repository zu aktivieren. Die Repositories in dieser Kategorie sind wahrscheinlich nur für Entwickler von Interesse. Auch hier lässt sich die Priorität eines Repositories ändern wie zuvor; Standard ist wieder 99.
Entsprechend der Regel bekommen wir diese Source- und 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
Das angehängte Skript enthält viele weitere Repositories wie openSUSE-BuildServices, Packman, usw. Alle diese sind standardmäßig auskommentiert; entferne das '#'-Zeichen, um ein Repository hinzuzufügen und ändere das "-cdf"-Argument in "-cf", um es zu aktivieren oder andersherum. An dieser Stelle wären auch weitere Repositories hinzuzufügen oder existierende auszukommentieren oder zu löschen – so wie es den eigenen Anforderungen entspricht.
Eine Liste der neuen Repositories erhalten wir so:
zypper repos --uri
Bevor wir fortsetzen, sollten die neuen Repositories aufgefrischt werden:
zypper refresh
Danach sollte zuerst zypper selbst auf die neue Version aktualisiert werden. Dies ist sicherlich eine angrebachte Maßnahme, wobei dies bereits einen beträchtlichen Teil des neuen Systems aktualisieren wird, was einige Zeit in Anspruch nehmen mag.
zypper update zypper
Schließlich starten wir die Distributionsaktualisierung. (Das mag mehrere Stunden dauern!).
zypper dist-upgrade
Nach Abschluss sollte das Sytem so bald wie möglich neu gestartet werden.
Da die angehängte Datei ein einfaches Skript ist, wird sie – entgegen der Ausführungen im blog – unter dieser einfachen Lizenz veröffentlicht:
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.
Zuletzt ist noch zu sagen, dass das Skript nicht zur Stapelverarbeitung geeignet ist. Es stellt viele Fragen – einige kommen vom Skript selbst, andere vom aufgerufenen Programm zypper –, die zu beantworten sind (meistens mit „ yes” oder „no”). Also muss man an seinem Terminal bleiben und sehen was passiert.
| Anhang | Größe |
|---|---|
| suse_upgrade.sh_.gz | 1.42 KB |