In diesem Kapitel sind die Richtlinien und Voraussetzungen für die Installation und den Einsatz von Solaris Live Upgrade beschrieben. Außerdem sollten Sie sich mit den allgemeinen Informationen zu Upgrades unter Checkliste für ein Upgrade vertraut machen. Dieses Kapitel enthält die folgenden Abschnitte:
Richtlinien zum Erstellen von Dateisystemen mit dem Befehl lucreate
Arbeiten mit Solaris Live Upgrade von einem entfernten System
Solaris Live Upgrade ist in der Solaris 9-Software enthalten. Wenn Sie ein Upgrade mithilfe von Solaris Live Upgrade durchführen möchten, müssen Sie die Solaris Live Upgrade-Packages in Ihrem aktuellen Betriebssystem installieren. Eine Boot-Umgebung kann auf die Solaris-Version der auf dem System installierten Solaris Live Upgrade-Packages aufgestuft werden. Wenn Sie beispielsweise in Ihrem akutellen Betriebssystem Solaris 8 die Solaris 9 Live Upgrade-Packages installiert haben, können Sie ein Upgrade einer Boot-Umgebung auf das Solaris 9 Marketing- oder Update-Release durchführen.
In Tabelle 34–1 sind die von Solaris Live Upgrade unterstützten Versionen aufgeführt.
Tabelle 34–1 Unterstützte Solaris-Versionen
Plattform |
Ausgangsversion |
Zielversion |
---|---|---|
SPARC-basiertes System |
Solaris 2.6-, Solaris 7- oder Solaris 8-Betriebssysteme |
Solaris 8-Betriebssystem |
SPARC-basiertes System |
Solaris 2.6-, Solaris 7- oder Solaris 8-Betriebssysteme |
Solaris 9-Betriebssystem |
x86-basiertes System |
Solaris 7-Betriebssystem |
Solaris 8-Betriebssystem |
x86-basiertes System |
Solaris 7- oder Solaris 8-Betriebssystem |
Solaris 9-Betriebssystem |
Ein Upgrade auf Solaris 7 ist nicht möglich.
Sie können die Solaris Live Upgrade-Packages folgendermaßen installieren:
Mit dem Befehl pkgadd. Die Solaris Live Upgrade-Packages heißen SUNWlur und SUNWluu und sind in dieser Reihenfolge zu installieren.
Mit einem Installationsprogramm auf der Solaris-DVD, der Solaris Software 2 of 2-CD oder in einem Netzwerkinstallationsabbild.
Unter Solaris 2.6, Solaris 7 oder Solaris 8 release kann das Installationsprogramm für Solaris Live Upgrade unter Umständen nicht ausgeführt werden. In diesen Versionen ist der für die Ausführung der JavaTM 2-Laufzeitumgebung (J2RE) erforderliche Patch-Satz nicht enthalten. Um das Solaris Live Upgrade-Installationsprogramm ausführen und die Packages installieren zu können, benötigen Sie das für J2RE empfohlene Patch-Cluster. Installieren Sie die Solaris Live Upgrade-Packages mit dem Befehl pkgadd, oder installieren Sie das für J2RE empfohlene Patch-Cluster, das Ihnen unter http://sunsolve.sun.com zur Verfügung steht.
Anweisungen zur Installation der Solaris Live Upgrade-Software finden Sie unter Installieren von Solaris Live Upgrade.
Beachten Sie die allgemeinen Voraussetzungen bezüglich des Festplattenspeichers für ein Upgrade. Siehe Kapitel 5.
Um die nötige Dateisystemgröße für eine neue Boot-Umgebung abzuschätzen, beginnen Sie mit der Erstellung der Boot-Umgebung. Die Größe wird berechnet. Sie können den Vorgang dann abbrechen.
Die Festplatte in der neuen Boot-Umgebung muss als Boot-Gerät fungieren können. Bei einigen Systemen bestehen Einschränkungen bezüglich der Festplatten, die als Boot-Gerät eingesetzt werden können. Schlagen Sie in der Dokumentation zu dem System nach, ob solche Einschränkungen bestehen.
Eventuell sind einige Vorbereitungen an der Festplatte nötig, bevor Sie die neue Boot-Umgebung erstellen können. Stellen Sie sicher, dass die Festplatte korrekt formatiert ist:
Stellen Sie sicher, dass Slices vorhanden sind, die für die zu kopierenden Dateisysteme groß genug sind.
Identifizieren Sie die Dateisysteme, die Verzeichnisse enthalten, die von den Boot-Umgebungen gemeinsam genutzt und nicht kopiert werden sollen. Soll ein Verzeichnis gemeinsam verwendet werden, so müssen Sie eine neue Boot-Umgebung erstellen, in welcher das Verzeichnis ein eigenes Slice einnimmt. Das Verzeichnis wird dadurch zu einem Dateisystem und kann mit künftigen Boot-Umgebungen gemeinsam genutzt werden. Weitere Informationen zum Erstellen von separaten Dateisystemen für die gemeinsame Nutzung finden Sie unter Richtlinien zum Auswählen von Slices für gemeinsam nutzbare Dateisysteme.
Solaris Live Upgrade verwendet die Technologie des Solaris Volume Manager, um Boot-Umgebungen mit Dateisystemen zu erstellen, bei denen es sich um RAID-1-Volumes (gespiegelte Systeme) handelt. Um die Mirroring-Funktionen von Solaris Live Upgrade nutzen zu können, müssen Sie mindestens eine State Database und mindestens drei State Database Replicas anlegen. Eine State Database speichert Informationen zum Status Ihrer Solaris Volume Manager-Konfiguration auf einer Festplatte ab. Die State Database ist eine Sammlung aus mehreren replizierten Kopien der Datenbank. Jede dieser Kopien wird als State Database Replica bezeichnet. Beim Kopieren einer State Database schützt die Replica dank der redundanten Auslegung gegen Datenverlust. Wie Sie eine State Database anlegen, erfahren Sie in “State Database (Overview)” in Solaris Volume Manager Administration Guide.
Solaris Live Upgrade bietet nicht die volle Funktionalität von Solaris Volume Manager. Solaris Live Upgrade unterstützt nur ein RAID-1-Volume (Mirror) mit Verkettungen aus einzelnen Slices auf dem Dateisystem root (/). Ein gespiegeltes System (MIrror) kann maximal aus drei Verkettungen bestehen. Richtlinien zum Anlegen gespiegelter Dateisysteme finden Sie unter Richtlinien zum Auswählen von Slices für gespiegelte Dateisysteme.
In den folgenden Abschnitten sind die für Solaris Live Upgrade erforderlichen Packages und Informationen zu empfohlenen Patches aufgeführt. Informationen zum Hinzufügen von Packages und Patches mithilfe von Solaris Live Upgrade finden Sie unter Systemupgrades mit Packages und Patches.
Beim Aktualisieren, Hinzufügen und Entfernen von Packages oder Patches sind für Solaris Live Upgrade Packages bzw. Patches erforderlich, die den erweiterten Packaging-Richtlinien SVR4 entsprechen. Sun-Packages entsprechen diesen Richtlinien, doch Sun kann nicht gewährleisten, dass Packages von Drittherstellern diesen Richtlinien entsprechen. Verstößt ein Package gegen diese Richtlinien, kann dies dazu führen, dass während eines Upgrades die Software zum Hinzufügen von Packages Fehler verursacht oder die aktive Boot-Umgebung ändert.
Weitere Informationen zum Hinzufügen und Entfernen von Packages mit Solaris Live Upgrade finden Sie in der Manpage luupgrade( 1M). Weitere Informationen zu Packaging-Anforderungen finden Sie in Anhang G.
Überprüfen Sie, dass in Ihrer bestehenden Betriebsumgebung die folgenden Packages vorhanden sind. Diese Packages werden für den Betrieb von Solaris Live Upgrade benötigt. Wenn Packages aus der Spalte für das jeweilige Release fehlen, fügen Sie diese mit dem Befehl pkgadd zum System hinzu.
Tabelle 34–2 Für Solaris Live Upgrade erforderliche Packages
Solaris 2.6-Release |
Solaris 7-Release |
Solaris 8-Release |
---|---|---|
SUNWadmap |
SUNWadmap |
SUNWadmap |
SUNWadmc |
SUNWadmc |
SUNWadmc |
SUNWjvrt |
SUNWjvrt |
SUNWj2rt |
SUNWlibC |
SUNWlibC |
SUNWlibC |
SUNWadmfw |
SUNWbzip |
|
SUNWmfrun |
| |
SUNWloc |
Um zu überprüfen, ob ein bestimmtes Package auf Ihrem System vorhanden ist, geben Sie folgenden Befehl ein.
% pkginfo [[Package-Name]] |
Sie können mit Solaris Live Upgrade Patches und Packages zu einem System hinzufügen. Indem Sie Solaris Live Upgrade zum Einspielen von Patches auf ein System verwenden, reduziert sich die Ausfallzeit auf die nötige Zeit für den Neustart. Um einer Boot-Umgebung Patches oder Packages hinzuzufügen, können Sie entweder den Befehl luupgrade oder ein Solaris Flash-Archiv verwenden.
Wenn Sie Patches direkt zu einer Boot-Umgebung hinzufügen möchten, erstellen Sie eine neue Boot-Umgebung und führen den Befehl luupgrade mit der Option -t aus. Zum Hinzufügen von Packages zu einer Boot-Umgebung verwenden Sie den Befehl luupgrade mit der Option -p. Weitere Informationen finden Sie in der Manpage luupgrade(1M).
Alternativ können Sie auch Solaris Live Upgrade verwenden und ein Solaris Flash-Archiv installieren. Ein Archiv enthält eine komplette Kopie einer Boot-Umgebung, die die neuen Packages und Patches bereits enthält. Diese vollständige Boot-Umgebung bzw. das Referenzsystem wird als Master-System bezeichnet. Beim Erstellen eines Solaris Flash-Archivs erstellen Sie zunächst ein Master-System. Nachdem Sie ein Master-System erstellt haben, fügen Sie alle Patches und Packages hinzu, die Sie installieren wollen. Erstellen Sie dann ein Solaris Flash-Archiv des Master-Systems. Installieren Sie danach mit Solaris Live Upgrade das Archiv in der neuen Boot-Umgebung. Sie können die Boot-Umgebung kopieren und beliebig oft ändern und weitergeben. Informationen zum Erstellen eines Solaris Flash-Archivs finden Sie in Kapitel 21. Informationen zum Installieren eines Solaris Flash-Archivs mit Solaris Live Upgrade finden Sie unter Installation des Solaris Flash-Archivs in einer Boot-Umgebung.
Beim Aktualisieren, Hinzufügen und Entfernen von Packages oder Patches sind für Solaris Live Upgrade Packages bzw. Patches erforderlich, die den erweiterten Packaging-Richtlinien SVR4 entsprechen. Sun-Packages entsprechen diesen Richtlinien, doch Sun kann nicht gewährleisten, dass Packages von Drittherstellern diesen Richtlinien entsprechen. Verstößt ein Package gegen diese Richtlinien, kann dies dazu führen, dass während eines Upgrades die Software zum Hinzufügen von Packages Fehler verursacht oder die aktive Boot-Umgebung geändert wird.
Weitere Informationen zum Hinzufügen und Entfernen von Packages mit Solaris Live Upgrade finden Sie in der Manpage luupgrade( 1M). Weitere Informationen zu Packaging-Anforderungen finden Sie in Anhang G.
Damit Solaris Live Upgrade fehlerfrei funktioniert, müssen einige wenige Patches für die jeweilige Betriebssystemversion installiert werden. Vor der Installation oder Ausführung von Live Upgrade müssen Sie einen kleinen Patch-Satz installieren. Die aktuelle Patchliste entnehmen Sie bitte der Website http://sunsolve.sun.com. Suchen Sie auf der Website SunSolveSM nach dem Informationsdokument 72099.
Die Option lucreate -m legt fest, welche und wie viele Dateisysteme in der neuen Boot-Umgebung angelegt werden sollen. Sie müssen die genaue Anzahl der anzulegenden Dateisysteme angeben, indem Sie diese Option wiederholen. Wenn Sie die Option -m einmal verwenden, geben Sie an, wohin alle Dateisysteme gestellt werden sollen. Sie führen alle Dateisysteme aus der ursprünglichen Boot-Umgebung in das eine Dateisystem zusammen, das Sie über die Option -m angeben. Wenn Sie die Option -m zweimal angeben, werden zwei Dateisysteme erstellt. Wenn Sie die Option -m zum Erstellen von Dateisystemen verwenden, beachten Sie bitte die folgenden Richtlinien:
Sie müssen die Option -m einmal für das Root-Dateisystem (/) der neuen Boot-Umgebung angeben. Wenn Sie den Befehl lucreate ohne die Option -m ausführen, wird das Konfigurationsmenü angezeigt. Mit dem Konfigurationsmenü können Sie die neue Boot-Umgebung anpassen, indem Sie die Dateien an neue Einhängepunkte umleiten.
Alle kritischen Dateisysteme in der aktuellen Boot-Umgebung, die Sie nicht mit der Option -m angeben, werden in dem Dateisystem der nächsthöheren Ebene zusammengeführt.
Nur die Dateisysteme, die Sie getrennt mit der Option -m angeben, werden in der neuen Boot-Umgebung erstellt. Wenn die aktuelle Boot-Umgebung viele Dateisysteme enthält und Sie in der neuen Boot-Umgebung die gleiche Anzahl an Dateisystemen erstellen wollen, müssen Sie die Option -m für jedes zu erstellende Dateisystem einmal angeben. Wenn Sie zum Beispiel Dateisysteme für Root (/), /opt und /var haben, verwenden Sie die Option -m für jedes Dateisystem in der neuen Boot-Umgebung.
Duplizieren Sie keine Einhängepunkte. So darf es zum Beispiel nicht zwei Root-Dateisysteme (/) geben.
Beim Anlegen von Dateisystemen für eine Boot-Umgebung gelten dieselben Regeln wie zum Anlegen von Dateisystemen für das Betriebssystem Solaris. Solaris Live Upgrade kann Sie nicht daran hindern, kritische Dateisysteme unzulässig zu konfigurieren. Sie können zum Beispiel einen lucreate-Befehl eingeben, durch den separate Dateisysteme für Root (/) und /kernel erstellt werden, obwohl diese Aufteilung von Root (/) nicht zulässig ist.
Überlappen Sie Slices nicht, wenn Sie die Slice-Aufteilung von Festplatten ändern. Bei überlappenden Slices wird die neue Boot-Umgebung scheinbar erstellt, jedoch nicht gebootet, wenn Sie sie aktivieren. Die überlappenden Dateisysteme können beschädigt werden.
Damit Solaris Live Upgrade ordnungsgemäß funktioniert, muss der Inhalt der Datei vfstab in der aktiven Boot-Umgebung gültig sein und die Datei muss mindestens einen Eintrag für Root (/) enthalten.
Beim Erstellen einer inaktiven Boot-Umgebung müssen Sie ein Slice angeben, in das das root-Dateisystem (/) kopiert werden soll. Beachten Sie beim Auswählen eines Slice für das Root-Dateisystem (/) die folgenden Richtlinien. Das Slice muss folgenden Kriterien entsprechen:
Es muss sich um ein Slice handeln, von dem das System booten kann.
Es muss die empfohlene Mindestgröße aufweisen.
Bei einem sun4m-System darf das Root-Dateisystem (/) nicht größer sein als 2 GB.
Es kann sich auf einer anderen oder derselben physischen Festplatte wie das aktive Root-Dateisystem (/befinden.
Es darf sich um ein Veritas Volume Manager-Volume handeln, diese Volumes werden jedoch nicht unterstützt.
Sie können eine neue Boot-Umgebung mit einer beliebigen Kombination aus Festplatten-Slices, Solaris Volume Manager-Volumes und Veritas Volume Manager-Volumes erstellen. Für kritische Dateisysteme, die in die neue Boot-Umgebung kopiert werden, sind folgende Typen zulässig:
Physische Slices.
Eine Verkettung aus einem einzelnen Slice, die in einem RAID–1-Volume (Mirror) enthalten ist. Bei dem Slice, die das Root (/)-Dateisystem enthält, darf es sich um ein RAID–1-Volume handeln.
Eine Verkettung aus einem einzelnen Slice, die in einem RAID–0-Volume enthalten ist. Bei dem Slice, die das Root (/)-Dateisystem enthält, darf es sich um ein RAID–0-Volume handeln.
Beim Erstellen einer neuen Boot-Umgebung erkennt der Befehl lucreate -m die folgenden drei Gerätetypen:
Ein physisches Slice im Format /dev/dsk/cwtxdysz
Ein Solaris Volume Manager-Volume im Format /dev/md/dsk/dnum
Ein Veritas Volume Manager-Volume im Format /dev/vx/dsk/volume_name
Wenn bei einem Upgrade mit Veritas VxVM Probleme auftreten, schlagen Sie unter Systempanik bei einem Upgrade mit Solaris Live Upgrade und Veritas VxVm nach.
Gehen Sie nach den folgenden Richtlinien vor, um festzustellen, ob ein RAID-1-Volume ausgelastet ist, gerade neu synchronisiert wird oder ob ein Volume Dateisysteme enthält, die von einer Solaris Live Upgrade-Boot-Umgebung verwendet werden.
Kurzbefehle und Richtlinien für das Benennen von Volumes finden Sie unter Richtlinien für das benutzerdefinierte JumpStart-Verfahren und Solaris Live Upgrade.
Wenn ein Mirror oder Submirror Wartungsmaßnahmen bedarf oder einen Vorgang bearbeitet, ist es nicht möglich, Komponenten aus dem Verbund zu entfernen. Sie sollten vor der Erstellung einer neuen Boot-Umgebung den Befehl metastat verwenden und dabei das Schlüsselwort detach angeben. Der Befehl metastat prüft, ob der Mirror gerade neu synchronisiert wird oder ob gerade ein Zugriff stattfindet. Weitere Informationen finden Sie in der Manpage metastat(1M).
Wenn Sie das Schlüsselwort detach verwenden, um einen Submirror aus dem Verbund zu entfernen, so prüft lucreate, ob das Gerät gerade neu synchronisiert wird. Falls das Gerät gerade neu synchronisiert wird, lässt sich der Submirror nicht aus dem Verbund entfernen und Sie erhalten eine Fehlermeldung.
Beim Resynchronisieren werden Daten von einem Submirror zum anderen kopiert; eine Resynchronisierung findet nach folgenden Problemen statt:
Fehler in oder Ausfall von Submirrors.
Systemabstürze.
Ein Submirror wurde offline genommen und dann wieder online gestellt.
Es wurde ein neuer Submirror hinzugefügt.
Weitere Informationen zur Resynchronisierung finden Sie unter “RAID 1 Volume (Mirror) Resynchronization” in Solaris Volume Manager Administration Guide.
Verwenden Sie statt Solaris Volume Manager den Befehl lucreate, um mit Volumes auf inaktiven Boot-Umgebungen zu arbeiten. Der Solaris Volume Manager weiß nichts von der Boot-Umgebung; der Befehl lucreate enthält jedoch Prüfmechanismen, die verhindern, dass Sie aus Versehen eine Boot-Umgebung zerstören. Beispielsweise hindert Sie lucreate daran, ein Solaris Volume Manager-Volume zu überschreiben oder zu löschen.
Wenn Sie jedoch bereits Solaris Volume Manager verwendet haben, um komplexe Solaris Volume Manager-Verkettungen, Stripes und Mirrors zu erstellen, müssen Sie auch im weiteren Verlauf Ihrer Arbeit hierfür Solaris Volume Manager verwenden. Solaris Live Upgrade erkennt diese Komponenten und unterstützt sie. Bevor Sie Solaris Volume Manager-Befehle verwenden, mit denen Sie Volume-Komponenten erstellen, ändern oder zerstören können, sollten Sie die Befehle lustatus bzw. lufslist verwenden. Diese Befehle können feststellen, in welchen Solaris Volume Manager-Volumes sich Dateisysteme befinden, die von einer Solaris Live Upgrade-Boot-Umgebung verwendet werden.
Es gibt drei Möglichkeiten, wie Sie mit dem Befehl lucreate und der Option -m ein Swap-Slice konfigurieren können:
Wenn Sie kein Swap-Slice angeben, werden für die neue Boot-Umgebung die Swap-Slices der aktuellen Boot-Umgebung konfiguriert.
Wenn Sie ein oder mehrere Swap-Slices angeben, so verwendet die neue Boot-Umgebung ausschließlich diese Swap-Slices. Eine gemeinsame Nutzung von Swap-Slices durch die beiden Boot-Umgebungen findet nicht statt.
Sie können sowohl ein Swap-Slice gemeinsam nutzen als auch ein neues Swap-Slice hinzufügen.
Die folgenden Beispiele illustrieren die drei Möglichkeiten zur Swap-Konfiguration. In der aktuellen Boot-Umgebung ist das Root-Dateisystem (/) auf c0t0d0s0 konfiguriert. Das Swap-Dateisystem befindet sich auf c0t0d0s1.
Im folgenden Beispiel wird kein Swap-Slice angegeben. Die neue Boot-Umgebung enthält das Root-Dateisystem (/) auf c0t1d0s0. Der Swap-Bereich auf c0t0d0s1 wird von der aktuellen und von der neuen Boot-Umgebung gemeinsam genutzt.
# lucreate -n be2 -m /:c0t1d0s0:ufs |
Im folgenden Beispiel wird ein Swap-Slice angegeben. Die neue Boot-Umgebung enthält das Root-Dateisystem (/) auf c0t1d0s0. Auf c0t1d0s1 wird ein neues Swap-Dateisystem angelegt. Eine gemeinsame Nutzung des Swap-Slice durch die aktuelle und die neue Boot-Umgebung findet nicht statt.
# lucreate -n be2 -m /:c0t1d0s0:ufs -m -:c0t1d0s1:swap |
Im folgenden Beispiel wird ein neues Swap-Slice hinzugefügt und ein weiteres Swap-Slice durch beide Boot-Umgebungen gemeinsam genutzt. Die neue Boot-Umgebung enthält das Root-Dateisystem (/) auf c0t1d0s0. Auf c0t1d0s1 wird ein neues Swap-Slice angelegt. Das Swap-Slice auf c0t0d0s1 wird von der aktuellen und der neuen Boot-Umgebung gemeinsam genutzt.
# lucreate -n be2 -m /:c0t1d0s0:ufs -m -:shared:swap -m -:c0t1d0s1:swap |
Die Erstellung einer Boot-Umgebung schlägt fehl, wenn das Swap-Slice von einer anderen Boot-Umgebung als der aktuellen genutzt wird. Wenn die Boot-Umgebung mit der Option -s erstellt wurde, so darf die alternative Boot-Umgebung das Swap-Slice nutzen, nicht jedoch andere Boot-Umgebungen.
Solaris Live Upgrade kopiert den gesamten Inhalt eines Slice in das angegebene Slice der neuen Boot-Umgebung. Es kann sinnvoll sein, bestimmte große Dateisysteme auf einem Slice nicht zu kopieren, sondern den beiden Boot-Umgebungen zur gemeinsamen Nutzung zur Verfügung zu stellen. So können Sie Festplattenspeicher und Zeit sparen. Betriebssystemwesentliche Dateisysteme wie Root (/) und /var müssen kopiert werden. Dateisysteme wie /home sind dagegen nicht kritisch und können von den Boot-Umgebungen gemeinsam genutzt werden. Gemeinsam nutzbare Dateisysteme müssen benutzerdefinierte Dateisysteme sein und sich in der aktiven und der neuen Boot-Umgebung in separaten Swap-Slices befinden. Sie können die Festplatte je nach Bedarf auf unterschiedliche Weise neu konfigurieren.
Sie können die Slice-Aufteilung der Festplatte vor dem Erstellen der neuen Boot-Umgebung ändern und das gemeinsam nutzbare Dateisystem in ein eigenes Slice stellen. Wenn sich zum Beispiel Root (/), /var und /home in demselben Slice befinden, konfigurieren Sie die Festplatte neu und stellen /home in ein eigenes Slice. Wenn Sie neue Boot-Umgebungen erstellen, nutzen die aktuelle und die neuen Boot-Umgebungen /home standardmäßig gemeinsam.
Wenn ein Verzeichnis gemeinsam genutzt werden soll, muss es in ein eigenes Slice gestellt werden. Das Verzeichnis wird dadurch zu einem eigenen Dateisystem, das mit einer anderen Boot-Umgebung gemeinsam genutzt werden kann. Sie können den Befehl lucreate mit der Option -m verwenden, um eine neue Boot-Umgebung zu erstellen und ein Verzeichnis in ein eigenes Slice zu stellen. Das neue Dateisystem kann danach jedoch noch nicht von der ursprünglichen und der neuen Boot-Umgebung gemeinsam genutzt werden. Sie müssen den Befehl lucreate erneut mit der Option -m ausführen, um eine weitere Boot-Umgebung zu erstellen. Die zwei neuen Boot-Umgebungen können dann das Verzeichnis gemeinsam nutzen.
Wenn Sie beispielsweise ein Upgrade von Solaris 8 auf Solaris 9 vornehmen möchten und /home gemeinsam genutzt werden soll, dann können Sie den Befehl lucreate mit der Option -m ausführen. Sie könnten eine Solaris 8-Umgebung mit /home als separatem Dateisystem auf einem eigenen Slice erzeugen. Führen Sie den Befehl lucreate mit der Option -m dann erneut aus, um diese Boot-Umgebung zu duplizieren. In dieser dritten Boot-Umgebung können Sie anschließend das Upgrade auf Solaris 9 durchführen. /home wird dann von Release Solaris 8 und Solaris 9 gemeinsam genutzt.
Eine Beschreibung kritischer und gemeinsam nutzbarer Dateisysteme finden Sie unter Arten von Dateisystemen.
Wenn Sie eine neue Boot-Umgebung erstellen, können Sie angeben, dass bestimmte Verzeichnisse und Dateien nicht in die neue Boot-Umgebung hinüberkopiert werden sollen. Wenn Sie ein Verzeichnis von der Kopie ausgeschlossen haben, können Sie darunter befindliche Unterverzeichnisse oder Dateien wahlweise auch wieder einschließen. Diese wiederhergestellten Unterverzeichnisse bzw. Dateien werden dann in die neue Boot-Umgebung kopiert. Sie könnten so beispielsweise alle Dateien und Verzeichnisse unter /etc/mail vom Kopieren ausschließen und anschließend die Dateien und Verzeichnisse unter /etc/mail/staff wieder einbeziehen. Mit dem folgenden Befehl würden Sie das Unterverzeichnis staff in die neue Boot-Umgebung kopieren.
# lucreate -n second_disk -x /etc/mail -y /etc/mail/staff |
Verwenden Sie die Optionen zum Ausschließen von Dateien nur mit Bedacht. Entfernen Sie keine Dateien oder Verzeichnisse, die für den Systembetrieb erforderlich sind.
In der folgenden Tabelle sind die Optionen des Befehls lucreate zum Entfernen und Wiederherstellen von Verzeichnissen und Dateien aufgeführt.
Angabemethode |
Ausschließende Optionen |
Einschließende Optionen |
---|---|---|
Geben Sie den Namen des Verzeichnisses oder der Datei an |
-x AusschlussVerz |
-y EinbezogenesVerz |
Geben Sie eine Listendatei an |
-f Listendatei -z Listendatei |
-Y Listendatei -z Listendatei |
Beispiele dafür, wie Sie beim Erstellen einer Boot-Umgebung die Verzeichnisse und Dateien anpassen können, finden Sie unter So erstellen Sie eine Boot-Umgebung und passen den Inhalt an (Befehlszeilenschnittstelle).
Wenn Sie zum Umstieg bereit sind und die neue Boot-Umgebung aktivieren möchten, aktivieren Sie einfach schnell die neue Boot-Umgebung und starten das System dann neu. Beim ersten Booten einer neu erstellten Boot-Umgebung werden die Dateien der verschiedenen Boot-Umgebungen synchronisiert. “Synchronisieren” bedeutet hier, dass eventuell bestimmte kritische Systemdateien und Verzeichnisse aus der zuletzt aktiven Boot-Umgebung in die Boot-Umgebung kopiert werden, die gebootet wird. Die geänderten Dateien und Verzeichnisse werden herüberkopiert.
Solaris Live Upgrade prüft, ob Änderungen an kritischen Dateien stattgefunden haben. Wenn der Inhalt einer dieser Dateien nicht in beiden Boot-Umgebungen identisch ist, wird die jeweilige Datei von der aktiven Boot-Umgebung in die neue Boot-Umgebung kopiert. Die Synchronisierung ist für kritische Dateien wie /etc/passwd oder /etc/group gedacht, die sich seit der Erstellung der neuen Boot-Umgebung eventuell geändert haben.
Die Liste der Verzeichnisse und Dateien, die synchronisiert werden, befindet sich in der Datei /etc/lu/synclist. In manchen Fällen möchten Sie vielleicht auch andere Dateien aus der aktiven Boot-Umgebung in die neue Boot-Umgebung kopieren. Sie können daher je nach Bedarf weitere Verzeichnisse und Dateien in /etc/lu/synclist aufnehmen.
Wenn Sie Dateien aufnehmen, die nicht in /etc/lu/synclist aufgeführt sind, besteht die Möglichkeit, dass Ihr System danach nicht mehr bootet. Bei der Synchronisierung werden lediglich Dateien kopiert und/oder Verzeichnisse angelegt. Es werden keine Dateien oder Verzeichnisse entfernt.
Die folgende /etc/lu/synclist-Beispieldatei zeigt, welche Standardverzeichnisse und -dateien für dieses System synchronisiert werden.
/var/mail OVERWRITE /var/spool/mqueue OVERWRITE /var/spool/cron/crontabs OVERWRITE /var/dhcp OVERWRITE /etc/passwd OVERWRITE /etc/shadow OVERWRITE /etc/opasswd OVERWRITE /etc/oshadow OVERWRITE /etc/group OVERWRITE /etc/pwhist OVERWRITE /etc/default/passwd OVERWRITE /etc/dfs OVERWRITE /var/log/syslog APPEND /var/adm/messages APPEND |
Bei folgenden Verzeichnissen und Dateien kann es in bestimmten Situationen sinnvoll sein, sie in die Datei synclist aufzunehmen:
/var/yp OVERWRITE /etc/mail OVERWRITE /etc/resolv.conf OVERWRITE /etc/domainname OVERWRITE |
Bei den Einträgen in der Datei synclist kann es sich um Dateien oder Verzeichnisse handeln. Das zweite Feld gibt an, was für eine Aktualisierung stattfindet, wenn die Boot-Umgebung aktiviert wird. Die Aktualisierung kann auf drei verschiedene Arten erfolgen:
OVERWRITE — Der Inhalt der Datei in der aktiven Boot-Umgebung überschreibt den Inhalt der Datei in der neuen Boot-Umgebung. OVERWRITE ist die Standardaktion, wenn im zweiten Feld kein anderer Wert angegeben wird. Handelt es sich bei dem Eintrag um ein Verzeichnis, so werden alle Unterverzeichnisse mitkopiert. Alle Dateien werden überschrieben. Die jeweilige Datei hat in der neuen Boot-Umgebung dasselbe Datum, denselben Modus und dieselben Eigentümer wie in der vorherigen Boot-Umgebung.
APPEND — Der Inhalt der Datei in der aktiven Boot-Umgebung wird an den Inhalt der Datei in der neuen Boot-Umgebung angehängt. Dies kann eventuell dazu führen, dass in der Datei doppelte Einträge vorkommen. Für Verzeichnisse ist die Option APPEND nicht zulässig. Die jeweilige Datei hat in der neuen Boot-Umgebung dasselbe Datum, denselben Modus und dieselben Eigentümer wie in der vorherigen Boot-Umgebung.
PREPEND — Der Inhalt der Datei in der aktiven Boot-Umgebung wird an den Anfang der Datei in der neuen Boot-Umgebung eingefügt. Dies kann eventuell dazu führen, dass in der Datei doppelte Einträge vorkommen. Für Verzeichnisse ist die Option PREPEND nicht zulässig. Die jeweilige Datei hat in der neuen Boot-Umgebung dasselbe Datum, denselben Modus und dieselben Eigentümer wie in der vorherigen Boot-Umgebung.
Wenn Sie zum ersten Mal von einer neu erstellten Boot-Umgebung booten, synchronisiert Solaris Live Upgrade die neue Boot-Umgebung mit der letzten aktiven Boot-Umgebung. Nach diesem ersten Start mit Synchronisierung führt Solaris Live Upgrade keine weitere Synchronisierung durch, es sei denn, dies wird explizit angefordert.
Um bei Verwendung der Benutzeroberfläche eine Synchronisierung zu erzwingen, geben Sie bei der entsprechenden Abfrage yes ein.
Um bei Verwendung der Befehlszeile eine Synchronisierung zu erzwingen, geben Sie den Befehl luactivate mit der Option -s ein.
Das Erzwingen einer Synchronisierung bietet sich beispielsweise bei Verwendung mehrerer Versionen des Betriebssystems Solaris an. Es ist anzunehmen, dass Änderungen in Dateien wie email oder passwd/group in der Boot-Umgebung, die Sie aktivieren möchten, vorhanden sein sollen. Wenn Sie eine Synchronisierung erzwingen, prüft Solaris Live Upgrade, ob es zwischen den zu synchronisierenden Dateien Konflikte gibt. Wenn beim Booten der neuen Boot-Umgebung ein Konflikt erkannt wird, wird eine Warnung ausgegeben. Die Dateien werden nicht synchronisiert. Die Boot-Umgebung kann trotz eines solchen Konflikts möglicherweise erfolgreich aktiviert werden. Ein Konflikt kann auftreten, wenn Sie sowohl in der neuen als auch in der aktiven Boot-Umgebung Änderungen an derselben Datei vornehmen. Nehmen wir beispielsweise an, Sie nehmen in der ursprünglichen Boot-Umgebung Änderungen an der Datei /etc/passwd vor. Anschließend nehmen Sie in der neuen Boot-Umgebung ebenfalls Änderungen an /etc/passwd vor. Nun kann der Synchronisierungsvorgang nicht entscheiden, welche der beiden Dateien er für die Synchronisierung kopieren soll.
Verwenden Sie diese Option sehr vorsichtig, denn Sie wissen möglicherweise gar nicht, welche Änderungen in der letzten aktiven Boot-Umgebung vorgenommen wurden und können diese nicht kontrollieren. Angenommen, Sie arbeiten in der aktuellen Boot-Umgebung mit der Solaris 9-Software. Sie müssen auf ein Solaris 7-Release zurückgreifen und booten dieses mit einer erzwungenen Synchronisation. Dies könnte dazu führen, dass Dateien im Release 7 geändert werden. Da Dateien vom jeweiligen Release des Betriebssystems abhängen, schlägt das Booten des Release Solaris 7 möglicherweise fehl, da die Solaris 9-Dateien nicht mit den Solaris 7-Dateien kompatibel sind.
Wenn Sie, beispielsweise über eine Tip-Verbindung, entfernt auf die zeichenorientierte Benutzeroberfläche zugreifen, müssen Sie die Umgebungsvariable TERM möglicherweise auf VT220 setzen. Setzen Sie bei der Arbeit mit CDE (Common Desktop Environment) außerdem die Variable TERM auf dtterm, anstatt auf xterm.