Il database CIM del repository WBEM può essere danneggiato nelle seguenti condizioni:
Viene applicata una revisione della patch 112945 per una versione di aggiornamento di Solaris 9 su un sistema che esegue l'ambiente operativo Solaris 9.
Si rimuove quindi la patch che era stata applicata al sistema.
Se il repository WBEM è danneggiato, il Visualizzatore log della Solaris Management Console presenta il seguente messaggio di errore:
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 la copia di 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. I dati eventualmente 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 i 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 il comando patchadd non trasmette il parametro corretto alla funzione remove_PATCH_PROPERTIES.
Per maggiori informazioni, vedere la pagina man patchadd( 1M).
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:
Installation of XXXXXX-YY failed: Attempting to patch a package that is not installed. |
Questi messaggi indicano che, poiché patchadd non ha rilevato la presenza sul sistema dei package che avrebbe dovuto correggere, la patch in oggetto è stata ignorata.
Il messaggio viene visualizzato quando il comando patchadd rileva 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. Ad esempio, è possibile che il package sia stato rimosso dall'amministratore di sistema o non sia mai stato installato. Questo tipo di errore si può verificare quando è stato installato un cluster più ridotto rispetto al cluster Entire Distribution.
Soluzione: Ignorare il messaggio di errore.
Dopo avere installato l'MU in modalità monoutente, non usare il comando exit. Usare il comando reboot. Se viene usato il comando exit al posto del comando reboot, si verificano i seguenti problemi:
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.
Il modulo 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 l'MU 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 l'installazione dell'MU in modalità multiutente e non è rimasta attiva alcuna connessione come utente root, riavviare il sistema.