test

Note su Solaris 10

Amministrazione del sistema

Questa sezione descrive i problemi di Solaris 10 connessi all'amministrazione dei sistemi.

Sun Patch Manager Tool 2.0 non è compatibile con le versioni precedenti

Un sistema che esegue Sun Patch Manager Tool 2.0 può gestire i sistemi remoti che utilizzano Patch Manager Tool, anche nella versione 1.0.

Tuttavia, un sistema con una versione precedente di Patch Manager Tool non può gestire i sistemi remoti che utilizzano Patch Manager Tool 2.0. Le versioni precedenti includono:

Nota –

Il sistema operativo Solaris 8 non supporta il modello CIM/WBEM (Common Information Model/Web Based Enterprise Management) per Patch Manager Tool. Ciò comporta che sui sistemi Solaris 8 non è possibile eseguire la gestione remota con Patch Manager.

Sun Remote Services Net Connect è supportato solo nella zona globale

Sun Remote Services (SRS) Net Connect è supportato solo nella zona globale. Vengono generati messaggi di errore se si esegue una delle seguenti operazioni:

Vengono generati i seguenti messaggi di errore:


*** installazione del pacchetto SUNWcstu non riuscita - 
amministrazione interattiva richiesta:

Script di richiesta interattivo fornito dal software
pkgadd: ERRORE: lo script di richiesta non è 
stato completato correttamente

L'installazione di SUNWcstu è stata sospesa (è richiesta un'interazione).
Non sono state apportate modifiche al sistema.  

*** installazione del pacchetto SUNWfrunc non riuscita - 
amministrazione interattiva richiesta:

Script di richiesta interattivo fornito dal software
pkgadd: ERRORE: lo script di richiesta non è 
stato completato correttamente

L'installazione di SUNWfrunc è stata sospesa (è richiesta un'interazione).
Non sono state apportate modifiche al sistema.

Soluzione: ignorare i messaggi di errore.

Vengono visualizzati messaggi di errore o di avvertimento durante l'installazione di zone non globali con il comando zoneadm

Durante l'installazione di una zona non globale con il comando zoneadm, vengono visualizzati messaggi di errore o di avvertimento durante l'installazione dei pacchetti. I messaggi generati sono simili ai seguenti:


Preparazione dell'installazione della zona zona1.
Creazione dell'elenco dei file da copiare dalla zona globale.
Copia di 2348 file nella zona.
Inizializzazione del registro prodotti della zona.
Determinazione dell'ordine di inizializzazione dei pacchetti della zona.
Preparazione dell'inizializzazione di 790 pacchetti sulla zona.
Inizializzati 790 pacchetti sulla zona.
La zona zona1 è inizializzata.

L'installazione di questi pacchetti ha generato degli errori: 
SUNWjhrt SUNWmcc SUNWjhdev SUNWnsb SUNWmcon SUNWmpatchmgr

L'installazione di questi pacchetti ha generato dei messaggi di avvertenza: 
SUNWj3rt SUNWmc SUNWwbmc SUNWmga SUNWdclnt SUNWlvma SUNWlvmg 
SUNWrmui SUNWdoc SUNWpl5m SUNWpmgr

I problemi relativi all'installazione dei pacchetti vengono anche registrati in /export/zone1/root/var/sadm/system/logs/install_log, che contiene un log dell'installazione della zona.

Soluzione: nessuna.

Nota –

La zona non globale può continuare a essere utilizzata nonostante la segnalazione di questi messaggi. L'installazione dei pacchetti generava alcuni problemi anche nelle versioni precedenti di Solaris Express e Solaris 10 Beta. Tuttavia, questi problemi non venivano segnalati. A partire da questa versione di Solaris, questi errori vengono segnalati e registrati correttamente.

Il programma di amministrazione del registro dei prodotti di Solaris non si avvia all'interno di una zona (6220284)

Se si cerca di avviare il programma di amministrazione del registro dei prodotti di Solaris in una zona, l'operazione non riesce. Durante l'installazione della zona, il database del registro dei prodotti di Solaris, productregistry, non viene duplicato all'interno della zona. Il programma non può perciò essere eseguito nella zona.

Soluzione: come superutente, copiare il database productregistry nella zona.


# cp /var/sadm/install/productregistry percorso_zona/var/sadm/install/

Nel comando precedente, percorso_zona è il percorso della directory radice della zona creata.

patchadd non riapplica le patch ai pacchetti installati successivamente (6219176)

Il comando patchadd non riapplica le patch nelle seguenti circostanze.

  1. Si applica una patch a un sistema che non contiene tutti i pacchetti corretti da quella patch.

  2. Successivamente, si installano i pacchetti che non erano presenti al momento dell'applicazione della patch.

  3. Si riapplica la patch per correggere i pacchetti installati successivamente.

La parte della patch che corregge i pacchetti aggiunti successivamente non viene installata. Compare un messaggio simile al seguente.


patchadd ~tsk/patches/111111-01
Verifica delle patch...

Caricamento delle patch installate sul sistema...

Eseguito

Caricamento delle patch di cui è richiesta l'installazione.

Eseguito

Le seguenti patch richieste sono già installate sul sistema
La patch 111111-01 di cui è richiesta l'installazione è già installata sul sistema.

Nessuna patch di cui controllare la dipendenza.

Soluzione: scegliere una delle soluzioni seguenti.

Soluzione 1: se sul sistema non è stata creata nessuna zona, usare il comando patchadd con l'opzione -t per correggere il sistema.


# patchadd -t ID-patch

Nel comando precedente, ID-patch è l'ID della patch che si desidera applicare.

Soluzione 2: se sul sistema sono state create una o più zone, procedere come segue.

  1. Disinstallare la patch.


    # patchrm ID-patch

  2. Installare i pacchetti aggiuntivi non presenti sul sistema che vengono corretti dalla patch.


    # pkgadd -d dispositivo abbrev_pacchetto

    Nell'esempio precedente, dispositivo specifica il percorso assoluto del pacchetto o dei pacchetti da installare. abbrev_pacchetto specifica il nome abbreviato del pacchetto da installare. È possibile specificare i nomi di più pacchetti.

  3. Reinstallare la patch.


    # patchadd  ID-patch

Le zone non globali create dopo l'applicazione di una patch alle zone globali non sono accessibili dai servizi di login remoto (6216195)

Se si crea una zona globale e vi si applica una patch, i servizi di login remoto non saranno abilitati nelle zone non globali create successivamente. Alcuni esempi di tali servizi remoti sono rlogin e telnet. Se si crea una zona non globale dopo avere applicato una patch a una zona globale, non è possibile eseguire un login remoto nella zona non globale. Questo problema riguarda i sistemi a cui vengono applicate patch che forniscono o modificano il pacchetto SUNWcsr.

Soluzione: scegliere una delle soluzioni seguenti.

Soluzione 1: se sul sistema non è ancora stata avviata la zona non globale, procedere come segue.

  1. Nella zona globale, spostarsi nella directory /var/svc/profile della zona non globale.


    globale# cd percorso_zona/root/var/svc/profile

    Nell'esempio precedente, percorso_zona è il percorso della zona non globale. Per determinare il percorso della zona non globale, digitare il comando seguente in una zona globale.


    globale# zonecfg -z nome_zona info zonepath

  2. Rimuovere il profilo inetd_services.xml.


    globale# rm inetd_services.xml

  3. Creare un collegamento simbolico per inetd_services.xml che punti al profilo inetd_generic.xml.


    globale# ln -s inetd_generic.xml inetd_services.xml

  4. Avviare la zona non globale.

    Per maggiori informazioni sull'avvio di una zona, vedere il manuale System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Soluzione 2: se sul sistema è già stata avviata la zona non globale, procedere come segue.

  1. Eseguire la procedura descritta nella soluzione precedente.

  2. Nella zona non globale, abilitare i servizi elencati nel profilo /var/svc/profile/inetd_services.xml.


    esempio-zona# svccfg apply /var/svc/profile/inetd_services.xml

  3. Riavviare la zona non globale.


    esempio-zona# reboot

Soluzione 3: prima di creare le zone sul sistema, applicare la patch appropriata per la propria piattaforma.

Non è possibile eliminare i client diskless esistenti dal sistema (6205746)

Se si utilizza il comando smdiskless per eliminare un client diskless, il comando non riesce. Il client diskless non viene rimosso dai database del sistema. Viene visualizzato il seguente messaggio di errore:


Failing with error EXM_BMS.

Soluzione: disabilitare la condivisione della partizione /export prima di aggiungere il client.

L'installazione di Net Connect 3.1.1 non riesce (6197548)

L'installazione di Net Connect 3.1.1 non riesce se si seleziona il prodotto all'inizio di un'installazione completa di Solaris 10. Il problema si verifica se l'installazione viene eseguita dal DVD del sistema operativo Solaris 10. Al termine dell'installazione del sistema operativo, il seguente messaggio di errore viene registrato nel log di installazione di Net Connect, in /var/sadm/install/logs/:


Installazione di SUNWSRSPX non riuscita.
Errore: pkgadd non riuscito per SUNWsrspx 
Installazione completata. Package: SUNWsrspx

Soluzione: al termine dell'installazione del sistema operativo, procedere come segue:

  1. Inserire il DVD del sistema operativo Solaris 10 o il CD Solaris 10 Software - 4.

  2. Spostarsi nella directory del prodotto Net Connect.

  3. Eseguire il programma di installazione di Net Connect.

Nota –

Per scaricare la versione più recente di Sun Net Connect e le note sulla versione, accedere al portale di Sun Net Connect all'indirizzo https://srsnetconnect.sun.com.

x86: La libreria C predefinita può causare un errore di avvio se si installa un archivio Solaris Flash (6192995)

Si può verificare un errore di avvio connesso all'archivio Solaris Flash nelle seguenti circostanze:

Quando si cerca di avviare il sistema clone, viene visualizzato il seguente messaggio di errore:


WARNING: init exited with fatal signal 9; restarting.

Soluzione: procedere come segue.

  1. Prima di creare l'archivio, disattivare la libreria /lib/libc.so.1 sul sistema master.


    # umount /lib/libc.so.1

    Questo comando permette al sistema master di usare la versione base della libreria C libc.

  2. Creare l'archivio Solaris Flash sul sistema master.

    Per maggiori informazioni sulla creazione degli archivi Solaris Flash, vedere la Guida all’installazione di Solaris 10: archivi Solaris Flash (creazione e installazione).

  3. Attivare la libreria /lib/libc.so.1 sul sistema master.


    # mount -O -F lofs /lib/libc.so.1 /usr/lib/libc/libc_hwcap2.so.1

  4. Installare l'archivio Solaris Flash sul sistema clone.

    Per maggiori informazioni sull'installazione degli archivi Solaris Flash, vedere la Guida all’installazione di Solaris 10: archivi Solaris Flash (creazione e installazione).

SPARC: Il comando smosservice delete non rimuove correttamente tutte le directory (6192105)

Se si utilizza il comando smosservice delete per rimuovere un servizio di un client diskless, il comando non rimuove correttamente tutte le directory del servizio.

Soluzione: procedere come segue.

  1. Verificare che non siano presenti client che utilizzano il servizio.


    # unshare /export/exec/Solaris_10_sparc.all
# rm -rf /export/exec/Solaris_10_sparc.all
# rm -rf /export/exec/.copyofSolaris_10_sparc.all
# rm -rf /export/.copyofSolaris_10
# rm -rf /export/Solaris_10
# rm -rf /export/share
# rm -rf /export/root/templates/Solaris_10
# rm -rf /export/root/clone/Solaris_10
# rm -rf /tftpboot/inetboot.sun4u.Solaris_10

  2. Rimuovere la voce seguente dal file /etc/bootparams.


    fs1-24 boottype=:os
    Nota –

    Rimuovere questa voce solo se il file server non fornisce funzioni o risorse per altri servizi.

  3. Rimuovere la voce seguente dal file /etc/dfs/dfstab.


    share -F nfs -o ro /export/exec/Solaris_8_sparc.all/usr

  4. Modificare il file /var/sadm/system/admin/services/Solaris_10.

    • Se il file server non è Solaris_10, eliminare il file.

    • Se il file server è Solaris_10, rimuovere tutte le voci che compaiono dopo le prime tre righe. Le righe eliminate indicano i pacchetti del servizio USR_PATH e SPOOLED ROOT in /export/root/templates/Solaris_10 e nelle piattaforme supportate.

Il comando patchadd non supporta l'installazione delle patch da un server NFS (6188748)

Se si esegue patchadd per installare una patch via NFS da un altro sistema, il comando non riesce. L'esempio seguente mostra un'operazione patchadd non riuscita e il messaggio di errore risultante:


Verifica delle patch...

Caricamento delle patch installate sul sistema...
[...]
Caricamento delle patch di cui è richiesta l'installazione.
[...]
Controllo delle patch specificate per l'installazione.
[...]
Le patch approvate saranno installate in questo ordine:
[...]
Controllo delle zone locali...
[...]
Riepilogo per le zone:
[...]
Patch che hanno superato il controllo delle dipendenze:
[...]

Applicazione delle patch alla zona globale
Aggiunta delle patch...

 Controllo delle patch installate...
Verifica della capacità del file system (metodo rapido)...
Installazione dei package di patch...

 La patch IDpatch è stata installata correttamente.
Vedere /var/sadm/patch/IDpatch/log per maggiori informazioni
 Package di patch installati:
   SUNWroute
[...]

Aggiunta delle patch...
 La directory delle patch
 /dev/.SUNW_patches_0111105334-1230284-00004de14dcb29c7
 non è presente sul sistema.  

[...]

Patchadd sta terminando.

Soluzione: copiare manualmente tutte le patch da installare dal server NFS al sistema locale. Usare quindi il comando patchadd per installare le patch dalla directory del sistema locale in cui erano state copiate.

Il comando lucreate non crea i volumi RAID-1 (5106987)

Se si utilizza il comando lucreate per creare volumi RAID-1 (mirror) non associati a uno dei dispositivi della directory /dev/md, il comando non riesce. Per eseguire il mirroring dei file system con il comando lucreate, è prima necessario creare i mirror con Solaris Volume Manager.

Soluzione: creare i file system in mirroring con Solaris Volume Manager, quindi creare il nuovo ambiente di boot con il comando lucreate.

Per maggiori informazioni sul comando lucreate, vedere la pagina man lucreate(1M) o la Guida all’installazione di Solaris 10: Solaris Live Upgrade e pianificazione degli aggiornamenti.

Per maggiori informazioni sulla creazione di file system in mirroring con Solaris Volume Manager, vedere il manuale Solaris Volume Manager Administration Guide.

SPARC: Gli errori irreversibili che si verificando durante un ciclo di sospensione e ripresa del sistema possono produrre un blocco del sistema (5062026)

Un errore irreversibile che si verifica durante un ciclo di sospensione e ripresa (cpr) può causare il blocco del sistema. In genere questo problema si verifica sulle workstation Sun Blade 2000 su cui è installato l'acceleratore grafico XVR-1000. Più raramente, il problema si può verificare su altri sistemi SPARC a causa di errori irreversibili. Quando l'errore si verifica, il core dump non viene salvato e sulla console non compare più il prompt. Il problema si verifica più frequentemente se il debugger del kernel (kadb) è attivo.

Soluzione: per rendere nuovamente utilizzabile il sistema, eseguire un riavvio manuale.

SPARC: L'arresto del sistema usando una combinazione di tasti può produrre un errore irreversibile (5061679)

Se si cerca di arrestare il sistema premendo una sequenza di tasti (ad esempio Stop-A o L1-A) il sistema può produrre un errore irreversibile. Viene visualizzato un messaggio di errore simile al seguente:


panic[cpu2]/thread=2a100337d40: pcisch2 (pci@9,700000): 
consistent dma sync timeout

Soluzione: non utilizzare una combinazione di tasti per portare il sistema al livello della PROM di OpenBoot.

Non è possibile usare il comando ipfs con l'opzione -W (5040248)

Il comando ipfs salva e ripristina informazioni sullo stato della NAT (Network Address Translation) e tabelle sullo stato di filtro dei pacchetti. Questo programma impedisce l'interruzione delle connessioni di rete in caso di riavvio del sistema. Se si esegue il comando con l'opzione -W, ipfs non salva le tabelle di stato del kernel. Viene visualizzato il seguente messaggio di errore:


state:SIOCSTGET: Bad address

Soluzione: nessuna.

Le autorizzazioni dei punti di attivazione non vengono preservate nell'ambiente di boot (4992478)

Quando si crea un nuovo ambiente di boot con lucreate, le autorizzazioni dei punti di attivazione dei file system non vengono preservate. Questo impedisce lo svolgimento di alcuni processi dell'utente. Se il nuovo ambiente di boot viene creato in un ambiente di clustering, il cluster disattiva i nodi e quindi si avvia dal CD-ROM per riparare le autorizzazioni dei punti di attivazione.

Soluzione: procedere come segue.

  1. Creare il nuovo ambiente di boot.


    # lucreate -n nuovo_be -m /:c0t0d0s0:ufs 
-m /var:c1t0d0s0:ufs -m  /usr:c2t0d0s0:ufs

    Nell'esempio precedente, il comando lucreate crea l'ambiente di boot nuovo_be. Questo esempio definisce i file system e i punti di attivazione seguenti.

    • Il file system root (/) viene attivato su c0t0d0s0.

    • Il file system var viene attivato su c1t0d0s0.

    • Il file system usr viene attivato su c2t0d0s0.

  2. Attivare il file system radice del nuovo ambiente di boot.


    # mount /dev/dsk/c0t0d0s0 /mnt

  3. Per ogni punto di attivazione definito per l'ambiente di boot, cambiare le autorizzazioni in 755.


    # chmod 755 /mnt/var
# chmod 755 /mnt/usr

  4. Disattivare il file system radice.

    # umount /dev/dsk/c0t0d0s0

Il comando kill -HUP non produce sempre la rilettura del file di configurazione snmpd.conf da parte dell'agente (4988483)

Dopo aver modificato il contenuto di snmpd.conf, è possibile eseguire il comando kill -HUP ID processo snmp. Questo comando arresta il processo snmp. Il comando invia quindi un segnale all'agente master del System Management Agent (snmpd) perché rilegga snmpd.conf e implementi le modifiche apportate. Non sempre il comando produce la rilettura del file di configurazione da parte dell'agente master. Di conseguenza, non sempre l'uso del comando rende effettive le modifiche del file di configurazione.

Anziché utilizzare kill -HUP, riavviare il System Management Agent dopo una modifica al file snmpd.conf. Procedere come segue:

  1. Diventare superutente.

  2. Digitare il comando seguente:

    # /etc/init.d/init.sma restart

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

Si supponga di dover avviare un sistema Sun LX50 che dispone di una partizione di servizio e su cui è installato Solaris 10 per x86. Premendo il tasto funzione F4, quando richiesto, per avviare la partizione di servizio, lo schermo diventa vuoto. Il sistema non avvia la partizione di servizio.

Soluzione: non premere il tasto F4 mentre è visualizzata la schermata di avvio 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 Invio. Il sistema avvia la partizione di servizio.

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. Anche se si crea un'istanza Solaris_ProviderPath per un provider scritto per queste interfacce, il daemon di Solaris WBEM Services 2.5 non riesce a trovarlo.

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: