Il database CIM del repository WBEM può danneggiarsi nelle seguenti condizioni:
Viene applicata una delle seguenti patch degli ambienti operativi Solaris 9 9/02, 12/02 o 4/03 a un sistema che esegue l'ambiente operativo Solaris 9.
Versione |
Patch |
---|---|
Solaris 9 9/02 |
112945-03 |
Solaris 9 12/02 |
112945-05 |
Solaris 9 4/03 |
112945-14 |
Viene quindi rimossa dal sistema una delle patch elencate qui sopra.
Se il repository WBEM si danneggia, viene visualizzato il seguente messaggio di errore nel visualizzatore log della Solaris Management Console.
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 |
Soluzione: Scegliere una delle soluzioni seguenti.
Procedere come segue per evitare che il repository WBEM venga danneggiato.
Diventare superutente.
Prima di applicare la patch, eseguire un backup del repository WBEM.
# cp -r /var/sadm/wbem/logr percorso/logr |
Nell'esempio precedente, percorso indica il percorso del backup del repository WBEM.
Se il repository WBEM viene danneggiato dopo la rimozione della patch, arrestare il server WBEM.
# /etc/init.d/init.wbem stop |
Ripristinare il backup del repository WBEM.
# cp -rf percorso/logr /var/sadm/wbem/logr |
Riavviare il server WBEM.
# /etc/init.d/init.wbem start |
Procedere come segue per creare un nuovo repository WBEM.
Questa soluzione non ripristina i dati WBEM se il repository WBEM è danneggiato. Eventuali dati aggiunti al repository durante l'installazione vengono perduti.
Diventare superutente.
Arrestare il server WBEM.
# /etc/init.d/init.wbem stop |
Rimuovere i file dalla directory /logr.
# rm /var/sadm/wbem/logr/* |
Rimuovere la directory /notFirstTime.
# rmdir notFirstTime |
Avviare il server WBEM.
# /etc/init.d/init.wbem start |
Compilare manualmente eventuali MOF proprietari.
# /usr/sadm/bin/mofcomp file-MOF |
Se si installa una patch che supporta più architetture per i package viene visualizzato un messaggio di errore simile al seguente in /var/sadm/install_data/Maintenance_Update_log.
Installazione di xxxxxx-yy (x di xx) Per ulteriori dettagli vedere /var/sadm/patch/xxxxxx-yy/log grep: impossibile aprire nomepkg.estensione/pkginfo |
Ad esempio, se la patch 123456-01 contiene i package di patch SUNWcar e SUNWcar.u viene visualizzato il seguente messaggio di errore.
grep: impossibile aprire SUNWcar.u/pkginfo |
Soluzione: Ignorare il messaggio di errore. Il messaggio non compromette l'installazione della patch. Il messaggio indica che patchadd(1M) non trasmette il parametro corretto alla funzione remove_PATCH_PROPERTIES().
A causa di problemi legati alle interazioni tra sh(1) e ksh(1), l'utility install_mu potrebbe non installare alcune patch in modo corretto. L'errore si verifica se l'utility viene avviata con il seguente comando dalla riga di comando o da uno script di amministrazione:
# /bin/sh ./install_mu opzioni |
Soluzione: Eseguire install_mu dalla riga di comando o da uno script di amministrazione come segue:
# ./install_mu opzioni |
Uno dei seguenti messaggi, che non hanno effetti avversi, può essere visualizzato nel file Maintenance_Update_log nella directory /var/sadm/install_data:
Uno o più package di patch inclusi in XXXXXX-YY non sono installati su questo sistema. Patchadd sta terminando. |
Oppure:
Installazione di XXXXXX-YY non riuscita: Attempting to patch a package that is not installed. |
Questi messaggi indicano che patchadd non ha trovato sul sistema i package su cui applicare le patch specificate, che perciò vengono ignorate.
Il messaggio viene visualizzato quando patchadd nota una discrepanza durante l'installazione di una patch per una architettura su un sistema con una diversa architettura. Ad esempio, una patch sun4u su un sistema sun4m.
I messaggi possono anche essere il risultato di uno o più package mancanti. I package possono essere stati rimossi dall'amministratore o non essere mai stati installati se sul sistema è presente un cluster più ridotto del gruppo "Entire Distribution".
Soluzione: Ignorare il messaggio.
Dopo avere installato il sistema in modalità monoutente, non usare il comando exit. Usare il comando reboot. Se viene usato il comando exit al posto del comando reboot, si verifica quanto segue:
Il sistema viene riportato al livello init 3 e non è possibile eseguire il login fino al reboot.
Nessun altro utente può eseguire il login finché il sistema non viene riavviato.
pam_projects.so.1 produce un file core quando gli utenti tentano di eseguire il login. Viene visualizzato il messaggio seguente:
NOTICE: core_log: in.rshd[1479] core dumped: /var/crash/core.in.rshd.1479 |
Se un processo cerca di accedere al modulo pam_projects.so.1, nella console di sistema vengono visualizzati messaggi relativi al caricamento del modulo. Compare un messaggio simile al seguente:
cron[1433]: load_modules: can not open module /usr/lib/security/pam_projects.so.1 |
Questi messaggi vengono visualizzati anche se MU3 viene installato in modalità multiutente. In entrambi i casi, i messaggi non vengono più visualizzati dopo il riavvio del sistema.
Soluzione: Se è stato usato il comando exit dopo un'installazione in modalità monoutente, riavviare il sistema.
Se è stato usato il comando exit dopo un'installazione in modalità multiutente e non è rimasta alcuna connessione come utente root, riavviare il sistema.