Sie sind hier

Upgrade von openSUSE aus dem laufenden System heraus

Gespeichert von h2b am 4. April 2012 - 14:32
Problembeschreibung
System: 
openSUSE
Version: 
12.1 - 13.2
Symptom: 

Ein openSUSE-System soll auf eine neue Distribution aktualisiert werden, ohne Medien wie DVD, CD, USB-Stäbe o. ä. zu benutzen. Stattdessen  soll die Aktualisierung aus dem laufenden System heraus erfolgen.
 

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.

AnhangGröße
Binärdaten suse_upgrade.sh_.gz1.42 KB

Bereich:

Kommentare

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.