Problemi di installazione che si verificano durante l'aggiornamento

La funzione Live Upgrade non riesce a determinare il dispositivo di boot (4525464)

Se si avvia il sistema da una partizione radice in mirroring di Solstice DiskSuite^TM o di Solaris^TM Volume Manager, oppure da una partizione radice incapsulata di Veritas, il comando lucreate non riesce a determinare il dispositivo di boot. Viene visualizzato il messaggio seguente.

ATTENZIONE: Impossibile determinare il dispositivo root 
mediante accesso diretto alle impostazioni del dispositivo di boot. 
ERRORE: Impossibile determinare il dispositivo root 
per l'ambiente di boot corrente. 
ERRORE: Impossibile determinare il dispositivo di boot 
fisico per l'ambiente di boot 
corrente <...>. Utilizzare l'opzione dalla riga di comando <-C> per specificare il 
dispositivo di boot fisico per l'ambiente di boot corrente <...>

Se si utilizza lucreate -C per specificare il dispositivo di boot fisico, il comando non riesce.

Soluzione: Modificare manualmente il file /usr/sbin/lucreate per consentire a Live Upgrade di determinare il dispositivo di boot da una partizione radice in mirroring di Solstice DiskSuite o di Solaris Volume Manager o da una partizione radice incapsulata di Veritas. Procedere come segue:

1. Creare una copia di backup di /usr/sbin/lucreate.

2. Aprire /usr/sbin/lucreate in un editor di testo.

3. Ricercare la riga seguente in /usr/sbin/lucreate .

   elif [ "${dpbe_pbeBootDev}" -eq "-" ] ; quindi

4. Cambiare la riga precedente come segue.

   elif [ "${dpbe_pbeBootDev}" = '-' ] ; then

5. Ricercare la riga seguente in /usr/sbin/lucreate .

   if [ "${OPTARG}" -ne "-" ] ; then

6. Cambiare la riga precedente come segue.

   if [ "${OPTARG}" != '-' ] ; then

7. Salvare le modifiche a /usr/sbin/lucreate.

Il comando lucreate è ora in grado di determinare il dispositivo di boot e l'opzione -C funziona correttamente.

Al termine dell'aggiornamento, rimuovere la copia di backup di /usr/sbin/lucreate.

L'aggiornamento non riesce se la capacità di /export è quasi esaurita (4409601)

Se la capacità della directory /export è quasi esaurita e si esegue un aggiornamento all'ambiente operativo Solaris 8 2/02, i requisiti di spazio per /export vengono calcolati erroneamente e l'aggiornamento non riesce. In genere, il problema si verifica se è installato un client diskless o se è installato un software di terze parti in /export. Viene visualizzato il messaggio seguente:

WARNING: Insufficient space for the upgrade.

Soluzione: Prima di eseguire l'aggiornamento, scegliere una delle soluzioni seguenti.

• Rinominare temporaneamente la directory /export fino al termine dell'aggiornamento.

• Commentare temporaneamente la riga /export nel file /etc/vfstab fino al termine dell'aggiornamento.

• Se /export è un file system separato, disattivarlo prima di eseguire l'aggiornamento.

Dopo l'aggiornamento, non è possibile rimuovere .save.SUNWcsr (4400054)

Dopo aver eseguito un aggiornamento da Solaris 2.5.1 8/97 o 11/97 a Solaris 8, in /a/var/sadm/system/logs/upgrade_log può comparire l'errore seguente:

rm: impossibile cancellare la directory /a/var/sadm/pkg/.save.SUNWcsr: 
File esistente

Soluzione: Per prevenire questo errore, prima di procedere all'aggiornamento a Solaris 8 eseguire il comando fsck sul file system radice.

Per risolvere l'errore dopo l'aggiornamento, eseguire fsck sul file system radice.

Aggiornamento di server e client diskless (4363078)

Se il sistema supporta client diskless installati con il tool AdminSuite 2.3 Diskless Client, è necessario eliminare tutti i client diskless esistenti prima di procedere all'installazione di Solaris 8 2/02. Per istruzioni specifiche, vedere la sezione "How to Set Up Your Diskless Client Environment" del manuale Solaris 8 System Administration Supplement.

Se si cerca di installare Solaris 8 2/02 su client diskless esistenti, viene visualizzato il seguente messaggio di errore:

La versione di Solaris (Solaris 7) sulla slice <xxxxxxxx> 
non può essere aggiornata. 
È stato riscontrato un problema non identificato nella 
configurazione software installata sul disco. 

Aggiornamento del data store JavaSpaces per prevenire perdite di dati WBEM

Se si esegue un aggiornamento da Solaris 8 (Solaris WBEM Services 2.0), Solaris 8 6/00 (WBEM Services 2.1), Solaris 8 10/00 (WBEM Services 2.2) o Solaris 8 1/01 (WBEM Services 2.3) a Solaris 8 2/02 (Solaris WBEM Services 2.4), è necessario convertire i dati proprietari in formato MOF (Managed Object Format) nel formato del nuovo repository Reliable Log usato da Solaris WBEM Services 2.4. La mancata conversione può causare una perdita di dati.

Soluzione: Per convertire i dati WBEM, prima di eseguire l'aggiornamento è necessario salvare il software JavaSpaces^TM. Dopo l'aggiornamento, è necessario eseguire il comando wbemconfig convert.

Prima di eseguire l'aggiornamento a Solaris 8 2/02, procedere come segue per salvare il software JavaSpaces.

1. Diventare superutente.

2. Salvare il software JavaSpaces.

   cp /usr/sadm/lib/wbem/outrigger.jar /usr/sadm/lib/wbem/outrigger.jar.tmp

3. Controllare e annotare la versione del software JDK^TM installata sul sistema. Ad esempio:

   # /usr/bin/java -version java version "1.2.1" Solaris VM (build Solaris_JDK_1.2.1_04c, native threads, sunwjit)

   È necessario eseguire la stessa versione del JDK usata per la creazione del datastore JavaSpaces.

Una volta completato l'aggiornamento a Solaris 82/02, è necessario convertire i dati WBEM. Per informazioni specifiche, vedere la sezione "Upgrading the CIM Object Manager Repository" in Solaris WBEM Services Administrator's Guide.

Il CDE della versione Solaris 2.5.1 viene reso inattivo se era stato installato in una posizione diversa da quella predefinita e si esegue un aggiornamento a Solaris 8 (4260819)

Questo problema si verifica sui sistemi che eseguono l'ambiente operativo Solaris 2.5.1 e il CDE installato separatamente di Solaris 2.5.1. I sistemi presentano il problema solo se il CDE installato separatamente è stato collocato in una directory diversa da /usr/dt. Su questi sistemi, viene creato un collegamento simbolico in /usr/dt che punta all'effettiva directory in cui si trova il CDE.

Quando si esegue l'aggiornamento a Solaris 8, il CDE viene reinstallato in /usr/dt e il collegamento viene rimosso. Il CDE originario non viene rimosso, ma viene reso "orfano" in quanto viene eliminato il suo collegamento.

Se durante l'aggiornamento si esegue una riallocazione dei file system, l'aggiornamento può non riuscire in quanto la procedura di riallocazione non tiene conto dello spazio aggiuntivo necessario in /usr/dt per la nuova versione del CDE. Un errore di questo tipo è riscontrabile solo al termine dell'aggiornamento. Se questo errore si verifica, il log di aggiornamento include gli appropriati messaggi di errore che indicano la mancanza di spazio.

Soluzione: Rimuovere il CDE originario prima di aggiornare il sistema a Solaris 8. Questa operazione può essere eseguita con lo script install-cde presente sul CD del CDE di Solaris 2.5.1. Lo script deve essere eseguito con l'opzione -uninstall per rimuovere il CDE.

Se si esegue un aggiornamento da un sistema con Solaris 7 e Web-Based Enterprise Management (WBEM) 1.0 a Solaris 8, WBEM 2.0 non funziona correttamente (4274920)

Se sul sistema Solaris 7 è stato installato WBEM 1.0 dal CD di Solaris Easy Access Server (SEAS) 3.0, prima di eseguire l'aggiornamento a Solaris 8 è necessario rimuovere i package di WBEM 1.0. Diversamente, aggiornando il sistema a Solaris 8, Solaris WBEM Services 2.0 non si avvierà. Il gestore di oggetti Common Information Model (CIM) non riesce ad avviarsi e compare il seguente messaggio di errore. Viene visualizzato il messaggio seguente.

File not found: /opt/sadm/lib/wbem/cimom.jar

Soluzione: Prima di eseguire l'aggiornamento a Solaris 8, usare il comando pkgrm per rimuovere i package di WBEM 1.0.

1. Per determinare se i package di WBEM 1.0 sono installati, usare il comando pkginfo come segue:

   % pkginfo | grep WBEM

2. Diventare superutente.

3. Usare il comando pkgrm per rimuovere tutti i package di WBEM 1.0:

   # pkgrm SUNWwbapi # pkgrm SUNWwbcor # pkgrm SUNWwbdev # pkgrm SUNWwbdoc # pkgrm SUNWwbm

SUNWeeudt non viene installato completamente durante l'aggiornamento (4304305)

Il log dell'aggiornamento può indicare che il package SUNWeeudt è stato installato solo parzialmente..

     pkgadd di SUNWeeudt su / in corso. 
     ERRORE:  la verifica degli attributi di 
     </a/usr/dt/appconfig/types/ru_RU.KOI8-R/datatypes.dt> 
     non è riuscita Percorso inesistente ...

     Installazione di <SUNWeeudt> parzialmente fallita. 
     codice restituito da pkgadd = 2  

Soluzione: Al termine dell'aggiornamento, procedere come segue.

1. Per rimuovere il package SUNWeeudt, digitare il comando seguente.

   # pkgrm SUNWeeudt

2. Per aggiungere il package SUNWeeudt, digitare.

   # pkgadd SUNWeeudt

Durante l'aggiornamento da Solaris 2.6 o Solaris 7, vengono installati alcuni package a 64 bit non necessari (4323398)

Quando si esegue un aggiornamento a Solaris 8 2/02 dall'ambiente operativo Solaris 2.6 o Solaris 7 senza selezionare il supporto a 64 bit, vengono ugualmente installati i seguenti package a 64 bit:

• SUNWceuox

• SUNWeeoux

• SUNWneoux

• SUNWseoux

• SUNWweoux

Soluzione: Al termine dell'aggiornamento, rimuovere questi package a 64 bit con il comando pkgrm:

# pkgrm SUNWceuox SUNWeeuox SUNWneuox SUNWseuox SUNWweuox