In diesem Kapitel werden bekannte Probleme erläutert, die sich auf die Installation und Verwendung der Solaris 9 MU3-Software beziehen.
Die CIM-Datenbank des WBEM-Repository wird unter folgenden Bedingungen möglicherweise beschädigt:
Sie wenden eines der folgenden Patches aus der Betriebssystemumgebung Solaris 9 9/02, 12/02 oder 4/03 auf ein System an, auf dem die Betriebssystemumgebung Solaris 9 ausgeführt wird.
Version |
Patch |
---|---|
Solaris 9 9/02 |
112945-03 |
Solaris 9 12/02 |
112945-05 |
Solaris 9 4/03 |
112945-14 |
Danach entfernen Sie eins der zuvor genannten Patches, das auf das System angewendet wurde.
Wenn das WBEM-Repository beschädigt ist, wird die folgende Fehlermeldung im Protokoll-Viewer der Solaris Management Console angezeigt.
CIM_ERR_FAILED: /usr/sadm/lib/wbem/../../../../var/sadm/wbem/logr/ preReg/PATCH113829install/Solaris_Application.mof,18,ERR_SEM, ERR_EXC_SET_CLASS,CIM_ERR_FAILED:Other Exception: java.io.StreamCorruptedException: invalid stream header |
Lösung: Wählen Sie eine der folgenden Problemlösungen:
Führen Sie die folgenden Schritte aus, um eine Beschädigung des WBEM-Repository zu vermeiden.
Melden Sie sich als Superuser an.
Erstellen Sie eine Sicherungskopie des WBEM-Repository, bevor Sie Patches anwenden.
# cp -r /var/sadm/wbem/logr Pfad/logr |
Im Beispiel oben steht Pfad für den Pfad der Sicherungskopie des WBEM-Repository.
Wenn das WBEM-Repository nach dem Zurücksetzen des Patches beschädigt ist, stoppen Sie den WBEM-Server.
# /etc/init.d/init.wbem stop |
Stellen Sie das WBEM-Repository anhand der Sicherungskopie wieder her.
# cp -rf Pfad/logr /var/sadm/wbem/logr |
Starten Sie den WBEM-Server neu.
# /etc/init.d/init.wbem start |
Führen Sie die folgenden Schritte aus, um ein neues WBEM-Repository zu erstellen.
Bei dieser Lösung werden die WBEM-Daten nicht wiederhergestellt, wenn das WBEM-Repository beschädigt ist. Alle Daten, die während der Installation zum Repository hinzugefügt wurden, gehen verloren.
Melden Sie sich als Superuser an.
Stoppen Sie den WBEM-Server.
# /etc/init.d/init.wbem stop |
Entfernen Sie die Dateien aus dem Verzeichnis /logr.
# rm /var/sadm/wbem/logr/* |
Entfernen Sie das Verzeichnis /notFirstTime.
# rmdir notFirstTime |
Starten Sie den WBEM-Server.
# /etc/init.d/init.wbem start |
Kompilieren Sie alle proprietären MOFs von Hand.
# /usr/sadm/bin/mofcomp MOF-Dateiname |
Werden Patches installiert, die Unterstützung für unterschiedliche Paketarchitekturen bieten, so erscheint in /var/sadm/install_data/Maintenance_Update_log möglicherweise eine der nachfolgenden, rein informativen Fehlermeldungen.
Installing xxxxxx-yy (x of xx) See /var/sadm/patch/xxxxxx-yy log for details grep: can't open paketabk.erweiterung/pkginfo |
Wenn zum Beispiel Patch 123456-01 die Patch-Pakete SUNWcar und SUNWcar.u enthält, erscheint folgende Fehlermeldung.
grep: can't open SUNWcar.u/pkginfo |
Lösung: Ignorieren Sie die Fehlermeldungen. Die Meldung hat keine Auswirkung auf die Patch-Installation. Die Meldung besagt lediglich, dass patchadd(1M) nicht den richtigen Parameter an die Funktion remove_PATCH_PROPERTIES () übergibt.
Aufgrund von Problemen wegen der Interaktion zwischen sh(1) und ksh(1) installiert das Dienstprogramm install_mu bestimmte Patches unter Umständen nicht korrekt. Dieser Fehler tritt auf, wenn Sie das Dienstprogramm von der Befehlszeile oder von einem Verwaltungsskript aus mit folgendem Befehl starten:
# /bin/sh ./install_mu Optionen |
Lösung: Führen Sie das Programm install_mu folgendermaßen von der Befehlszeile oder über ein Verwaltungsskript aus:
# ./install_mu Optionen |
In der Datei Maintenance_Update_log im Verzeichnis /var/sadm/install_data wird möglicherweise eine der folgenden, rein informativen Fehlermeldungen angezeigt:
Ein oder mehrere Patch-Pakete von XXXXXX-YY sind auf diesem System nicht installiert. Patchadd wird beendet. |
Oder:
Installation von XXXXXX-YY ist fehlgeschlagen: Es wurde versucht, ein Patch für ein Paket auszuführen, das nicht installiert ist. |
Diese Meldungen weisen darauf hin, dass patchadd auf Ihrem System keines der Pakete finden konnte, auf die patchadd ein Patch anwenden sollte. Das angegebene Patch wurde daher übersprungen.
Die Meldung wird angezeigt, wenn patchadd bei der Installation eines Patch für eine Architektur auf einem System mit einer anderen Architektur eine Diskrepanz feststellt, zum Beispiel bei der Installation eines sun4u-Patch in einem sun4m-System.
Außerdem wird diese Meldung unter Umständen dann ausgegeben, wenn eines oder mehrere Pakete nicht vorhanden sind. Möglicherweise wurde das Paket vom Administrator entfernt oder wurde überhaupt nie installiert, zum Beispiel bei der Installation eines Clusters, das nicht die gesamte Distribution umfasste.
Lösung: Ignorieren Sie die Meldung.
Geben Sie nach abgeschlossener Installation im Einzelbenutzermodus nicht den Befehl exit ein. Geben Sie den Befehl reboot ein. Wenn exit anstelle von reboot verwendet wird, geschieht Folgendes:
Das System wird auf init 3 gesetzt und Sie können sich erst nach einem Neustart des Systems wieder anmelden.
Es kann sich kein anderer Benutzer anmelden, bis das System neu gestartet wird.
pam_projects.so.1 führt einen Speicherabzug durch, wenn sich ein Benutzer oder Prozess anmelden will. Folgende Meldung wird angezeigt:
HINWEIS: core_log: in.rshd[1479] Speicherabzug geschrieben: /var/crash/core.in.rshd.1479 |
Wenn ein Prozess versucht, auf das Modul pam_projects.so.1 zuzugreifen, werden auf der Systemkonsole Meldungen über das Laden von Modulen (load module) angezeigt. Sie sehen dann eine Meldung wie folgende:
cron[1433]: load_modules: Modul /usr/lib/security/pam_projects.so.1 kann nicht geöffnet werden |
Diese Meldungen werden auch dann ausgegeben, wenn MU3 im Mehrbenutzermodus installiert wurde. In beiden Fällen werden die Meldungen nach einem Systemneustart nicht mehr angezeigt.
Lösung: Wenn der Befehl exit nach der Installation im Einzelbenutzermodus verwendet wird, starten Sie das System neu.
Wenn der Befehl exit nach der Installation im Mehrbenutzermodus verwendet wird und keine root-Benutzer mehr angemeldet sind, starten Sie das System neu.