Questo capitolo descrive i requisiti da verificare e i fattori da considerare prima di installare e utilizzare la funzione Solaris Live Upgrade. Vedere anche le informazioni generali sull'aggiornamento dei sistemi nella sezione Lista di controllo per l'aggiornamento. Il capitolo è suddiviso nelle seguenti sezioni:
Gestione dei pacchetti e delle patch con Solaris Live Upgrade
Indicazioni per la creazione dei file system con il comando lucreate
Solaris Live Upgrade è incluso in Solaris 9. Per eseguire l'aggiornamento con Solaris Live Upgrade, occorre installare i pacchetti di Solaris Live Upgrade nell'ambiente operativo in uso. Si può eseguire l'aggiornamento di un ambiente di boot alla versione dell'ambiente operativo Solaris equivalente a quella dei pacchetti di Solaris Live Upgrade installati sul sistema in uso. Ad esempio, se sull'ambiente operativo Solaris 8 in uso sono stati installati i pacchetti di Solaris 9 Live Upgrade, è possibile eseguire l'aggiornamento dell'ambiente di boot a Solaris 9, versione base o di aggiornamento.
La Tabella 34–1 elenca le versioni supportate da Solaris Live Upgrade.
Tabella 34–1 Release di Solaris supportate
Piattaforma |
Release dalla quale si esegue l'aggiornamento |
Release di destinazione dell'aggiornamento |
---|---|---|
Sistema SPARC |
Solaris 2.6, Solaris 7 o Solaris 8 |
Solaris 8 |
Sistema SPARC |
Solaris 2.6, Solaris 7 o Solaris 8 |
Solaris 9 |
Sistema x86 |
Solaris 7 |
Solaris 8 |
Sistema x86 |
Solaris 7 o Solaris 8 |
Solaris 9 |
Non è possibile aggiornare i sistemi all'ambiente operativo Solaris 7.
I pacchetti di Solaris Live Upgrade possono essere installati:
Con il comando pkgadd. I pacchetti di Solaris Live Upgrade sono denominati SUNWlur e SUNWluu e vanno installati in quest'ordine.
Con il programma di installazione contenuto nel DVD di Solaris, nel CD Solaris Software 2 of 2 o in un'immagine di installazione in rete.
Se si esegue Solaris 2.6, Solaris 7 o Solaris 8, non sarà possibile eseguire il programma di installazione di Solaris Live Upgrade. Queste versioni infatti non contengono l'insieme di patch richiesto per eseguire il JavaTM 2 runtime environment. Per eseguire il programma di installazione di Solaris Live Upgrade e installarne i pacchetti è necessario che sul sistema sia presente il cluster di patch raccomandato per il Java 2 runtime environment. Per installare i pacchetti di Solaris Live Upgrade, usare il comando pkgadd. In alternativa, installare il cluster di patch raccomandato per il Java 2 runtime environment disponibile sul sito http://sunsolve.sun.com.
Per istruzioni sull'installazione di Solaris Live Upgrade, vedere Installazione di Solaris Live Upgrade.
Seguire le direttive generali per i requisiti di spazio negli aggiornamenti. Vedere Capitolo 5.
Per calcolare lo spazio richiesto nel file system per creare un ambiente di boot, iniziare il processo di creazione di un nuovo ambiente di boot. La dimensione viene calcolata. A quel punto è possibile interrompere il processo.
Il disco del nuovo ambiente di boot deve poter operare come dispositivo di boot. Per alcuni sistemi sono previste limitazioni riguardo ai dischi utilizzabili come dispositivi di boot. Se necessario, vedere la documentazione del proprio sistema.
Prima di creare il nuovo ambiente di boot, può essere necessaria una preparazione del disco. Controllare che il disco sia formattato correttamente:
Identificare le slice sufficientemente grandi da contenere i file system da copiare.
Identificare i sistemi che contengono le directory da condividere, anziché da copiare, tra gli ambienti di boot. Per condividere una directory, è necessario creare un nuovo ambiente di boot con la directory situata su una propria slice. La directory diventa così un file system ed è quindi condivisibile con altri ambienti di boot. Per maggiori informazioni sulla creazione di file system separati da condividere, vedere Indicazioni per la scelta delle slice per i file system condivisibili.
Utilizzando la tecnologia di Solaris Volume Manager, Solaris Live Upgrade permette di creare ambienti di boot in grado di contenere come file system volumi RAID-1 (mirror). Per usare le funzioni di mirroring di Solaris Live Upgrade, è necessario creare almeno un database di stato e almeno tre repliche di questo database. Il database di stato memorizza informazioni riguardo allo stato della configurazione di Solaris Volume Manager. Il database di stato è una raccolta di più copie replicate del database. Ogni copia viene denominata replica del database di stato. La copia del database di stato permette di proteggerlo contro la perdita di dati causata dalla presenza di punti di guasto non ridondanti. Per le procedure di creazione del database di stato, vedere la sezione “ State Database (Overview)” del manuale Solaris Volume Manager Administration Guide.
Solaris Live Upgrade non implementa tutte le funzionalità di Solaris Volume Manager. Solaris Live Upgrade supporta solo i volumi RAID-1 (mirror) con concatenazioni su singola slice nel file system radice (/). Ogni mirror può contenere fino a un massimo di tre concatenazioni. Per istruzioni sulla creazione di file system in mirroring, vedere Indicazioni per la scelta delle slice per i file system in mirroring.
Le sezioni seguenti descrivono i pacchetti richiesti da Solaris Live Upgrade e forniscono informazioni sulle patch consigliate. Per informazioni sull'uso di Solaris Live Upgrade per l'aggiunta di pacchetti e patch, vedere Aggiornamento di un sistema con pacchetti e patch.
Se durante un aggiornamento occorre aggiungere o rimuovere pacchetti o patch, Solaris Live Upgrade richiede che i pacchetti o le patch siano conformi alle direttive di packaging avanzate di SVR4. Benché i pacchetti Sun siano conformi a queste direttive, Sun non può garantire la conformità dei pacchetti di altri produttori. I pacchetti non conformi possono causare l'interruzione del software di aggiunta dei pacchetti durante il processo di aggiornamento o l'alterazione dell'ambiente di boot.
Per maggiori informazioni sull'aggiunta e la rimozione dei pacchetti con Solaris Live Upgrade, vedere la pagina man luupgrade( 1M). Per maggiori informazioni sui requisiti dei pacchetti, vedere l'Appendice G.
Verificare che l'ambiente operativo contenga i pacchetti elencati nella tabella seguente, che sono necessari per l'uso di Solaris Live Upgrade. Se uno o più pacchetti elencati per la propria versione non sono presenti, usare il comando pkgadd per aggiungerli.
Tabella 34–2 Pacchetti richiesti per Solaris Live Upgrade
Solaris 2.6 |
Solaris 7 |
Solaris 8 |
---|---|---|
SUNWadmap |
SUNWadmap |
SUNWadmap |
SUNWadmc |
SUNWadmc |
SUNWadmc |
SUNWjvrt |
SUNWjvrt |
SUNWj2rt |
SUNWlibC |
SUNWlibC |
SUNWlibC |
SUNWadmfw |
SUNWbzip |
|
SUNWmfrun |
| |
SUNWloc |
Per controllare la presenza dei pacchetti sul sistema, digitare il comando seguente.
% pkginfo [[nome_pacchetto]] |
Solaris Live Upgrade permette di aggiungere patch e pacchetti ai sistemi. Utilizzando Solaris Live Upgrade per aggiungere una o più patch a un sistema, il tempo di inattività del sistema si limita alla durata del reboot. Per aggiungere patch e pacchetti a un ambiente di boot, è possibile usare il comando luupgrade o un archivio Solaris Flash.
Per aggiungere una patch direttamente a un ambiente di boot, creare un nuovo ambiente di boot e usare il comando luupgrade con l'opzione -t. Per aggiungere un pacchetto a un ambiente di boot, usare il comando luupgrade con l'opzione -p. Per maggiori informazioni, vedere la pagina man luupgrade( 1M).
Oppure, è possibile installare un archivio Solaris Flash usando Solaris Live Upgrade. L'archivio contiene una copia completa dell'ambiente di boot con i nuovi pacchetti e le patch già incluse. Questo ambiente di boot completo, o il singolo sistema di riferimento, vengono detti sistemi master. Il processo di creazione di un archivio Solaris Flash inizia con la creazione di un sistema master. Dopo aver creato un sistema master, aggiungervi le patch e i pacchetti che si desidera installare. Quindi, creare un archivio Solaris Flash del sistema master. Usare Solaris Live Upgrade per installare l'archivio sul nuovo ambiente di boot. La copia, la modifica e la distribuzione dell'ambiente di boot possono essere ripetuti per il numero di volte necessario. Per informazioni su come creare un archivio Solaris Flash, vedere il Capitolo 21. Per istruzioni sulle procedure da seguire per installare un archivio Solaris Flash con Solaris Live Upgrade, vedere Installazione di archivi Solaris Flash in un ambiente di boot.
Se durante un aggiornamento occorre aggiungere o rimuovere pacchetti o patch, Solaris Live Upgrade richiede che i pacchetti o le patch siano conformi alle direttive di packaging avanzate SVR4. Benché i pacchetti Sun siano conformi a queste direttive, Sun non può garantire la conformità dei pacchetti di altri produttori. I pacchetti non conformi possono causare l'interruzione del software di aggiunta dei pacchetti o l'alterazione dell'ambiente di boot.
Per maggiori informazioni sull'aggiunta e la rimozione dei pacchetti con Solaris Live Upgrade, vedere la pagina man luupgrade( 1M). Per maggiori informazioni sui requisiti dei pacchetti, vedere l'Appendice G.
Il funzionamento corretto di Solaris Live Upgrade richiede l'installazione di un determinato insieme di patch per ogni versione dell'OS. Prima di installare o eseguire Live Upgrade, è necessario installare un determinato insieme di patch. Verificare di disporre dell'elenco più aggiornato delle patch accedendo al sito http://sunsolve.sun.com. Sul sito SunSolveSM, ricercare il documento informativo 72099.
L'opzione -m del comando lucreate specifica quali e quanti file system dovranno essere creati nel nuovo ambiente di boot. Ripetendo questa opzione è necessario specificare il numero esatto dei file system che si desidera creare. Ad esempio, usando una sola volta l'opzione -m si specifica una sola posizione in cui collocare tutti i file system; in questo modo, tutti i file system dell'ambiente di boot originale vengono uniti nell'unico file system specificato dall'opzione -m. Se l'opzione -m viene specificata due volte, vengono creati due file system. Quando si utilizza l'opzione -m per creare i file system, occorre ricordare quanto segue:
È necessario specificare una sola opzione -m per il file system radice (/) del nuovo ambiente di boot. Se si esegue lucreate senza l'opzione -m, viene visualizzato il menu di configurazione. Questo menu permette di personalizzare il nuovo ambiente di boot redirigendo i file su nuovi punti di attivazione.
I file system di importanza critica presenti nell'ambiente di boot corrente che non vengono specificati con un'opzione -m vengono uniti nel file system creato al livello superiore.
Nel nuovo ambiente di boot vengono creati solo i file system specificati con l'opzione -m. Se l'ambiente di boot corrente contiene più file system e si desidera avere lo stesso numero di file system in quello nuovo, è necessario specificare un'opzione -m per ogni file system da creare. Ad esempio, se si dispone dei file system radice (/), /opt e /var, occorrerà usare un'opzione -m per ogni file system del nuovo ambiente di boot.
I punti di attivazione non possono essere duplicati. Ad esempio, non è possibile creare due file system radice (/).
Per la creazione dei file system di un ambiente di boot, le regole da seguire sono uguali a quelle per la creazione dei file system per l'ambiente operativo Solaris. Solaris Live Upgrade non previene la creazione di configurazioni non valide per i file system di importanza critica. Ad esempio, sarebbe possibile inserire un comando lucreate che crei file system separati per / e /kernel, creando così una divisione non valida per il file system radice (/).
Durante il ripartizionamento dei dischi, evitare di sovrapporre le slice. In tal caso, infatti, il nuovo ambiente di boot verrà creato senza errori ma, una volta attivato, non permetterà di avviare il sistema. I file system sovrapposti possono risultare danneggiati.
Perché Solaris Live Upgrade operi correttamente, è necessario che il file vfstab dell'ambiente di boot attivo abbia un contenuto valido con almeno una voce per il file system radice (/).
Quando si crea un ambiente di boot inattivo, occorre identificare la slice in cui copiare il file system radice (/). Per selezionare tale slice, usare i criteri seguenti. La slice deve soddisfare i seguenti requisiti:
Deve essere una slice da cui sia possibile eseguire il boot.
Deve avere la dimensione minima consigliata.
Se si utilizza un sistema sun4m, il file system radice (/) non deve superare la dimensione di 2 Gbyte.
Può occupare dischi fisici differenti o lo stesso disco come file system radice (/) attivo.
Può essere un volume di Veritas Volume Manager, ma questi volumi non sono supportati.
È possibile creare un nuovo ambiente di boot che contenga qualunque combinazione di slice di dischi fisici, volumi Solaris Volume Manager o volumi Veritas Volume Manager. Nel nuovo ambiente di boot è possibile copiare i file system di importanza critica dei seguenti tipi:
Slice fisiche.
Concatenazioni di una singola slice che siano incluse in un volume RAID–1 (mirror). La slice che contiene il file system radice (/) può essere un volume RAID–1.
Concatenazioni di una singola slice che siano incluse in un volume RAID–0. La slice che contiene il file system radice (/) può essere un volume RAID–0.
Quando si crea un nuovo ambiente di boot, il comando lucreate - m riconosce i seguenti tre tipi di dispositivo:
Le slice fisiche nella forma /dev/dsk/cwtxdysz
I volumi di Solaris Volume Manager nella forma /dev/md/dsk/dnum
I volumi Veritas Volume Manager nella forma /dev/vx/dsk/nome_volume
In caso di problemi nell'aggiornamento con Veritas VxVM, vedere Errore fatale del sistema durante l'aggiornamento con Solaris Live Upgrade su volumi Veritas VxVm.
Usare le seguenti linee guida per controllare se un volume RAID-1 è occupato, è in corso di sincronizzazione o se contiene file system utilizzati in quel momento da un ambiente di boot di Solaris Live Upgrade.
Per indicazioni e linee guida sulla denominazione dei volumi, vedere Linee guida per JumpStart personalizzato e Solaris Live Upgrade.
Se un mirror o un submirror richiede un intervento di manutenzione o è occupato, non è possibile scollegarne i componenti. Prima di creare un nuovo ambiente di boot e utilizzare la parola chiave detach, occorre usare il comando metastat. Il comando metastat controlla se il mirror è in fase di risincronizzazione o se è correntemente in uso. Per informazioni, vedere la pagina man metastat(1M).
Se si utilizza la parola chiave detach per separare un submirror, lucreate controlla se il dispositivo è attualmente in fase di risincronizzazione. Se è in corso una risincronizzazione, il submirror non può essere scollegato e viene generato un messaggio di errore.
La risincronizzazione è il processo con cui i dati residenti in un submirror vengono copiati in un altro submirror quando si verifica uno dei seguenti problemi:
Si è verificato un guasto nel submirror.
Il sistema si interrompe.
Un submirror è stato disattivato e riattivato.
È stato aggiunto un nuovo submirror.
Per maggiori informazioni sulla risincronizzazione, vedere la sezione “RAID 1 Volume (Mirror) Resynchronization” del manuale Solaris Volume Manager Administration Guide.
Per operare sui volumi di un ambiente di boot inattivo, è preferibile usare il comando lucreate anziché i comandi di Solaris Volume Manager. Solaris Volume Manager non riconosce gli ambienti di boot, mentre il comando lucreate utilizza una serie di controlli che impediscono la possibile distruzione involontaria degli ambienti di boot. Ad esempio, lucreate impedisce di sovrascrivere o di eliminare i volumi di Solaris Volume Manager.
Se tuttavia si è già utilizzato il software Solaris Volume Manager per creare concatenazioni, stripe e mirror di natura complessa, per modificare queste configurazioni è necessario utilizzare ancora Solaris Volume Manager. Solaris Live Upgrade riconosce questi componenti e supporta il loro utilizzo. Prima di usare i comandi di Solaris Volume Manager per creare, modificare o distruggere i componenti dei volumi, usare i comandi lustatus o lufslist. Questi comandi permettono di determinare quali volumi di Solaris Volume Manager contengano file system utilizzati da un ambiente di boot Solaris Live Upgrade.
Per configurare una slice di swap con il comando lucreate e l'opzione -m, è possibile procedere in tre modi:
Se non viene specificata una slice di swap, per il nuovo ambiente di boot vengono configurate le slice di swap appartenenti all'ambiente di boot corrente.
Se vengono specificate una o più slice di swap, il nuovo ambiente di boot userà solo le slice di swap specificate. I due ambienti di boot non condividono nessuna slice di swap.
È possibile specificare sia la condivisione di una slice di swap che l'aggiunta di una nuova slice di swap.
Gli esempi seguenti illustrano i tre metodi per la configurazione dello spazio di swap. L'ambiente di boot corrente è configurato con il file system radice (/) su c0t0d0s0. Il file system di swap si trova su c0t0d0s1.
Nell'esempio seguente non è specificata nessuna slice di swap. Il nuovo ambiente di boot contiene il file system radice (/) su c0t1d0s0. L'ambiente di boot corrente e quello nuovo condividono lo spazio di swap su c0t0d0s1.
# lucreate -n be2 -m /:c0t1d0s0:ufs |
Nell'esempio seguente è specificata una slice di swap. Il nuovo ambiente di boot contiene il file system radice (/) su c0t1d0s0. Viene creata una nuova slice di swap su c0t1d0s1. L'ambiente di boot corrente e quello nuovo non condividono nessuna slice di swap.
# lucreate -n be2 -m /:c0t1d0s0:ufs -m -:c0t1d0s1:swap |
Nell'esempio seguente, viene aggiunta una slice di swap e una seconda slice di swap è condivisa tra i due ambienti di boot. Il nuovo ambiente di boot contiene il file system radice (/) su c0t1d0s0. Viene creata una nuova slice di swap su c0t1d0s1. L'ambiente di boot corrente e quello nuovo condividono la slice di swap su c0t0d0s1.
# lucreate -n be2 -m /:c0t1d0s0:ufs -m -:shared:swap -m -:c0t1d0s1:swap |
La creazione dell'ambiente di boot non riesce se la slice di swap è utilizzata da un ambiente di boot diverso da quello corrente. Se l'ambiente di boot era stato creato con l'opzione -s, la slice di swap può essere utilizzata solo dall'ambiente di boot alternativo ma non da altri.
Solaris Live Upgrade copia l'intero contenuto di una slice nella slice designata del nuovo ambiente di boot. In alcuni casi, tuttavia, può essere più comodo condividere i file system di grandi dimensioni tra gli ambienti di boot anziché copiarli fisicamente, in modo da occupare meno spazio e velocizzare le operazioni. I file system di importanza critica per l'ambiente operativo, ad esempio il file system radice (/) e /var, devono necessariamente essere copiati. I file system come /home non sono di importanza critica e possono essere condivisi tra gli ambienti di boot. I file system condivisibili devono essere definiti dall'utente e trovarsi su slice di swap separate nell'ambiente di boot attivo e in quello inattivo. Il disco può essere riconfigurato in vari modi a seconda delle esigenze.
È possibile ripartizionarlo prima di creare il nuovo ambiente di boot e collocare il file system condivisibile in una propria slice. Ad esempio, se i file system radice (/), /var e /home si trovano tutti nella stessa slice, è possibile riconfigurare il disco e collocare /home in una propria slice. Quando si crea un nuovo ambiente di boot, /home viene automaticamente condiviso con il nuovo ambiente di boot.
Se si desidera condividere una directory, è necessario collocarla in una slice separata. La directory diventa così un file system condivisibile con un altro ambiente di boot. Il comando lucreate con l'opzione -m permette di creare un nuovo ambiente di boot e di collocare una directory in una propria slice. Tuttavia, il nuovo file system non può ancora essere condiviso con l'ambiente di boot originale. A tale scopo, occorre eseguire il comando lucreate con l'opzione -m e creare un altro ambiente di boot. I due ambienti di boot nuovi potranno condividere la directory.
Ad esempio, se si desidera eseguire un aggiornamento da Solaris 8 a Solaris 9 e condividere il file system /home, è possibile eseguire il comando lucreate con l'opzione -m per creare una versione Solaris 8 con /home come file system separato in una propria slice. Occorre quindi eseguire nuovamente il comando lucreate con l'opzione -m per duplicare questo ambiente di boot. Questo terzo ambiente di boot potrà quindi essere aggiornato a Solaris 9. Il file system /home verrà condiviso tra le versioni Solaris 8 e Solaris 9.
Per una descrizione dei file system di importanza critica e dei file system condivisibili, vedere Tipi di file system.
Quando si crea un nuovo ambiente di boot, è possibile escludere dal processo di copia alcuni file e directory specifici. Se si esclude una directory, è tuttavia possibile includere file o sottodirectory specifiche contenuti al suo interno. Tali file o sottodirectory verranno quindi copiati nel nuovo ambiente di boot. Ad esempio, è possibile escludere dalla copia l'intero contenuto di /etc/mail ma includere i file e le directory in /etc/mail/staff. Il comando seguente copia la sottodirectory staff nel nuovo ambiente di boot.
# lucreate -n secondo_disco -x /etc/mail -y /etc/mail/staff |
Le opzioni di esclusione dei file devono essere usate con estrema attenzione. In particolare, occorre evitare di rimuovere file o directory che sono richiesti dal sistema.
La tabella seguente elenca le opzioni del comando lucreate disponibili per rimuovere o ripristinare file e directory.
Metodo di designazione |
Opzioni di esclusione |
Opzioni di inclusione |
---|---|---|
Specificare il nome della directory o del file |
-x dir/file_esclusi |
-y dir/file_inclusi |
Usare un file che contiene un elenco |
-f file_elenco -z file_elenco |
-Y file_elenco -z file_elenco |
Alcuni esempi di personalizzazione dei file e delle directory durante la creazione di un ambiente di boot sono riportati in Creare un ambiente di boot e personalizzarne il contenuto (riga di comando).
Quando si è pronti per usare il nuovo ambiente di boot, è possibile attivarlo velocemente e riavviare il sistema. La prima volta che si avvia un nuovo ambiente di boot, i file vengono sincronizzati con quelli dell'ambiente precedentemente in uso. “Sincronizzazione” significa in questo caso la copia di alcuni file e directory di importanza critica dall'ambiente di boot precedente a quello nuovo. Vengono copiati i file e le directory che sono stati modificati.
Solaris Live Upgrade controlla i file di importanza critica che sono stati modificati. Se il contenuto di questi file non corrisponde nei due ambienti di boot, quelli residenti nell'ambiente di boot attivo vengono copiati nel nuovo ambiente di boot. La sincronizzazione è particolarmente utile per applicare al nuovo ambiente di boot le modifiche apportate ad alcuni file di importanza critica, ad esempio /etc/passwd o /etc/group.
Il file /etc/lu/synclist contiene l'elenco delle directory e dei file da sincronizzare. In alcuni casi, è possibile copiare altri file dall'ambiente di boot attivo a quello nuovo. Se necessario, è possibile aggiungere i file e le directory desiderate a /etc/lu/synclist.
L'aggiunta di file non elencati in /etc/lu/synclist potrebbe rendere impossibile il boot del sistema. Il processo di sincronizzazione si limita alla copia dei file e alla creazione di directory. Non esegue la rimozione di file e directory.
L'esempio seguente del file /etc/lu/synclist mostra le directory e i file standard che vengono sincronizzati su questo sistema.
/var/mail OVERWRITE /var/spool/mqueue OVERWRITE /var/spool/cron/crontabs OVERWRITE /var/dhcp OVERWRITE /etc/passwd OVERWRITE /etc/shadow OVERWRITE /etc/opasswd OVERWRITE /etc/oshadow OVERWRITE /etc/group OVERWRITE /etc/pwhist OVERWRITE /etc/default/passwd OVERWRITE /etc/dfs OVERWRITE /var/log/syslog APPEND /var/adm/messages APPEND |
Qui di seguito sono riportati alcuni esempi di file e directory che potrebbero essere aggiunti al file synclist:
/var/yp OVERWRITE /etc/mail OVERWRITE /etc/resolv.conf OVERWRITE /etc/domainname OVERWRITE |
Il file synclist può contenere file o directory. Il secondo campo indica il metodo di aggiornamento che viene utilizzato all'attivazione dell'ambiente di boot. Sono disponibili tre metodi per l'aggiornamento dei file:
OVERWRITE — Il contenuto del file dell'ambiente di boot attivo viene sovrascritto con quello del file del nuovo ambiente di boot. Se nel secondo campo non viene specificata nessuna azione, viene usato automaticamente il metodo OVERWRITE. Nel caso delle directory, vengono copiate anche tutte le sottodirectory. Questo processo sovrascrive tutti i file. La data, la modalità e il proprietario del file del nuovo ambiente di boot sono uguali a quelli del file dell'ambiente di boot precedente.
APPEND — Il contenuto del file dell'ambiente di boot attivo viene aggiunto alla fine del file del nuovo ambiente di boot. Questo processo può causare la duplicazione di alcune voci nel file. L'azione APPEND non può essere applicata alle directory. La data, la modalità e il proprietario del file del nuovo ambiente di boot sono uguali a quelli del file dell'ambiente di boot precedente.
PREPEND — Il contenuto del file dell'ambiente di boot attivo viene aggiunto all'inizio del file del nuovo ambiente di boot. Questo processo può causare la duplicazione di alcune voci nel file. L'azione PREPEND non può essere applicata alle directory. La data, la modalità e il proprietario del file del nuovo ambiente di boot sono uguali a quelli del file dell'ambiente di boot precedente.
La prima volta che si avvia un sistema da un nuovo ambiente di boot, il software Solaris Live Upgrade sincronizza questo ambiente con quello precedentemente attivo. Dopo il boot e la sincronizzazione iniziale, Solaris Live Upgrade non esegue altre sincronizzazioni in modo automatico.
Per forzare una sincronizzazione usando l'interfaccia a caratteri, digitare yes alla richiesta del sistema
Per forzare una sincronizzazione dalla riga di comando, usare il comando luactivate con l'opzione -s
Se si stanno conservando più versioni dell'ambiente operativo Solaris, può essere necessario forzare la sincronizzazione. Possono essere necessarie versioni modificate di file quali email o passwd/group nell'ambiente di boot che si sta attivando. In questo modo, Solaris Live Upgrade controlla i conflitti tra i file sottoposti alla sincronizzazione. Quando si avvia il nuovo ambiente di boot e viene rilevato un conflitto, il software genera un messaggio di avvertimento e i file non vengono sincronizzati. Ciò nonostante, l'attivazione può essere completata correttamente. La modifica dello stesso file nell'ambiente di boot nuovo e in quello attivo può generare un conflitto. Ad esempio, si supponga di modificare il file /etc/passwd nell'ambiente di boot originale. Successivamente, vengono apportate altre modifiche al file /etc/passwd nel nuovo ambiente di boot In questo caso, il processo di sincronizzazione non è in grado di scegliere quale file copiare per sincronizzare i due ambienti.
Questa opzione deve essere utilizzata con estrema cautela, poiché spesso è difficile tener conto di tutte le modifiche apportate all'ultimo ambiente di boot attivo. Ad esempio, se l'ambiente di boot corrente viene eseguito in Solaris 9 e si ritorna a Solaris 7 con una sincronizzazione forzata, i file della versione 7 possono risultare modificati. Poiché i file dipendono dalla versione dell'ambiente operativo, il boot di Solaris 2.6 può non riuscire perché i file di Solaris 9 non sono sempre compatibili con quelli di Solaris 7.
Quando si visualizza l'interfaccia a caratteri in modo remoto, ad esempio attraverso una linea asincrona, può essere necessario impostare la variabile d'ambiente TERM su VT220. Inoltre, se si utilizza il Common Desktop Environment (CDE), occorre impostare la variabile TERM sul valore dtterm anziché xterm.