Unter Umständen wird folgende Meldung angezeigt:
Das Solaris-Betriebssystem im Bereich c0t0d0s0 kann nicht aktualisiert werden. Ein Dateisystem, das in der Dateisystemtabelle (vfstab) aufgeführt ist, konnte nicht eingehängt werden. |
Möglicherweise verwechselt die Installationssoftware I-Knoten, die auf Stripe- DiskSuiteTM -Metageräten gespeichert sind, mit Root-I-Knoten. Die Metageräte werden dann versuchsweise als aufrüstbare Bereiche eingehängt. Wenn dieses Problem auftritt, schlägt der Einhängevorgang fehl, und die Installation wird abgebrochen.
Warnung: mod_install: MT-nicht sicherer Treiber 'tnatp' ignorierte Absturz[cpu0] / thread=7051e040:mutex-enter:bad_mutex lp=1046aa20 owner=7051e040 thread=7051e040
Für die Betriebssystemumgebung Solaris 7 ist ein Upgrade auf TotalNET Advanced Server (SunLinkTM), Version 5.2 erforderlich, da ein Treiberkonflikt aufgetreten ist. Bei Einsatz von Version 5.0 oder Version 5.1 für den TotalNET Advanced Server wird die Solaris 7-Betriebssystemumgebung nicht ordnungsgemäß gestartet.
Problemlösung: Vor der Installation von Solaris 7 müssen Sie sämtliche Installationen auf die Version 5.2 für den TotalNET Advanced Server aufrüsten. Diese Version ist von der CD Solaris Easy Access Server 2.0 erhältlich. Befolgen Sie die Anweisungen für die Aufrüstung bestehender TotalNET Advanced Server-Installationen.
Lesen Sie auf jeden Fall vor dem Starten des Upgrades Ihres x86-basierten Systems auf die Solaris 7-Betriebssystemumgebung die Fehlerbeschreibung mit der ID 4121281 durch.
Wenn Sie DiskSuiteTM ausführen und ein Upgrade auf Solaris 7 durchführen, müssen Sie ebenfalls ein Upgrade auf DiskSuite 4.2 vornehmen. DiskSuite 4.2 beinhaltet ein Skript mit der Bezeichnung metacvt, mit dem das Entfernen und Ersetzen der metadb-Repliken automatisiert wird. Mit Hilfe dieses Skripts können Sie die Bezeichnung des SCSI-Treibers, in dem die Repliken gespeichert sind, von cmdk in sd ändern, wenn Sie das Upgrade auf Solaris 7 und DiskSuite 4.2 durchführen.
Problemlösung: Um potentielle Datenverluste während der Aktualisierung auf das Solaris 7-Betriebssystem zu vermeiden, speichern Sie die Metageräte-Konfigurationen des Systems in Textdateien, und entfernen Sie die entsprechenden metadb-Repliken, bevor Sie ein x86-System aktualisieren, auf dem DiskSuite ausgeführt wird. Nach der Aktualisierung müssen Sie die Konfigurationen mit Hilfe des Befehlszeilen-Fensters von DiskSuite wiederherstellen.
Die Versionshinweise zu DiskSuite Version 4.2 enthalten Anleitungen für das Speichern von metadb-Konfigurationen, das Entfernen der metadb-Repliken, die Aktualisierung von x86-Systemen auf das Solaris 7-Betriebssystem, die Aktualisierung auf DiskSuite 4.2 sowie für das Wiederherstellen der Metageräte-Konfigurationen. Bourne-Shell-Skripts zur Automatisierung dieser Prozeduren werden für die Solaris 7-Betriebssystemumgebung zur Verfügung gestellt.
Ein Paket mit der Architektur und Version eines bereits installierten Pakets soll installiert werden. Durch diese Installation wird das betreffende Paket überschrieben.
Beim Aktualisieren eines Systems anhand von "Entire Distribution plus OEM Cluster" werden folgende Pakete scheinbar wiederholt hinzugefügt:
SUNWolinc
SUNWxwdim
SUNWxwinc
SUNWxwman
SUNWxwpmn
SUNWxwsrc
SUNWolbk
SUNWoldim
SUNWolman
SUNWolsrc
In "Installation der Solaris-Software - Fortschritt" wird gelegentlich der Abschluß der Installation angezeigt, obwohl diese noch läuft. Das Installationsprogramm fügt noch mehrere Minuten lang Pakete hinzu, obwohl die Installation gemäß der Anzeige bereits abgeschlossen ist. Verlassen Sie sich hinsichtlich des Abschlusses der Installation nicht auf diese Anzeige. Folgende Meldung wird angezeigt, sobald die Installation tatsächlich abgeschlossen ist:
Installation abgeschlossen |
Unter Umständen installiert JumpStart nicht den standardmäßigen Boot-Vorgang auf der aktuellen Standard-Boot-Platte. Dieses Problem kann bei Verwendung einer vollständig automatisierten Installation auf einer SPARCstationTM 5 mit zwei Festplatten auftreten. Daher wird beim Neustart statt der aktuellen Version die vorhergehende Version des Solaris-Betriebssystems gebootet.
Problemlösung: Installieren Sie die Solaris-Betriebssystemumgebung ohne JumpStartTM.
Bei der Aufrüstung des Solaris-Betriebssystems auf einem Server mit Clients ohne Massenspeicher werden die Optionen in der Datei dfstab für /usr nicht beibehalten. Tragen Sie beispielsweise in der Datei dfstab folgendes ein:
share -F nfs -o rw /export/exec/Solaris_2.7_sparc.all/usr |
Dann wird der Eintrag während der Aktualisierung automatisch durch folgende Zeile ersetzt:
share -F nfs -o ro /export/exec/Solaris_2.7_sparc.all/usr |
Problemlösung: Vor der Aktualisierung des Solaris-Betriebssystems auf einem OS-Server mit Clients ohne Massenspeicher oder mit SolsticeTM AutoClientTM sollten Sie die Datei /etc/dfs/dfstab für die Clients sichern.
Lesen Sie vor der Aktualisierung des x86-Systems auf die Solaris 7-Betriebssystemumgebung auf jeden Fall die Fehlerbeschreibung mit der ID 4121281, die bereits unter "Installationsfehler, die beim Start einer interaktiven Installation auftreten" im vorliegenden Kapitel beschrieben wurde, sowie alle übrigen in diesem Abschnitt angegebenen Fehlerbeschreibungen. Dieses Problem kann zu Datenverlusten führen.
Nach der Aktualisierung eines Servers mit Clients ohne Massenspeicher, die verschiedene SPARC-Kernel-Architekturen aufweisen (z. B. ein sun4u-Server mit folgenden Clients ohne Massenspeicher: sun4c, sun4d und sun4m), können die SUNWkvm-Pakete für Clients mit vom Server abweichender Kernel-Architektur nicht gepatcht werden.
Problemlösung: Fügen Sie manuell sämtliche SUNWkvm-Pakete hinzu, bevor Sie Patches anwenden, die sich darauf auswirken.
# pkgadd -d SUNWkvm.* |
Das Aktualisierungsprogramm kann den für die Aktualisierung der Solaris-Software auf dem System erforderlichen Speicherplatz um bis zu 30 Prozent überschätzen. Aus diesem Grund ist die Aktualisierung vieler Systeme nur möglich, wenn Pakete abgewählt werden oder zusätzlicher Speicherplatz bereitgestellt wird.
Problemlösung: Sie können Plattenspeicher manuell zwischen Dateisystemen aufteilen oder mit Hilfe des Menüs "Software anpassen" nicht benötigte Softwarepakete entfernen.
Von den SolsticeTM AutoClientsTM wird beim Neustart folgende Meldung angezeigt:
fsck -F cachefs: Cache-Verzeichnis /.cache/rootcache ist nicht vorhanden. mount -F cachefs: Einhängen von cache fsck fehlgeschlagen fsck -F cachefs: Cache-Verzeichnis /.cache/rootcache ist nicht vorhanden. mount -F cachefs: Einhängen von cache fsck fehlgeschlagen |
Durch diese Meldung wird dem Kernel mitgeteilt, daß es sich um ein Root-Dateisystem des Typs cachefs handelt. Um vor der Durchführung einer Aktualisierung festzustellen, ob ein bestimmter Solstice AutoClient möglicherweise von diesem Problem beeinträchtigt wird, untersuchen Sie das Verzeichnis /export/root//var/sadm/pkg auf dem Server (hierbei handelt es sich um das Verzeichnis /var/sadm/pkg von Solstice AutoClient). Wenn dieses Verzeichnis ein Unterverzeichnis namens TADcar enthält, kann sich das Problem auf die Solstice AutoClients auswirken.
Problemlösung: Bearbeiten Sie nach der Aktualisierung die Datei /etc/system für die Solstice AutoClients, indem Sie folgende Zeile anhängen:
rootfs:cachefs |
Die Datei /etc/system der Solstice AutoClients ist auf dem Server unter dem Namen /etc/root//etc/system gespeichert.