Prima di aggiornare il proprio sistema si raccomanda di effettuare un salvataggio completo o quantomeno una copia di sicurezza di tutti quei dati e quelle informazioni di configurazione che non ci si può permettere di perdere. Gli strumenti e i processi di aggiornamento sono abbastanza affidabili, ma un problema dell'hardware durante l'aggiornamento potrebbe generare un sistema fortemente danneggiato.

Le cose principali che si potrebbe considerare di salvare sono i contenuti di /etc, /var/lib/dpkg, /var/lib/apt/extended_states e l'output di dpkg --get-selections "*" (le virgolette sono importanti). Se si usa aptitude per gestire i pacchetti, si dovrebbe salvare anche /var/lib/aptitude/pkgstates.

Il processo di aggiornamento in quanto tale non modifica nulla nelle directory /home, tuttavia alcune applicazioni (come ad esempio alcune parti della suite Mozilla e gli ambienti desktop GNOME e KDE) sovrascrivono le impostazioni dell'utente preesistenti con i nuovi valori predefiniti quando un utente avvia per la prima volta la nuova versione dell'applicazione. Per precauzione si potrebbe quindi voler fare una copia di sicurezza dei file e delle directory nascosti («dotfile», cioè file i cui nomi iniziano con un punto) che si trovano nelle directory «home» degli utenti. Tale copia potrebbe aiutare a ripristinare o a ricreare le vecchie impostazioni. Potrebbe anche essere il caso di informare gli utenti su questo argomento.

Tutte le installazioni di pacchetti devono essere eseguite con i privilegi di superutente, per cui è necessario effettuare il login come utente root, oppure usare su o sudo, per ottenere i diritti d'accesso necessari.

L'aggiornamento ha alcune condizioni preliminari; prima di eseguirlo si dovrebbe verificarle.

È saggio informare in anticipo tutti gli utenti di qualunque aggiornamento si stia pianificando, anche se gli utenti che accedono al sistema tramite una connessione ssh non dovrebbero notare granché durante l'aggiornamento e dovrebbero poter continuare a lavorare.

Se si desidera prendere delle precauzioni supplementari, si esegua un salvataggio delle partizioni degli utenti (/home) o le si smonti prima di aggiornare il sistema.

Con l'aggiornamento a squeeze si dovrà anche fare un aggiornamento del kernel, per cui sarà necessario riavviare il sistema.

Tra i pacchetti interessati all'aggiornamento ci ne potrebbero essere alcuni a cui sono associati dei servizi. In questo caso, tali servizi potrebbero essere fermati mentre è in corso l'aggiornamento, la sostituzione o la configurazione dei pacchetti. In questo periodo di tempo i servizi non saranno disponibili.

La durata del disservizio varia a seconda del numero di pacchetti da aggiornare sul sistema e comprende anche il tempo che occorre all'amministratore di sistema per rispondere alle (eventuali) domande sulla configurazione poste dall'aggiornamento dei pacchetti. Notare che se l'aggiornamento non è presidiato e il sistema richiede una risposta per andare avanti è probabile che i servizi rimangano non disponibili^[4] per un periodo di tempo significativo.

Se il sistema da aggiornare fornisce dei servizi critici agli utenti o per la rete^[5], è possibile ridurre il tempo di disservizio facendo un aggiornamento minimo, come descritto in Sezione 4.4.4, «Aggiornamento minimo del sistema», seguito da un aggiornamento del kernel, un riavvio (vedere Sezione 4.4.5, «Aggiornamento del kernel e udev») e poi l'aggiornamento dei pacchetti associati ai servizi critici. Fare l'aggiornamento di questi pacchetti prima di fare l'aggiornamento completo descritto in Sezione 4.4.6, «Aggiornamento del sistema». Questo metodo assicura che i servizi critici restino in funzione mentre è in corso l'aggiornamento completo del sistema e che il periodo di disservizio sia breve.

A causa dei numerosi cambiamenti nel kernel fra lenny e squeeze inerenti i driver, il rilevamento dell'hardware e la denominazione e l'ordinamento dei file device, c'è un rischio reale di avere dei problemi al momento di riavviare il proprio sistema dopo l'aggiornamento. Molti di questi potenziali problemi sono documentati in questo e nei prossimi capitoli delle presenti note di rilascio.

Pertanto è sensato assicurarsi di essere in grado di ripristinare il proprio sistema se questi non riesce a riavviarsi o, per sistemi gestiti da remoto, a tirare su la rete.

Se si sta aggiornando da remoto tramite una connessione ssh è fortemente raccomandato prendere tutte le precauzioni necessarie per essere in grado di accedere al server tramite un terminale seriale remoto. È possibile che, dopo l'aggiornamento del kernel e il riavvio del sistema, taluni device vengano rinominati come descritto in Sezione 4.6.2, «Riordino dell'enumerazione dei dispositivi» e si debba sistemare la configurazione del sistema tramite una console locale. Analogamente, se il sistema viene accidentalmente riavviato nel mezzo di un aggiornamento è possibile che lo si debba ripristinare usando una console locale.

La cosa più ovvia da fare per prima è riavviare il sistema con il vecchio kernel. Tuttavia, per varie ragioni documentate altrove nel presente documento, non è sicuro che questo funzioni.

Se questa operazione non riesce, sarà necessario trovare un modo alternativo per avviare il proprio sistema in modo da potervi accedere per ripararlo. Una possibilità è l'utilizzo di un'immagine di ripristino speciale o di un CD live di Linux. Dopo aver avviato in tal modo, si dovrebbe essere in grado di montare il proprio file system radice ed entrarvi con chroot per trovare e correggere il problema.

Un'altra possibilità che si raccomanda di usare è la modalità di ripristino dell'installatore di Debian squeeze. Il vantaggio di questa opzione consiste nel fatto che è possibile scegliere, fra i suoi numerosi metodi di installazione, quello che meglio corrisponde alla propria situazione. Per maggiori informazioni si consulti la sezione «Recupero di un sistema danneggiato» nel capitolo 8 della Guida all'installazione e le FAQ dell'installatore di Debian.

L'aggiornamento della distribuzione dovrebbe essere eseguito o da locale, da una console virtuale in modalità testo (o da un terminale seriale collegato direttamente), o da remoto, tramite una connessione ssh.

	Importante
	I servizi VPN (quali tinc) potrebbero non essere disponibili durante l'aggiornamento. Consultare Sezione 4.1.3, «Preparazione all'indisponibilità dei servizi».

Per ottenere un margine supplementare di sicurezza durante l'aggiornamento da remoto si suggerisce di eseguire i processi di aggiornamento nella console virtuale fornita dal programma screen, che consente la riconnessione sicura e garantisce che il processo di aggiornamento non venga interrotto nemmeno nel caso in cui il processo di connessione remota si interrompa.

	Importante
	Non si dovrebbe eseguire l'aggiornamento usando telnet, rlogin, rsh, o da una sessione X gestita da xdm, gdm o kdm e simili sul sistema che si sta aggiornando, poiché ciascuno di questi servizi potrebbe essere terminato durante l'aggiornamento, generando quindi un sistema inaccessibile e aggiornato solo a metà.

A causa del bug #512951, è necessario disinstallare completamente il pacchetto splashy prima dell'aggiornamento.

	# apt-get purge splashy

In certi casi l'uso di apt-get per l'installazione di pacchetti in sostituzione di aptitude potrebbe far sì che aptitude consideri un pacchetto come «inutilizzato» e ne programmi la rimozione. In generale, ci si dovrebbe accertare che il proprio sistema sia completamente aggiornato e «pulito» prima di procedere all'aggiornamento.

Pertanto bisognerebbe controllare se vi sono operazioni in sospeso nel gestore di pacchetti aptitude: se è programmato l'aggiornamento o la rimozione di un pacchetto, questo potrebbe influire negativamente sul processo di aggiornamento. Si noti che la correzione di questa situazione è possibile solo se il proprio sources.list punta tuttora a lenny e non a stable o a squeeze. A tale proposito si consulti Sezione A.2, «Controllare la propria lista delle fonti».

A tal fine è necessario eseguire l'«interfaccia grafica» di aptitude e premere g («Scarica/Installa/Rimuovi»). Se viene mostrata una qualsiasi azione, si dovrebbe controllarla e o risolverla o eseguirla. Se non viene proposta alcuna azione sarà mostrato il messaggio «Non ci sono pacchetti da installare, rimuovere o aggiornare».

Se si è configurato APT in modo da installare taluni pacchetti da una distribuzione diversa da stable (ad esempio da testing), si potrebbe dover modificare la configurazione del pinning del proprio APT (memorizzata in /etc/apt/preferences) in modo da consentire l'aggiornamento dei pacchetti alle versioni nel nuovo rilascio stable. Maggiori informazioni sul pinning di APT sono disponibili in apt_preferences(5).

Si raccomanda di controllare dapprima lo stato di tutti i pacchetti e di verificare che tutti siano in uno stato aggiornabile, indipendentemente dal metodo usato per l'aggiornamento. Il comando seguente mostrerà tutti i pacchetti con uno stato «Half-Installed» o «Failed-Config» e quelli con un qualsiasi stato di errore.

# dpkg --audit

È anche possibile controllare lo stato di tutti i pacchetti sul proprio sistema usando dselect, aptitude, o con comandi come ad esempio

# dpkg -l | pager

o

# dpkg --get-selections "*" > ~/curr-pkgs.txt

È auspicabile la rimozione di qualsiasi blocco prima dell'aggiornamento. Se qualsiasi pacchetto essenziale per l'aggiornamento è bloccato («on hold»), l'aggiornamento fallirà.

Si noti che aptitude usa un metodo differente per registrare i pacchetti bloccati rispetto ad apt-get e dselect. È possibile identificare i pacchetti bloccati per aptitude eseguendo

# aptitude search "~ahold" | grep "^.h"

Se si desidera controllare quali pacchetti erano bloccati per apt-get, si dovrebbe eseguire

# dpkg --get-selections | grep hold

Se un pacchetto è stato modificato e ricompilato localmente, e non lo si è rinominato né vi si è aggiunto un numero di epoca nella versione, è necessario bloccarlo per impedire che venga aggiornato.

Lo stato «bloccato» di un pacchetto per apt-get può essere modificato eseguendo il comando:

# echo nome_pacchetto hold | dpkg --set-selections

Si sostituisca hold con install per rimuovere lo stato «bloccato» del pacchetto.

Se c'è bisogno di sistemare qualcosa è meglio controllare che il proprio sources.list punti sempre a lenny come illustrato in Sezione A.2, «Controllare la propria lista delle fonti».

Se la sezione proposed-updates è elencata nel proprio /etc/apt/sources.list, la si dovrebbe rimuovere da quel file prima di tentare l'aggiornamento del sistema. Questa precauzione serve per ridurre il rischio di conflitti.

Se si ha un qualsiasi pacchetto non-Debian nel proprio sistema, si presti attenzione al fatto che questi possono essere rimossi durante l'aggiornamento a causa di conflitti di dipendenze. Se questi pacchetti sono stati installati aggiungendo un archivio di pacchetti supplementare nel proprio /etch/apt/sources.list, si dovrebbe controllare che tale archivio offra anche pacchetti compilati per squeeze e modificare di conseguenza la riga della fonte contemporaneamente alle righe delle fonti per i pacchetti Debian.

Taluni utenti potrebbero aver installato nel proprio sistema versioni non ufficiali «più recenti» da backport rispetto ai pacchetti che sono in Debian lenny. Tali pacchetti sono i candidati più probabili a causare problemi durante un aggiornamento, in quanto potrebbero generare conflitti fra file^[7]. Alcune informazioni sulla gestione di conflitti fra file che potrebbero verificarsi sono disponibili in Sezione 4.5, «Possibili problemi durante l'aggiornamento».

La configurazione predefinita prevede l'installazione dai principali server internet di Debian, ma si potrebbe voler modificare il proprio /etc/apt/sources.list in modo che usi i mirror, preferibilmente uno più vicino dal punto di vista della rete.

Gli indirizzi dei mirror HTTP o FTP di Debian sono reperibili in http://www.debian.org/distrib/ftplist (si guardi la sezione «Elenco dei mirror Debian». Generalmente i mirror HTTP sono più veloci di quelli FTP.

Per esempio, si supponga che il proprio mirror Debian più vicino sia http://mirrors.kernel.org. Ispezionandolo con un browser web o un client FTP si noterà che le directory principali sono organizzate nel modo seguente:

http://mirrors.kernel.org/debian/dists/squeeze/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/squeeze/contrib/binary-i386/...

Per poter utilizzare questo mirror con apt, si aggiungerà al proprio file sources.list la seguente riga:

deb http://mirrors.kernel.org/debian squeeze main contrib

Si noti che «dists» è aggiunto implicitamente e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su directory multiple.

Dopo aver aggiunto le nuove fonti, si disabilitino le righe «deb» preesistenti in sources.list, ponendovi davanti un simbolo cancelletto (#).

Anziché usare mirror HTTP o FTP dei pacchetti, si potrebbe voler modificare /etc/apt/sources.list in modo che usi un mirror su un disco locale (possibilmente montato su NFS).

Per esempio, il proprio mirror dei pacchetti potrebbe essere in /var/ftp/debian/ e avere le directory principali come segue:

/var/ftp/debian/dists/squeeze/main/binary-i386/...
/var/ftp/debian/dists/squeeze/contrib/binary-i386/...

Per poter utilizzare questo mirror con apt, si aggiunga questa riga al proprio sources.list:

deb file:/var/ftp/debian squeeze main contrib

Si noti che «dists» è aggiunto implicitamente e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su directory multiple.

Dopo aver aggiunto le nuove fonti, si disabilitino le righe «deb» preesistenti in sources.list, ponendovi davanti un simbolo cancelletto (#).

Se si vogliono utilizzare soltanto CD-ROM si disabilitino, commentandole, le righe «deb» preesistenti in /etc/apt/sources.list, ponendovi davanti un simbolo cancelletto (#).

Ci si accerti che in /etc/fstab ci sia una riga che abilita l'accesso al proprio drive CD-ROM su /cdrom (apt-cdrom richiede che il file system sia montato esattamente su /cdrom). Ad esempio, se il drive del CD-ROM è chiamato /dev/hdc, /etc/fstab dovrebbe contenere una riga come la seguente:

/dev/hdc /cdrom auto defaults,noauto,ro 0 0

Si noti che non ci devono essere spazi fra le parole defaults,noauto,ro nel quarto campo.

Per verificare il funzionamento, inserire un CD-ROM e provare a eseguire

# mount /cdrom    # questo monterà il CD nel punto di montaggio
# ls -alF /cdrom  # dovrebbe mostrare il contenuto della radice del CD
# umount /cdrom   # questo smonterà il CD

Poi, si esegua:

# apt-cdrom add

per ciascun CD-ROM di binari di Debian che si possiede, al fine di aggiungere i dati di ciascun CD al database di APT.

È fortemente raccomandato l'utilizzo del programma /usr/bin/script per registrare una trascrizione della sessione di aggiornamento. In tal modo, se si verificasse un problema si disporrà di una registrazione di quanto accaduto e, se necessario, si potranno fornire le informazioni esatte in un'eventuale segnalazione di errori. Per avviare la registrazione, si digiti:

# script -t 2>~/upgrade-squeeze.time -a ~/upgrade-squeeze.script

o un comando simile. Non si collochi il file della registrazione in una directory temporanea come /tmp o /var/tmp, in quanto i file in queste directory potrebbero venir cancellati durante l'aggiornamento o durante un qualunque riavvio.

Il file generato permetterà anche di rileggere le informazioni scorse fuori dalla schermata. Se si usa la console di sistema, basterà passare a VT2 (con Alt+F2) e, dopo aver effettuato l'accesso, utilizzare il comando less -R ~root/upgrade-squeeze.script per visualizzare il file.

Dopo aver completato l'aggiornamento si può arrestare script, digitando exit al prompt.

Se si è utilizzato il parametro -t per script, si può utilizzare il programma scriptreplay per replicare l'intera sessione:

# scriptreplay ~/upgrade-squeeze.time ~/upgrade-squeeze.script

Anzitutto deve essere recuperata la lista dei pacchetti disponibili per la nuova versione. Lo si fa eseguendo:

# apt-get update

Prima di aggiornare il proprio sistema ci si deve accertare di avere uno spazio disponibile sufficiente sul proprio disco fisso al momento di far partire l'aggiornamento completo del sistema, come descritto in Sezione 4.4.6, «Aggiornamento del sistema». Per prima cosa, poiché ogni pacchetto necessario per l'installazione prelevato dalla rete è immagazzinato in /var/cache/apt/archives (e nella sottodirectory partial/, durante lo scaricamento), ci si dovrebbe assicurare di avere spazio a sufficienza nella partizione del file system che contiene /var per il temporaneo scaricamento dei pacchetti che saranno installati nel sistema. Dopo lo scaricamento sarà probabilmente necessario avere ulteriore spazio disponibile in altre partizioni del file system per poter installare sia i pacchetti aggiornati (che potrebbero contenere file binari più grossi o più dati), sia i nuovi pacchetti che saranno introdotti con l'aggiornamento. Se il sistema non ha spazio libero a sufficienza, si potrebbe finire con un aggiornamento incompleto dal quale potrebbe essere difficile effettuare un ripristino.

apt-get può mostrare informazioni dettagliate sullo spazio su disco necessario per l'installazione. È possibile visualizzare questa stima prima di eseguire effettivamente l'aggiornamento, eseguendo:

# apt-get -o APT::Get::Trivial-Only=true dist-upgrade
[ ... ]
XXX aggiornati, XXX installati, XXX da rimuovere e XXX non aggiornati.
È necessario scaricare xx.xMB di archivi.
Dopo quest'operazione, verranno occupati AAAMB di spazio su disco.

Nota

L'esecuzione di questo comando all'inizio del processo di aggiornamento potrebbe restituire un errore, per le ragioni descritte nelle sezioni seguenti. In tal caso sarà necessario attendere finché non sarà stato eseguito l'aggiornamento minimo del sistema come descritto in Sezione 4.4.4, «Aggiornamento minimo del sistema» e sarà stato aggiornato il kernel prima di eseguire il comando per avere una stima dello spazio necessario su disco.

Se lo spazio disponibile è insufficiente per l'aggiornamento, apt-get avverte con un messaggio come questo:

E: Spazio libero in /var/cache/apt/archives/ insufficiente.

In questo caso, accertarsi di liberare prima uno spazio sufficiente. È possibile:

Si noti che per rimuovere pacchetti in modo sicuro è preferibile tornare a far puntare il proprio sources.list a lenny, come descritto in Sezione A.2, «Controllare la propria lista delle fonti».

In alcuni casi, eseguire direttamente un aggiornamento completo (come descritto più avanti) potrebbe rimuovere un gran numero di pacchetti che si potrebbe voler mantenere. È quindi raccomandato un processo di aggiornamento in due parti: prima un aggiornamento minimo che risolva questi conflitti, poi un aggiornamento completo come descritto in Sezione 4.4.6, «Aggiornamento del sistema».

Per farlo eseguire:

# apt-get upgrade

Questo consentirà l'aggiornamento di quei pacchetti che possono essere aggiornati senza richiedere l'installazione o la rimozione di altri pacchetti.

L'aggiornamento minimo può essere utile anche quando non è possibile effettuare un aggiornamento completo perché sul sistema c'è poco spazio libero.

La versione di udev in squeeze necessita di un kernel 2.6.26 o più recente con l'opzione CONFIG_SYSFS_DEPRECATED disattiva e le opzioni CONFIG_INOTIFY_USER e CONFIG_SIGNALFD attive. Poiché i kernel Debian standard in lenny (versione 2.6.26) hanno CONFIG_SYSFS_DEPRECATED attiva e la versione in lenny di udev non fornisce tutte le funzionalità attese dai kernel più recenti, si deve prestare particolare attenzione durante l'aggiornamento in modo da evitare di rendere il proprio sistema non avviabile.

L'avvio del kernel 2.6.26 da lenny con la versione di udev di squeeze potrebbe comportare l'impossibilità di assegnare correttamente i nomi alle interfacce di rete e potrebbe fallire anche l'assegnazione di alcuni permessi aggiuntivi ai device a blocchi (per esempio l'accesso al gruppo disk). Sembra che il programma funzioni ma alcune regole (per esempio le regole per la rete) non sono caricate correttamente. Quindi si raccomanda fortemente di aggiornare adesso il kernel per conto proprio, in modo da assicurarsi di avere a disposizione un kernel compatibile prima dell'aggiornamento di udev.

Per procedere con questo aggiornamento del kernel, si esegua:

# apt-get install linux-image-2.6-flavor

Si consulti Sezione 4.6.1, «Installazione del metapacchetto del kernel» per poter determinare quale flavor di pacchetto kernel dovrebbe venir installato.

Gli utenti del bootloader grub devono essere sicuri che update-grub sia eseguito durante il processo di aggiornamento del kernel oppure di eseguirlo manualmente.

Immediatamente dopo aver aggiornato il kernel, si raccomanda l'installazione anche del nuovo udev per minimizzare il rischio di altre incompatibilità causate dall'uso del vecchio udev con il nuovo kernel^[8]. Per farlo eseguire:

# apt-get install udev

Dopo aver aggiornato il kernel e udev si deve riavviare il sistema.

Una volta completati i passaggi descritti in precedenza, si è pronti per continuare con la parte principale dell'aggiornamento. Si esegua:

# apt-get dist-upgrade

	Nota
	Nelle versioni precedenti era raccomandato l'uso di aptitude per l'aggiornamento. Questo programma non è raccomandato per l'aggiornamento da lenny a squeeze.

Questo comando eseguirà un aggiornamento completo del sistema, ossia installerà le versioni più recenti disponibili di tutti i pacchetti e risolverà i possibili cambiamenti di dipendenze fra i pacchetti dei diversi rilasci. Se necessario, esso installerà taluni nuovi pacchetti (normalmente nuove versioni di librerie o pacchetti rinominati) e rimuoverà i pacchetti resi obsoleti in conflitto.

In caso di aggiornamento da una serie di CD-ROM (o DVD), verrà chiesto di inserire uno specifico CD in parecchi momenti dell'aggiornamento. Potrebbe capitare di dover inserire più volte lo stesso CD: ciò è dovuto a pacchetti correlati tra loro che sono stati distribuiti su diversi CD.

Nuove versioni di pacchetti attualmente installati che non possono essere aggiornati senza modificare lo stato d'installazione di un altro pacchetto saranno lasciate alla loro attuale versione (contrassegnati come «held back»;, «bloccati»). Questo fatto può essere risolto o utilizzando aptitude, per designare tali pacchetti per l'installazione, o provando con apt-get -f install pacchetto.

Il supporto per cryptoloop è stato rimosso dai pacchetti del kernel Linux in Debian 6.0. Se si usa cryptoloop, è necessario migrare a dm-crypt prima dell'aggiornamento.

Il processo d'aggiornamento a squeeze potrebbe richiedere la rimozione di pacchetti dal sistema. L'elenco preciso dei pacchetti varia in base ai pacchetti installati. Queste note di rilascio forniscono un suggerimento generico riguardo le rimozioni di pacchetti, ma, nel dubbio, prima di proseguire si raccomanda di esaminare le rimozioni dei pacchetti che vengono proposte.

Alcuni pacchetti comuni che ci si attende vengano rimossi includono: autofs (sostituito da autofs5), dhcp3 (sostituito da isc-dhcp), madwifi-source, python-setuptools e python2.4 (sostituito da python2.6). Per un elenco più completo di pacchetti resi obsoleti con squeeze si consulti Sezione 4.10, «Pacchetti obsoleti».

Se un'operazione che usa aptitude, apt-get o dpkg fallisce con l'errore

E: Dynamic MMap ran out of room

significa che lo spazio predefinito della cache è insufficiente. È possibile risolvere questo problema rimuovendo o riducendo a commenti righe inutili in /etc/apt/sources.list, oppure aumentando la dimensione della cache, dando un opportuno valore alla variabile APT::Cache-Limit in /etc/apt/apt.conf. Il seguente comando la imposterà a un valore che dovrebbe essere sufficiente per l'aggiornamento:

# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Questo assume che la variabile non sia ancora stata impostata in quel file.

Talvolta è necessario abilitare l'opzione APT::Force-LoopBreak affinché APT possa rimuovere temporaneamente un pacchetto essenziale, a causa di un circolo «è in conflitto con»/«pre-dipende da». Di norma apt-get emetterà un avviso e cesserà l'aggiornamento. Si può evitare questa situazione specificando l'opzione -o APT::Force-LoopBreak=1 nella riga di comando di apt-get.

È possibile che la struttura di dipendenze di un sistema sia talmente compromessa da richiedere un intervento manuale; ciò normalmente significa l'uso di apt-get o di

# dpkg --remove nome_pacchetto

per eliminare alcuni dei pacchetti che generano il problema, o

# apt-get -f install
# dpkg --configure --pending

In casi estremi potrebbe essere necessario forzare la re-installazione con un comando del tipo di

# dpkg --install /percorso/di/nome_pacchetto.deb

Non si dovrebbero verificare conflitti tra file se si aggiorna da un sistema lenny «puro», ma potrebbero verificarsi se sono stati installati backport non ufficiali. Un conflitto tra file causerà un errore simile al seguente:

Spacchetto <pacchetto-tizio> (da <file-del-pacchetto-tizio>) ...
dpkg: errore processando <pacchetto-tizio> (--install):
 tentata sovrascrittura di `<nome-di-qualche-file>',
 che si trova anche nel pacchetto <pacchetto-caio>
dpkg-deb: il sottoprocesso paste è stato terminato da un segnale (Pipe rotta)
 Sono occorsi degli errori processando:
 <pacchetto-tizio>

Si può tentare di risolvere un conflitto fra file rimuovendo forzatamente il pacchetto menzionato nell'ultima riga del messaggio d'errore:

# dpkg -r --force-depends nome_pacchetto

Dopo aver risolto questo problema, si dovrebbe poter riprendere l'aggiornamento ripetendo i comandi apt-get descritti in precedenza.

Durante l'aggiornamento verranno poste domande riguardanti la configurazione o la riconfigurazione di parecchi pacchetti. Quando viene chiesto se un qualsiasi file nella directory /etc/init.d o il file /etc/manpath.config deve essere sostituito con quello fornito dal manutentore del pacchetto, di solito è necessario rispondere affermativamente, per garantire la coerenza del sistema. Si può sempre ritornare alle versioni precedenti, dal momento che queste verranno salvate con l'estensione .dpkg-old.

Se non si è sicuri sul da farsi, ci si annoti il nome del pacchetto o del file e si sistemino le cose in un momento successivo. Le informazioni presentate sullo schermo durante l'aggiornamento possono essere riesaminate dopo essere state cercate nel file generato durante l'aggiornamento.

Quando si usa la console locale del sistema per fare l'aggiornamento, potrebbe accadere che durante l'aggiornamento la console sia spostata su una vista diversa e che si perda la visibilità del processo d'aggiornamento. Questo può accadere, per esempio, sui sistemi desktop quando viene riavviato gdm.

Per recuperare la console su cui era in corso l'aggiornamento, usare Ctrl+Alt+F1 in modo da ritornare sul terminale virtuale 1 se nella schermata di avvio grafico, oppure usare Alt+F1 se si usa se in una console testuale locale. Al posto di F1 usare il tasto funzione con lo stesso numero del terminale virtuale su cui era in corso l'aggiornamento. Per scorrere i diversi terminali in modalità testuale è possibile usare Alt+Freccia Sinistra o Alt+Freccia Destra.

Nella maggior parte dei casi l'aggiornamento dei pacchetti da lenny a squeeze avviene tranquillamente. Ci sono pochi casi in cui potrebbe essere necessario un qualche tipo d'intervento, prima o durante l'aggiornamento; seguono i dettagli per ciascun pacchetto.

Quando si effettua il dist-upgrade da lenny a squeeze è fortemente raccomandata l'installazione di un nuovo metapacchetto linux-image-2.6-*, che potrebbe essere installato automaticamente dal processo di dist-upgrade. Lo si può verificare eseguendo:

# dpkg -l "linux-image*" | grep ^ii

Se non si vede alcun output, si dovrà installare manualmente un nuovo pacchetto linux-image. Per vedere un elenco dei metapacchetti linux-image-2.6 disponibili si esegua:

# apt-cache search linux-image-2.6- | grep -v transition

Se non si è sicuri sul pacchetto da selezionare, si esegua uname -r e si cerchi un pacchetto con un nome simile. Ad esempio, se si vede «2.6.26-2-686» è consigliata l'installazione di linux-image-2.6-686. Si può anche utilizzare apt-cache per vedere una lunga descrizione di ciascun pacchetto che aiuti a scegliere il migliore disponibile. Ad esempio:

# apt-cache show linux-image-2.6-686

Si dovrebbe quindi utilizzare apt-get install per installarlo. Una volta che questo nuovo kernel è installato si dovrebbe riavviare alla prossima opportunità disponibile per poter apprezzare i benefici offerti dalla nuova versione del kernel.

Per i più avventurosi esiste un modo agevole per compilare il proprio kernel personalizzato su Debian GNU/Linux. Si installi lo strumento kernel-package e si legga la documentazione contenuta in /usr/share/doc/kernel-package. In alternativa, è anche possibile usare i sorgenti del kernel, forniti dal pacchetto linux-source-2.6. Usare il target deb-pkg disponibile nel makefile dei sorgenti per creare il pacchetto binario. Ci sono alcune differenze tra questi due approcci, consultare la documentazione dei rispettivi pacchetti.

Se possibile, è preferibile aggiornare il pacchetto del kernel separatamente dall'aggiornamento dist-upgrade principale, per ridurre i rischi di trovarsi con un sistema temporaneamente non avviabile. Si noti che questo dovrebbe essere fatto soltanto dopo il processo di aggiornamento minimo descritto in Sezione 4.4.4, «Aggiornamento minimo del sistema».

Da lenny in poi un nuovo meccanismo del kernel per il rilevamento dell'hardware potrebbe cambiare l'ordine in cui i dispositivi vengono rilevati sul sistema a ogni avvio, interessando l'ordine in cui i nomi dei dispositivi sono assegnati. Per esempio, se si hanno due adattatori di rete associati a due diversi driver i dispositivi ai quali eth0 e eth1 fanno riferimento potrebbero venire scambiati.

Per i dispositivi di rete si può evitare questo riordino utilizzando le definizioni in /etc/udev/rules.d/70-persistent-net.rules di udev. Visto che queste regole erano già presenti in lenny, non è necessario fare alcuna operazione per l'aggiornamento a squeeze e beneficiare dei nomi persistenti per i dispositivi di rete. Si noti che questo meccanismo di udev comporta che il nome di un dispositivo di rete è associato a un particolare componente hardware; se, per esempio, si scambiano gli adattatori hardware su un sistema con squeeze, il nuovo adattatore prenderà un nuovo nome per l'interfaccia anziché usare il nome esistente. Per riusare il nome del dispositivo esistente per il nuovo hardware è necessario cancellare l'associazione da /etc/udev/rules.d/70-persistent-net.rules.

Per i dispositivi di archiviazione si potrebbe evitare questo riordino utilizzando initramfs-tools e configurandolo affinché carichi i driver dei dispositivi di archiviazione nel medesimo ordine in cui sono attualmente caricati. Comunque, alla luce delle altre modifiche nel sottosistema di archiviazione del kernel Linux come descritto in Sezione 5.1.1, «Migrazione dei driver dei dischi da sottosistema IDE a PATA», non vale la pena fare questa operazione e invece si raccomanda di usare dei nomi di device che sono garantiti per essere per sempre stabili, come gli alias UUID ^[9] nella directory /dev/disk/by-uuid/ o i nomi dei device LVM in /dev/mapper/.

Se per l'avvio del sistema viene utilizzato un initrd creato con initramfs-tools, in alcuni casi la creazione dei file di device ad opera di udev può accadere troppo tardi perché gli script di avvio possano agire su di essi.

I sintomi consueti sono che l'avvio fallirà poiché il file system radice non può essere montato e si sarà rinviati ad una shell di debug, ma che quando in seguito si effettuerà una verifica tutti i device necessari saranno presenti in /dev. Ciò è stato osservato in casi in cui il file system radice è su un disco USB o in RAID, specialmente se viene utilizzato LILO.

Un modo per aggirare questa problematica è l'utilizzo del parametro di avvio rootdelay=9. Il valore per il timeout (in secondi) potrebbe necessitare di una correzione.

È possibile evitare questo problema usando un identificatore per il file system radice che non cambia da un avvio all'altro. Ci sono due possibili metodi per ottenere questo risultato: dare un'etichetta al file system o usare l'identificatore unico universale (UUID) del file system. Questi metodi sono supportati in Debian a partire dalla versione etch.

Entrambi gli approcci hanno vantaggi e svantaggi. Quello di dare un'etichetta è più leggibile, ma ci potrebbero essere problemi se un altro file system sul proprio sistema ha la medesima etichetta. Quello UUID è meno carino, ma il caso di avere due UUID contrastanti è più unico che raro.

Poniamo ad esempio che il file system radice risieda in /dev/hda6 e supponiamo che il proprio sistema abbia un'installazione udev funzionante con file system ext2 o ext3.

Per implementare l'approccio di etichettatura:

Per implementare l'approccio UUID:

Durante l'aggiornamento verrà chiesto se "caricare in cascata" GRUB 2: cioè di tenere GRUB Legacy come bootloader principale e di aggiungergli una voce in modo da caricare GRUB 2 e poi proseguire l'avvio del sistema Debian con esso. Questo permette di verificare se sul proprio sistema GRUB 2 funziona prima di usarlo definitivamente.

Una volta verificato che GRUB 2 è funzionante, si dovrebbe iniziare a usarlo correttamente: la configurazione con il caricamento in cascata dovrebbe essere usata solo temporaneamente. Eseguire upgrade-from-grub-legacy per installarlo definitivamente.

Il manuale di GRUB contiene altre informazioni sui cambiamenti tra GRUB Legacy e GRUB 2, alcuni dei quali potrebbero richiedere delle modifiche alle configurazioni più complesse. Se non è stata modificata la configurazione del bootloader, non dovrebbe essere necessario fare nulla.

Taluni pacchetti per lenny sono stati suddivisi in diversi pacchetti in squeeze, spesso al fine di migliorare la manutenzione del sistema. Per facilitare il percorso di aggiornamento in tali casi, squeeze spesso fornisce pacchetti «fittizi», che sono pacchetti vuoti che hanno lo stesso nome del vecchio pacchetto in lenny con dipendenze che causano l'installazione dei nuovi pacchetti. Questi pacchetti «fittizi» sono considerati obsoleti dopo l'aggiornamento e possono essere rimossi in tutta sicurezza.

La descrizione della maggior parte dei pacchetti fittizi, ma non di tutti, indica il loro scopo. Purtroppo le descrizioni dei pacchetti fittizi non sono uniformi, per cui si potrebbe anche trovare utile lo strumento deborphan con le opzioni --guess-* (per esempio --guess-dummy) per trovarli nel proprio sistema. Si noti che alcuni pacchetti fittizi non sono creati per essere rimossi dopo un aggiornamento ma, invece, servono per tener traccia nel tempo della versione attualmente disponibile di un programma.