Prima di aggiornare il proprio sistema è vivamente raccomandato 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/aptitude/pkgstates e l'output di dpkg --get-selections "*" (le virgolette sono importanti).

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, quantunque 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.

Probabilmente con l'aggiornamento a lenny si dovrà anche fare un aggiornamento del kernel, per cui normalmente sarà necessario riavviare il sistema. Tipicamente questo avverrà dopo la fine dell'aggiornamento.

A causa dei numerosi cambiamenti nel kernel fra etch e lenny 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 lenny. 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 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.

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 si accerta 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à.

Si informano gli utenti che usano il bootloader LILO del fatto che ora i parametri predefiniti per initramfs-tools generano un initramfs troppo grosso per essere caricato da LILO. Questi utenti dovrebbero quindi o passare a grub, o modificare il file /etc/initramfs-tools/initramfs.conf, modificando la riga

MODULES=most

in

MODULES=dep

Si noti comunque che, in seguito a tale operazione, initramfs-tools installerà solo i moduli necessari per lo specifico hardware su cui viene eseguito, nell'initramfs; pertanto, se si desidera generare un supporto di avvio che possa funzionare su più hardware rispetto a quello su cui lo si sta generando, si dovrebbe lasciare il parametro a

MODULES=most

e assicurarsi di non usare LILO.

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 etch e non a stable o a lenny. 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 un numero di epoca nella versione, è necessario bloccarlo per impedire che venga aggiornato.

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

# aptitude hold nome_pacchetto

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

Se c'è bisogno di sistemare qualcosa è meglio controllare che il proprio sources.list punti sempre a etch 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 lenny 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 etch. Tali pacchetti sono i candidati più probabili a causare problemi durante un aggiornamento, in quanto potrebbero generare conflitti fra file^[3]. Alcune informazioni sulla gestione di conflitti fra file che potrebbero verificarsi sono disponibili in Sezione 4.5.8, «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/lenny/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/lenny/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 lenny 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/lenny/main/binary-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

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

deb file:/var/ftp/debian lenny 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 filesystem 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-lenny.time -a ~/upgrade-lenny.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: basterà passare a VT2 (con Alt+F2) e, dopo aver effettuato l'accesso, utilizzare il comando less -R ~root/upgrade-lenny.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-lenny.time ~/upgrade-lenny.script

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

# aptitude update

L'esecuzione di questo comando per la prima volta dopo che le nuove fonti sono state aggiornate provocherà la visualizzazione a schermo di alcuni avvisi relativi alla disponibilità delle fonti. Questi avvisi sono innocui e non riappariranno quando si eseguirà nuovamente il comando.

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.5.7, «Aggiornare il resto 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.

Sia aptitude che apt mostreranno informazioni dettagliate sullo spazio su disco necessario per l'installazione. È possibile visualizzare questa stima prima di eseguire effettivamente l'aggiornamento, eseguendo:

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
XXX pacchetti aggiornati, XXX installati, XXX da rimuovere e XXX non aggiornati.
È necessario prelevare xx.xMB/yyyMB di archivi. Dopo l'estrazione, verranno occupati AAAMB.
Saranno scaricati/installati/rimossi pacchetti.

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.5.6, «Aggiornamento minimo del sistema» e sarà stato aggiornato il kernel come descritto in Sezione 4.1.1.1, «Accertarsi di essere su un kernel appropriato», prima di eseguire il comando per avere una stima dello spazio libero su disco.

Se lo spazio disponibile è insufficiente per l'aggiornamento, 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 etch, come descritto in Sezione A.2, «Controllare la propria lista delle fonti».

Molte segnalazioni d'errore hanno mostrato che le versioni dei pacchetti aptitude e apt in etch spesso non sono in grado di gestire l'aggiornamento a lenny. In lenny, apt è in grado di gestire meglio concatenamenti complessi di pacchetti che richiedono una configurazione immediata, mentre aptitude è più abile nel trovare soluzioni per soddisfare le dipendenze. Poiché queste due funzioni sono pesantemente chiamate in causa durante l'aggiornamento a lenny, è richiesto l'aggiornamento di questi due pacchetti prima di qualsiasi altro. Per apt si esegua:

# apt-get install apt

e per aptitude (se è installato) si esegua invece:

# aptitude install aptitude

Questo passo aggiornerà automaticamente libc6 e locales e includerà le librerie di supporto a SELinux (libselinux1). A questo punto, alcuni servizi saranno riavviati, inclusi xdm, gdm e kdm. Di conseguenza, le sessioni locali di X11 potrebbero essere disconnesse.

aptitude mantiene una lista di pacchetti che sono stati installati automaticamente (per esempio, in quanto dipendenze di un altro pacchetto). In lenny, anche apt possiede questa funzionalità.

Alla prima esecuzione della versione lenny di aptitude, esso leggerà la lista dei pacchetti installati automaticamente e la convertirà per l'uso con la versione lenny di apt. Se si ha aptitude installato, si dovrebbe eseguire almeno una volta il comando aptitude per effettuare la conversione. Un modo per eseguire questa operazione è la ricerca di pacchetti inesistenti:

# aptitude search "?false"

A causa dei conflitti fra alcuni pacchetti necessari fra etch e lenny, l'esecuzione diretta di aptitude dist-upgrade rimuoverà spesso grandi quantità di pacchetti che si vorranno mantenere. È quindi raccomandato un processo di aggiornamento in due parti: prima un aggiornamento minimo che risolva questi conflitti, poi un dist-upgrade completo.

Dapprima si esegua:

# aptitude safe-upgrade

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

Il prossimo passo varierà in funzione dell'insieme di pacchetti che si ha installati. Queste note di rilascio forniscono un suggerimento generico sul metodo da usare, ma, nel dubbio, prima di proseguire si raccomanda di esaminare le rimozioni dei pacchetti che vengono proposte da ogni metodo.

Taluni pacchetti comuni che ci si attende vengano rimossi includono base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common e xserver-common. Per un elenco più completo di pacchetti resi obsoleti con lenny si consulti Sezione 4.10, «Pacchetti obsoleti».

Si è ora pronti per continuare con la parte principale dell'aggiornamento. Si esegua:

# aptitude dist-upgrade

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, 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 intercorrelati 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 aptitude -f install pacchetto.

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 aptitude 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 aptitude.

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

# dpkg --remove nome_pacchetto

per eliminare taluni dei pacchetti che generano il problema, o

# aptitude -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 etch «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 aptitude 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 nelle directory /etc/init.d o /etc/terminfo 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 effettua il dist-upgrade da etch a lenny è 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.4.27-3-686» è consigliata l'installazione di linux-image-2.6-686. Si noti che il flavor 386 non esiste più: se si sta attualmente utilizzando il flavor 386 del kernel, si dovrebbe installare al suo posto il flavor 486. 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 aptitude 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.

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 veda Sezione 4.1.1.1, «Accertarsi di essere su un kernel appropriato» per una descrizione di tale processo. Si noti che questo dovrebbe essere fatto soltanto dopo il processo di aggiornamento minimo descritto in Sezione 4.5.6, «Aggiornamento minimo del sistema».

lenny è caratterizzato da un meccanismo di rilevamento dell'hardware più robusto di quelli dei precedenti rilasci. Questo potrebbe tuttavia causare cambiamenti nell'ordine in cui i dispositivi vengono rilevati sul sistema, 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. Si noti che il nuovo meccanismo significa che se ad esempio si sostituiscono gli adattatori Ethernet in un sistema lenny in funzione, il nuovo adattatore riceverà anche un nuovo nome d'interfaccia.

Per i dispositivi di rete si può evitare questo riordino utilizzando le regole di udev, più specificamente tramite le definizioni in /etc/udev/rules.d/70_persistent-net.rules^[4]. In alternativa è possibile utilizzare l'utility ifrename per collegare dispositivi fisici a specifici nomi all'avvio. Per maggiori informazioni si vedano ifrename(8) e iftab(5). Le due alternative (udev e ifrename) non dovrebbero essere utilizzate contemporaneamente.

Per i dispositivi di archiviazione si può evitare questo riordino utilizzando initramfs-tools e configurandolo affinché carichi i driver dei dispositivi di archiviazione nel medesimo ordine in cui vengono attualmente caricati. A tal fine si identifichi l'ordine in cui i moduli di archiviazione sul proprio sistema vengono caricati, verificando l'output di lsmod. lsmod elenca i moduli nell'ordine inverso rispetto a quello in cui sono stati caricati, per esempio il primo modulo della lista è l'ultimo che è stato caricato. Si noti che questo funziona solo con dispositivi che il kernel enumera in un ordine stabile (come i dispositivi PCI).

Tuttavia la rimozione e il ricaricamento dei pacchetti dopo l'avvio iniziale avrà effetto su tale ordine. Inoltre, il kernel potrebbe avere alcuni moduli collegati staticamente, e i loro nomi non appariranno nell'output di lsmod. Si potrebbe riuscire a ricavare i nomi di tali driver e l'ordine del loro caricamento leggendo il file /var/log/kern.log oppure l'output di dmesg.

Si aggiungano i nomi di tali moduli a /etc/initramfs-tools/modules nell'ordine in cui essi dovrebbero essere caricati all'avvio. Alcuni nomi di moduli potrebbero essere cambiati da etch a lenny: per esempio, sym53c8xx_2 è diventato sym53c8xx.

Sarà quindi necessario rigenerare le proprie immagini initramfs eseguendo update-initramfs -u -k all.

Una volta che si hanno in esecuzione un kernel e un udev di lenny, è possibile riconfigurare il proprio sistema per accedere ai dischi tramite un alias che non dipenda dall'ordine di caricamento dei driver. Questi alias sono memorizzati nella gerarchia /dev/disk/.

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 filesystem 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.

Se si sta utilizzando lilo come bootloader (è il bootloader predefinito per alcune installazioni di etch), si raccomanda vivamente di rieseguire lilo dopo l'aggiornamento:

# /sbin/lilo

Si noti che questo è necessario anche se non si è aggiornato il kernel del sistema, dal momento che il secondo stadio di lilo cambierà a causa dell'aggiornamento del pacchetto.

Si controlli inoltre il contenuto del file /etc/kernel-img.conf e ci si assicuri di avervi do_bootloader = Yes. In tal modo il bootloader sarà sempre rieseguito dopo un aggiornamento del kernel.

Se si incontrano problemi durante l'esecuzione di lilo, si controllino i collegamenti simbolici in / a vmlinuz e a initrd, nonché il contenuto del proprio /etc/lilo.conf per eventuali discrepanze.

Se ci si dimentica di rieseguire lilo prima del riavvio, o se il sistema viene riavviato accidentalmente prima che lo si possa fare manualmente, il sistema potrebbe non riuscire ad avviarsi. Al posto del prompt di LILO, si vedrà soltanto LI all'avvio del sistema^[5]. Per informazioni su come ripristinare da questa condizione, si veda Sezione 4.1.3, «Preparazione per il ripristino».

È 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:

Taluni pacchetti per etch sono stati suddivisi in diversi pacchetti in lenny, spesso al fine di migliorare la manutenzione del sistema. Per facilitare il percorso di aggiornamento in tali casi, lenny spesso fornisce pacchetti «fittizi», che sono pacchetti vuoti che hanno lo stesso nome del vecchio pacchetto in etch 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. Le descrizioni dei pacchetti fittizi non sono uniformi, comunque, per cui si potrebbe anche trovare utile lo strumento deborphan con l'opzione --guess per trovarli nel proprio sistema. Si noti che taluni pacchetti fittizi non sono creati per essere rimossi dopo un aggiornamento ma, invece, servono per tener traccia nel tempo della versione attualmente disponibile.