test

Note su Solaris 9 12/03

Problemi di amministrazione del sistema

Il comando patchadd installa una patch firmata se sono presenti due patch identiche nella stessa posizione (4949580)

Se si estrae il contenuto di una patch firmata nella stessa directory in cui si trova la patch, quest'ultima non può essere installata con il comando /usr/sbin/patchadd. La patch firmata viene invece installata eseguendo /usr/sbin/patchadd ./id_patch. La patch estratta non firmata viene ignorata.

In alcuni casi vengono visualizzati i seguenti messaggi di errore: 


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 id_patch.
Patchadd is terminating.

Soluzione: scegliere una delle soluzioni seguenti:

Nota –

Sostituire la password predefinita changeit con la password usata per proteggere il keystore Java.

Il comando lucreate non riesce se il nome del dispositivo di storage attivato è un sottoinsieme di un altro dispositivo di storage attivato, o se è un dispositivo di storage utilizzato per un nuovo ambiente di boot (4912890)

Quando si utilizza il comando lucreate per creare un nuovo ambiente di boot, il comando non riesce nei seguenti casi:

Vengono visualizzati erroneamente i seguenti messaggi di errore: 


L'utility di creazione dei file system 
/usr/lib/fs/ufsufs/mkfs non è disponibile.
 

Impossibile creare tutti i file system richiesti 
per l'ambiente di boot ambiente-boot.
 

Impossibile creare i file system per l'ambiente 
di boot ambiente-boot

Soluzione: verificare che non vi siano file system in uso sui dispositivi di storage i cui nomi sono sottoinsiemi di altri dispositivi di storage con file system anch'essi in uso.

In caso di ambiguità tra i nomi dei file system attivati, rinominare i metadevice di Solaris Volume Management.

Nella soluzione seguente, d10 e d100 vengono usati solo a titolo di esempio. Altri esempi di nomi di dispositivo ambigui sono d20 e d200 o d377 e d37, dove d20 interferisce con d200 e d377 interferisce con d37.

  1. Diventare superutente.

  2. Usare il comando metarename per rinominare uno dei metadevice con il nome ambiguo. 


    # metarename d10 d300

    Il metadevice d10 viene rinominato in d300.

Nota –

Il file system su d10 deve essere disattivato prima di utilizzare il comando metarename.

Dopo aver disattivato il file system, aprire con un editor il file /etc/vfstab e qualunque altro file di configurazione che contenga il nome del metadevice da rinominare. Sarà necessario cambiare ogni riferimento al vecchio nome del metadevice sostituendolo con il nuovo nome.

Se non è possibile disattivare il file system con il sistema in esecuzione in modalità multiutente perché un processo sta accedendo ai dati del file system, portare il sistema in modalità monoutente per disattivare il file system. Al termine delle modifiche, riavviare il sistema.

La presenza del file /etc/named.conf non consente di eseguire le operazioni della Solaris Management Console (SMC) sugli account utente e di gruppo (4777931)

Se si utilizza la Solaris Management Console per eseguire operazioni su un account utente o di gruppo su un sistema utilizzato come server DNS (Domain Name Service) e sul sistema è presente il file /etc/named.conf, le operazioni generano errori.

Gli errori seguenti si verificano quando si eseguono le operazioni indicate dall'interfaccia utente grafica (GUI) o quando si usano i comandi smuser e smgroup della console dalla riga di comando.

Se si esegue smuser per un utente, la console avvia una nuova finestra di dialogo o il comando si interrompe con i seguenti messaggi di errore: 


"La visualizzazione degli utenti o dei ruoli non è riuscita a causa
di un errore inatteso.
        L'errore è stato il seguente: CIM_ERR_FAILED."

Se si esegue smgroup per un gruppo, la console avvia una nuova finestra di dialogo o il comando si interrompe con i seguenti messaggi di errore: 


"Lettura degli ID dei gruppi non riuscita per errore CIM inatteso:
        CIM_ERR_FAILED."

Soluzione: scegliere una delle soluzioni seguenti:

Per maggiori informazioni vedere le pagine man smuser( 1M) e smgroup (1M).

x86: Premendo il tasto F4 durante il boot del BIOS, la partizione di servizio non viene avviata (4782757)

Quando si avvia un sistema Sun LX50 che dispone di una partizione di servizio e su cui è installato Solaris 9 12/03 (Edizione per piattaforma x86), viene offerta la possibilità di premere il tasto F4 per avviare la partizione di servizio. Tuttavia, premendo il tasto F4, lo schermo diventa bianco e la partizione di servizio non viene avviata.

Soluzione: non premere il tasto F4 mentre è visualizzata la schermata di boot del BIOS. Dopo un periodo di timeout, compare la schermata con le informazioni sulla partizione attiva del disco. Nella colonna del numero di partizione, selezionare il numero corrispondente a type=DIAGNOSTIC. Premere Return. Il sistema avvia la partizione di servizio.

I sistemi UltraSPARC II non producono sempre il messaggio CP Event (4732403)

Sui sistemi UltraSPARC II che eseguono Solaris 9 12/03, il messaggio CP Event che accompagna alcuni messaggi di errore fatale della memoria non viene sempre prodotto. Il problema si verifica ad esempio sui seguenti sistemi:

Di conseguenza, possono a volte mancare alcune informazioni necessarie per identificare le CPU guaste.

Soluzione: per informazioni aggiornate a questo riguardo, accedere al sito Web di SunSolveSM all'indirizzo http://sunsolve.sun.com.

Il daemon di Solaris WBEM Services 2.5 non trova i provider delle API com.sun (4619576)

Il daemon di Solaris WBEM Services 2.5 non riesce a trovare i provider scritti per l'interfaccia com.sun.wbem.provider o per l'interfaccia com.sun.wbem.provider20. Il problema persiste anche se si crea un'istanza di Solaris_ProviderPath per un provider scritto per queste interfacce.

Soluzione: arrestare e riavviare il daemon di Solaris WBEM Services 2.5. 


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

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

Se si utilizza la API javax per creare il provider, non è necessario arrestare e riavviare il daemon di Solaris WBEM Services 2.5, poiché questo daemon riconosce dinamicamente i provider javax.

Alcune chiamate ai metodi della API com.sun non riescono con il protocollo di trasporto XML/HTTP (4497393, 4497399, 4497406, 4497411)

Se si sceglie di usare la API com.sun al posto della API javax per sviluppare un software WBEM, sono pienamente supportate solo le chiamate remote (RMI) ai metodi CIM (Common Information Model). Non è garantito che altri protocolli, ad esempio XML/HTTP, funzionino perfettamente con la API com.sun.

La tabella seguente riporta alcuni esempi di chiamate che vengono eseguite correttamente con RMI ma non con XML/HTTP.

Chiamata del metodo  

Messaggio di errore  

CIMClient.close()

NullPointerException

CIMClient.execQuery()

CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED

CIMClient.getInstance()

CIM_ERR_FAILED

CIMClient.invokeMethod()

XMLERROR: ClassCastException

Non è possibile modificare le proprietà di attivazione dei file system con lo strumento “Attivazioni e condivisioni” della Solaris Management Console (4466829)

Lo strumento “Attivazioni e condivisioni” della Solaris Management Console non permette di modificare le opzioni di attivazione dei file system di importanza critica / (radice), /usr e /var.

Soluzione: scegliere una delle seguenti procedure:

L'aggiunta di dati con WBEM genera un errore CIM_ERR_LOW_ON_MEMORY (4312409)

Quando la memoria disponibile è ridotta, viene generato il seguente messaggio di errore: 


CIM_ERR_LOW_ON_MEMORY

Quando il gestore di oggetti CIM (Common Information Model) dispone di poca memoria, non è possibile aggiungere altre voci. È necessario ripristinare il repository del gestore di oggetti.

Soluzione: per ripristinare il repository del gestore di oggetti CIM, procedere come segue:

  1. Diventare superutente.

  2. Arrestare il gestore di oggetti CIM. 


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

  3. Rimuovere la directory di log JavaSpacesTM. 


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

  4. Riavviare il gestore di oggetti CIM. 


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

    Quando si ripristina il repository del gestore di oggetti CIM, si perdono le definizioni proprietarie incluse nel datastore. Sarà perciò necessario ricompilare i file MOF che contengono queste definizioni usando il comando mofcomp. Vedere l'esempio seguente: 


    # /usr/sadm/bin/mofcomp -u root -p password-di-root file-mof