test

Solaris 9 12/03 Versionshinweise

Fehler im Zusammenhang mit der Systemadministration

patchadd installiert signierten Patch, wenn zwei identische Patches an demselben Speicherort existieren (4949580)

Wird der Inhalt eines signierten Patches in dasselbe Verzeichnis wie der signierte Patch entpackt, so kann der entpackte Patch nicht mehr mit /usr/sbin/patchadd installiert werden. Stattdessen wird bei der Ausführung von /usr/sbin/patchadd ./Patch-ID der signierte Patch installiert. Der unsignierte entpackte Patch wird ignoriert.

Unter Umständen kann dabei auch folgende Fehlermeldung auftreten: 


Verifying signed patch patchid...
ERROR: Unable to open keystore /var/sadm/security/patchadd
/truststore for reading
ERROR: Unable to lock keystore /var/sadm/security
for exclusive access
Signature invalid on signed patch patchid.
Patchadd is terminating.

Abhilfemaßnahme: Wählen Sie eine der folgenden Problemlösungen:

Hinweis –

Ändern Sie dabei das Standardpasswort changeit auf das korrekte Passwort für den Java-Keystore.

Der Befehl lucreate schlägt fehl bei Namensüberschneidungen zweier eingehängter Speichergeräte oder eines eingehängten und eines als neue Boot-Umgebung verwendeten Speichergeräts (4912890)

Unter den folgenden Umständen schlägt der Befehl lucreate zum Erstellen einer neuen Boot-Umgebung fehl:

Es werden die folgenden irreführenden Fehlermeldungen angezeigt: 


The file system creation utility /usr/lib/fs/ufsufs/mkfs is not available.
 

Unable to create all required file systems for boot-environment.
 

Cannot make file systems for boot-environment

Abhilfemaßnahme: Vergewissern Sie sich, dass keine Dateisysteme auf Speichergeräten in Gebrauch sind, deren Gerätenamen im Gerätenamen anderer Speichergeräte enthalten sind, die ebenfalls gerade verwendet werden.

Sollten unter den eingehängten Dateisystemen derartige Überschneidungen der Gerätenamen bestehen, benennen Sie die vorhandenen Solaris Volume Management-Metageräte um.

In der folgenden Abhilfemaßnahme werden d10 und d100 nur als Beispiele herangezogen. Weitere Beispiele für Überschneidungen zwischen Gerätenamen sind d20 und d200 oder d377 und d37, wobei sich d20 mit d200 und d377 mit d37 überschneiden.

  1. Melden Sie sich als Superuser an.

  2. Verwenden Sie den Befehl metarename, um eines der Metageräte mit mehrdeutigem Namen umzubenennen. 


    # metarename d10 d300

    Das Metagerät d10 wird in d300 umbenannt.

Hinweis –

Bevor Sie den Befehl metarename ausführen, müssen Sie das Dateisystem auf d10 aushängen.

Während das Dateisystem nun ausgehängt ist, können Sie die Datei /etc/vfstab entsprechend bearbeiten. Denken Sie dabei auch an eventuelle weitere Konfigurationsdateien, die den Namen des umzubenennenden Metageräts enthalten. Sie müssen jeden Verweis auf den alten Metagerätenamen aktualisieren.

Sollte gerade ein Prozess auf Daten im betreffenden Dateisystem zugreifen, fahren Sie das System in einen Einzelbenutzermodus herunter, um das Dateisystem auszuhängen. Starten Sie das System neu, nachdem Sie die Änderungen vorgenommen haben.

Vorhandensein der Datei /etc/named.conf bringt Solaris Management Console-Operationen an Benutzer- und Gruppenkonten zum Scheitern (4777931)

Wenn Sie mit der Solaris Management Console Verwaltungsvorgänge an Benutzer- oder Gruppenkonten durchführen und das betreffende System gleichzeitig als DNS-Server (Domain Name Service) fungiert, treten Fehler auf. Dies ist genauer gesagt dann der Fall, wenn auf dem System die Datei /etc/named.conf existiert.

Die folgenden Fehler treten auf, wenn Sie diese Operationen über die grafische Benutzeroberfläche (GUI) oder anhand der Befehlszeilenschnittstellen smuser und smgroup durchführen.

Die Konsole öffnet einen neuen Dialog, oder smuser (bei Anwendung auf ein Benutzerkonto) wird beendet und meldet den Fehler: 


"Der Versuch, Benutzer oder Aufgabenbereiche anzuzeigen, ist
aufgrund eines unerwarteten Fehlers fehlgeschlagen.
Ursache hierfür war folgender Fehler: CIM_ERR_FAILED."

Die Konsole öffnet einen neuen Dialog, oder smgroup (bei Anwendung auf ein Gruppenkonto) wird beendet und meldet den Fehler: 


"Der Versuch, Gruppenkennungen zu lesen, ist mit unerwartetem
CIM-Fehler fehlgeschlagen: CIM_ERR_FAILED."

Abhilfemaßnahme: Wählen Sie eine der folgenden Problemlösungen:

Weitere Informationen entnehmen Sie bitte den Manpages smuser( 1M) und smgroup (1M).

x86: Die Service-Partition wird durch Betätigung von F4 beim Hochfahren des BIOS nicht gebootet (4782757)

Sie booten ein Sun LX50-System, das über eine Service-Partition verfügt und auf dem die Solaris 9 12/03-Software (x86 Platform Edition) installiert ist. Wenn Sie nun bei der entsprechenden Option die Funktionstaste F4 drücken, erscheint nur ein leerer Bildschirm. Die Service-Partition wird nicht gebootet.

Abhilfemaßnahme: Drücken Sie die Taste F4 während der Anzeige des BIOS-Startbildschirms nicht. Nach einer festgelegten Zeit erscheint der Bildschirm "Current Disk Partition Information“. Wählen Sie in der Spalte Part# die zu type=DIAGNOSTIC gehörige Nummer aus. Drücken Sie die Eingabetaste. Das System bootet die Service-Partition.

CP-Ereignismeldung auf UltraSPARC II wird nicht immer generiert (4732403)

In Solaris 9 12/03 auf UltraSPARC II-basierten Systemen wird die CP-Ereignismeldung, die einige unkorrigierbare Speicherfehler (Uncorrectable Memory Error) begleitet, nicht immer generiert. Folgende Systeme sind betroffen:

Dies hat zur Folge, dass gewisse Informationen zur Identifikation einer problematischen CPU eventuell nicht immer verfügbar sind.

Abhilfemaßnahme: Aktuelle Informationen zu diesem Problem finden Sie auf der SunSolveSM Website unter http://sunsolve.sun.com.

Der Solaris WBEM Services 2.5-Dämon findet com.sun-API-Provider nicht (4619576)

Der Solaris WBEM Services 2.5-Dämon findet Provider nicht, auf die über die Schnittstellen com.sun.wbem.provider bzw. com.sun.wbem.provider20 zugegriffen wird. Der Dämon findet den betreffenden Provider selbst dann nicht, wenn für diesen eine Solaris_ProviderPath-Instanz angelegt wird.

Abhilfemaßnahme: Damit der Solaris WBEM Services 2.5-Dämon einen derartigen Provider finden kann, muss er angehalten und neu gestartet werden. 


# /etc/init.d/init.wbem stop

# /etc/init.d/init.wbem start
Hinweis –

Wenn Sie Ihren Provider unter Verwendung der javax-API entwickeln, ist kein Neustart des Solaris WBEM Services 2.5-Dämons erforderlich. javax-Provider werden vom Solaris WBEM Services 2.5-Dämon automatisch erkannt.

Bestimmte com.sun API-Methodenaufrufe schlagen unter dem Transportprotokoll XML/HTTP fehl (4497393, 4497399, 4497406, 4497411)

Wenn Sie Ihre WBEM-Software mit der com.sun-API anstatt mit der javax-API entwickeln, wird nur der CIM-Fernmethodenaufruf (RMI) vollständig unterstützt (CIM steht für Common Information Model). Für andere Protokolle wie beispielsweise XML/HTTP kann nicht gewährleistet werden, dass eine vollständige und fehlerfreie Zusammenarbeit mit der com.sun-API möglich ist.

In der folgenden Tabelle sehen Sie Beispiele für Aufrufe, die unter RMI erfolgreich verlaufen, aber unter XML/HTTP fehlschlagen:

Methodenaufruf  

Fehlermeldung  

CIMClient.close()

NullPointerException

CIMClient.execQuery()

CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED

CIMClient.getInstance()

CIM_ERR_FAILED

CIMClient.invokeMethod()

XMLERROR: ClassCastException

Mount-Eigenschaften für Dateisysteme können mit dem Solaris Management Console-Tool Mounts and Shares nicht bearbeitet werden (4466829)

Das Tool Mounts and Shares von Solaris Management Console ist nicht in der Lage, Mount-Optionen für systemkritische Dateisysteme wie root /, /usr und /var zu ändern.

Abhilfemaßnahme: Wählen Sie eine der folgenden Problemlösungen:

Fehler CIM_ERR_LOW_ON_MEMORY beim Hinzufügen von Daten mit WBEM (4312409)

Bei niedriger Speicherverfügbarkeit erscheint folgende Fehlermeldung: 


CIM_ERR_LOW_ON_MEMORY

Wenn der CIM Object Manager nur über wenig freien Speicher verfügt, können Sie keine weiteren Einträge hinzufügen. Sie müssen das Repository des CIM Object Manager zurücksetzen.

Abhilfemaßnahme: Setzen Sie wie folgt das Repository von CIM Object Manager zurück:

  1. Melden Sie sich als Superuser an.

  2. Halten Sie den CIM Object Manager an. 


    # /etc/init.d/init.wbem stop

  3. Löschen Sie das JavaSpacesTM-Protokollverzeichnis. 


    # /bin/rm -rf /var/sadm/wbem/log

  4. Starten Sie den CIM Object Manager neu. 


    # /etc/init.d/init.wbem start
    Hinweis –

    Beim Zurücksetzen des CIM Object Manager-Repository gehen ggf. gespeicherte eigene Definitionen verloren. In diesem Fall müssen Sie die MOF-Dateien mit den entsprechenden Definitionen mit dem Befehl mofcomp neu kompilieren. Hierzu ein Beispiel: 


    # /usr/sadm/bin/mofcomp -u root -p root-Passwort mof-Datei