In diesem Kapitel werden bekannte Probleme erläutert, die sich auf die Installation und Verwendung der Solaris 9 MU4-Software beziehen.
Die WBEM Repository-CIM-Datenbank kann unter den folgenden Umständen beschädigt werden:
Sie wenden eine überarbeitete Version von Patch 112945 für eine aktualisierte Solaris 9-Version auf ein System an, auf dem das Betriebssystem Solaris 9 ausgeführt wird.
Anschließend entfernen Sie diese Patches.
Wenn das WBEM Repository beschädigt ist, wird in Solaris Management Console Log Viewer die folgende Fehlermeldung 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 |
Abhilfemaßnahme: 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.
Sollte das WBEM Repository nach der Patch-Entfernung beschädigt sein, beenden Sie den WBEM-Server.
# /etc/init.d/init.wbem stop |
Stellen Sie das WBEM Repository aus der Sicherungskopie wieder her.
# cp -rf Pfad/logr /var/sadm/wbem/logr |
Starten Sie den WBEM-Server neu.
# /etc/init.d/init.wbem start |
Befolgen Sie diese Anweisungen, um ein neues WBEM Repository zu erstellen.
Bei diesem Verfahren werden die WBEM-Daten im Fall eines beschädigten WBEM Repository nicht wiederhergestellt. Alle während der Installation in das Repository aufgenommenen Daten gehen verloren.
Melden Sie sich als Superuser an.
Beenden Sie den WBEM-Server.
# /etc/init.d/init.wbem stop |
Löschen Sie die Dateien im Verzeichnis /logr.
# rm /var/sadm/wbem/logr/* |
Löschen Sie das Verzeichnis /notFirstTime.
# rmdir notFirstTime |
Starten Sie den WBEM-Server.
# /etc/init.d/init.wbem start |
Kompilieren Sie etwaige proprietäre MOF-Dateien manuell.
# /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 |
Abhilfemaßnahme: Ignorieren Sie die Fehlermeldungen. Die Meldung hat keine Auswirkung auf die Patch-Installation. Sie besagt lediglich, dass der Befehl patchadd nicht den richtigen Parameter an die Funktion remove_PATCH_PROPERTIES übergibt.
Weitere Informationen finden Sie in der Manpage patchadd( 1M).
Aufgrund von Problemen wegen der Interaktion zwischen sh(1) und ksh(1) installiert das Skript install_mu bestimmte Patches unter Umständen nicht korrekt. Dieser Fehler tritt auf, wenn Sie das Skript von der Befehlszeile oder von einem Verwaltungsskript aus mit folgendem Befehl starten:
# /bin/sh ./install_mu Optionen |
Abhilfemaßnahme: Führen Sie das Skript 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 besagen, dass der Befehl patchadd keine der zum Patchen vorgesehenen Pakete auf dem System finden konnte und das angegebene Patch deshalb übersprungen wurde.
Die Meldung wird angezeigt, wenn der Befehl patchadd bei der Installation eines Patches für eine Architektur auf einem System mit einer anderen Architektur eine Diskrepanz feststellt, zum Beispiel bei der Installation eines sun4u-Patch auf einem sun4m-System.
Außerdem wird diese Meldung unter Umständen dann ausgegeben, wenn eines oder mehrere Pakete nicht vorhanden sind. Dabei kann es sich um Pakete handeln, die entweder vom Administrator entfernt oder aber nie installiert wurden. Dieser Fehler tritt beispielsweise auf, wenn ein Cluster installiert wurde, das kleiner als die Entire Distribution ist.
Abhilfemaßnahme: Ignorieren Sie die Fehlermeldungen.
Geben Sie nach abgeschlossener MU-Installation im Einzelbenutzermodus nicht den Befehl exit ein. Geben Sie den Befehl reboot ein. Wenn exit anstelle von reboot verwendet wird, treten folgende Probleme auf:
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.
Das Modul pam_projects.so.1 führt einen Speicherabzug durch, wenn sich ein Benutzer oder Prozess anmelden will. Folgende Meldung wird angezeigt:
NOTICE: core_log: in.rshd[1479] core dumped: /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 ein Meldung der Art:
cron[1433]: load_modules: Modul /usr/lib/security/pam_projects.so.1 kann nicht geöffnet werden |
Diese Meldungen werden auch bei einer MU-Installation im Mehrbenutzermodus ausgegeben. In beiden Fällen werden die Meldungen nach einem Systemneustart nicht mehr angezeigt.
Abhilfemaßnahme: Wenn der Befehl exit nach der Installation im Einzelbenutzermodus verwendet wird, starten Sie das System neu.
Wenn der Befehl exit nach der MU-Installation im Mehrbenutzermodus verwendet wird und keine root-Benutzer mehr angemeldet sind, starten Sie das System neu.