Capitolo 4. Aggiornamenti da rilasci precedenti

Sommario

4.1. Preparazione all'aggiornamento
4.1.1. Salvare i dati e le informazioni di configurazione
4.1.2. Informare gli utenti in anticipo
4.1.3. Preparazione per il ripristino
4.1.4. Preparazione di un ambiente sicuro per l'aggiornamento
4.1.5. Preparazione di initramfs per LILO
4.2. Verifica dello stato del sistema
4.2.1. Rivedere le azioni in sospeso nel gestore di pacchetti
4.2.2. Disattivare il pinning di APT
4.2.3. Verifica dello stato dei pacchetti
4.2.4. La sezione «proposed-updates» (aggiornamenti proposti)
4.2.5. Fonti non ufficiali e backport
4.3. Smarcare manualmente i pacchetti
4.4. Preparazione delle fonti per APT
4.4.1. Aggiunta di fonti internet per APT
4.4.2. Aggiunta di fonti da mirror locale per APT
4.4.3. Aggiunta di fonti per APT su CD-ROM o DVD
4.5. Aggiornare i pacchetti
4.5.1. Registrazione della sessione
4.5.2. Aggiornamento della lista dei pacchetti
4.5.3. Accertarsi di avere spazio disponibile a sufficienza per l'aggiornamento
4.5.4. Aggiornare dapprima apt, aptitude o entrambi
4.5.5. Uso con APT dell'elenco di aptitude dei pacchetti installati automaticamente
4.5.6. Aggiornamento minimo del sistema
4.5.7. Aggiornare il resto del sistema
4.5.8. Possibili problemi durante l'aggiornamento
4.6. Aggiornare il kernel e i pacchetti collegati
4.6.1. Installazione del metapacchetto del kernel
4.6.2. Riordino dell'enumerazione dei dispositivi
4.6.3. Problemi di temporizzazione dell'avvio
4.7. Cose da fare prima di riavviare il sistema
4.7.1. Rieseguire LILO
4.8. L'avvio del sistema si blocca su Waiting for root file system
4.8.1. Come evitare questo problema prima dell'aggiornamento
4.8.2. Come risolvere il problema dopo l'aggiornamento
4.9. Preparazione per il prossimo rilascio
4.10. Pacchetti obsoleti
4.10.1. Pacchetti fittizi

4.1. Preparazione all'aggiornamento

Prima di procedere all'aggiornamento si consiglia di leggere anche le informazioni contenute in Capitolo 5, Problemi di cui essere al corrente per lenny, dove vengono trattati i potenziali problemi non direttamente collegati al processo di aggiornamento, ma che potrebbe essere comunque importante conoscere prima di iniziare.

4.1.1. Salvare i dati e le informazioni di configurazione

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.

4.1.1.1. Accertarsi di essere su un kernel appropriato

La versione lenny di glibc non funzionerà con kernel antecedenti la versione 2.6.8 su qualsiasi architettura e alcune architetture hanno requisiti superiori. È fortemente raccomandato l'aggiornamento e il test di un kernel etch 2.6.18 o 2.6.24 o un kernel personalizzato di versione uguale o superiore a 2.6.18 prima di iniziare il processo di aggiornamento.

4.1.2. Informare gli utenti in anticipo

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

4.1.3. Preparazione per il ripristino

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.

4.1.3.1. Shell di debug durante l'avvio con initrd

initramfs-tools include una shell di debug[2] negli initrd che genera. Per esempio, se initrd non è in grado di montare il file system radice si verrà rimandati in questa shell di debug, la quale mette a disposizione i comandi di base per trovare il problema e, se possibile, risolverlo.

Le cose di base da controllare sono: la presenza dei file device corretti in /dev, quali moduli vengono caricati (cat /proc/modules) e l'output di dmesg per gli errori durante il caricamento dei driver. L'output di dmsesg mostra inoltre quali file device sono stati assegnati a quali dischi; questi risultati andranno confrontati con l'output di echo $ROOT, per assicurarsi che il file system radice sia sul device atteso.

Se si è riusciti a risolvere il problema, digitando exit si uscirà dalla shell di debug e si continuerà il processo di avvio a partire dal punto in cui il problema si è verificato. Naturalmente sarà anche necessario risolvere il problema sottostante e rigenerare initrd in modo che il prossimo avvio non fallisca nuovamente.

4.1.4. Preparazione di un ambiente sicuro per l'aggiornamento

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]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à.

4.1.5. Preparazione di initramfs per LILO

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.

4.2. Verifica dello stato del sistema

Il processo di aggiornamento descritto nel presente capitolo è stato concepito per aggiornamenti da sistemi etch «puri», ossia senza pacchetti di terze parti. Per ottenere un processo di aggiornamento il più affidabile possibile si potrebbero voler rimuovere i pacchetti di terze parti dal proprio sistema prima di iniziare l'aggiornamento.

Questa procedura presume altresì che il proprio sistema sia stato aggiornato fino all'ultimo aggiornamento disponibile per etch: se non è il caso, o se non si è sicuri, si seguano le istruzioni contenute in Sezione A.1, «Aggiornare il proprio sistema etch».

4.2.1. Rivedere le azioni in sospeso nel gestore di pacchetti

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 gScarica/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».

4.2.2. Disattivare il pinning di APT

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

4.2.3. Verifica dello stato dei pacchetti

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

4.2.4. La sezione «proposed-updates» (aggiornamenti proposti)

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.

4.2.5. Fonti non ufficiali e backport

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

4.2.5.1. Utilizzo di pacchetti backports.org

backports.org è un archivio semi-ufficiale, fornito dagli sviluppatori di Debian GNU/Linux, che mette a disposizione pacchetti più recenti per la versione stable, basati sulla ricompilazione di pacchetti dall'archivio di «testing».

L'archivio backports.org contiene pacchetti da «testing», ma con numeri di versione diminuiti, pertanto il percorso di aggiornamento dai backport di etch a lenny viene salvato. Ci sono comunque alcuni backport creati da unstable (aggiornamenti di sicurezza e le eccezioni seguenti: Firefox, kernel, OpenOffice.org, X.Org).

If you do not use one of these exceptions, you can safely upgrade to lenny. If you use one of these exceptions, set the Pin-Priority (see apt_preferences(5)) temporarily to 1001 for all packages from lenny, and you should be able to do a safe dist-upgrade too.

4.3. Smarcare manualmente i pacchetti

Al fine di impedire ad aptitude di rimuovere pacchetti che sono stati installati a seguito di dipendenze, sarà necessario smarcarli manualmente come pacchetti auto. Questo include OpenOffice e Vim per installazioni desktop:

# aptitude unmarkauto openoffice.org vim

E le immagini del kernel 2.6, se queste sono state installate usando un metapacchetto del kernel:

# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)
[Nota]Nota

È possibile controllare quali pacchetti sono marcati come auto in aptitude eseguendo:

# aptitude search '~i~M'

4.4. Preparazione delle fonti per APT

Prima di iniziare l'aggiornamento è necessario predisporre per le liste dei pacchetti il file di configurazione di apt, /etc/apt/sources.list.

apt prenderà in considerazione tutti i pacchetti che possono essere trovati tramite le righe «deb» e installerà il pacchetto con il numero di versione più alto, dando la priorità alle righe menzionate per prime (in questo modo, nel caso in cui siano presenti varie fonti equivalenti, tipicamente si dovrebbe menzionare per primo un disco fisso locale, poi il CD-ROM e infine il mirror HTTP/FTP).

[Suggerimento]Suggerimento

Potrebbe essere necessario aggiungere un'eccezione del controllo GPG per CD e DVD. Si aggiunga la seguenre riga a /etc/apt/apt.conf, se non è ancora presente in /etc/apt/apt.conf.d/00trustcdrom:

APT::Authentication::TrustCDROM "true";

Questo però non funziona con file di immagini di DVD/CD.

Si fa spesso riferimento a un rilascio sia tramite il suo nome in codice (ad esempio etch, lenny), sia tramite la denominazione del suo stato (cioè oldstable, stable, testing, unstable). Fare riferimento ad un rilascio attraverso il suo nome in codice presenta il vantaggio che non si sarà mai sorpresi da un nuovo rilascio, pertanto è il metodo qui adottato. Questo naturalmente significa che si dovrà prestare attenzione agli annunci di rilascio. Se invece si utilizza la denominazione dello stato, si vedrà una grande quantità di aggiornamenti disponibili per i propri pacchetti non appena avviene un rilascio.

4.4.1. Aggiunta di fonti internet per APT

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 (#).

4.4.2. Aggiunta di fonti da mirror locale per APT

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 (#).

4.4.3. Aggiunta di fonti per APT su CD-ROM o DVD

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.

4.5. Aggiornare i pacchetti

Il metodo raccomandato per l'aggiornamento dalle versioni precedenti di Debian GNU/Linux prevede l'utilizzo del gestore dei pacchetti aptitude, che rende le decisioni riguardanti le installazioni dei pacchetti più sicure rispetto all'esecuzione diretta di apt-get.

Non ci si dimentichi di montare tutte le partizioni necessarie (in particolare le partizioni radice e /usr) in modalità di lettura e scrittura, con un comando del tipo:

# mount -o remount,rw /mountpoint

Si dovrebbe poi controllare molto attentamente che le voci sulle fonti di APT (contenute in /etc/apt/sources.list) facciano riferimento a «lenny» o a «stable». Non ci dovrebbero essere voci di fonti che puntano a etch.

[Nota]Nota

Le righe delle fonti per un CD-ROM faranno spesso riferimento a «unstable»; sebbene ciò possa generare confusione, non le si dovrebbe modificare.

4.5.1. Registrazione della sessione

È 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

4.5.2. Aggiornamento della lista dei pacchetti

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.

4.5.3. Accertarsi di avere spazio disponibile a sufficienza per l'aggiornamento

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

  • Rimuovere i pacchetti che sono stati precedentemente scaricati per l'installazione (in /var/cache/apt/archives). La rimozione della cache dei pacchetti, eseguendo apt-get clean o aptitude clean, rimuoverà tutti i file dei pacchetti scaricati in precedenza.

  • Rimuovere i vecchi pacchetti non più utilizzati. Se si è installato popularity-contest, è possibile usare popcon-largest-unused per elencare i pacchetti che non vengono usati e che occupano più spazio nel sistema. È anche possibile usare deborphan o debfoster per trovare pacchetti obsoleti (vedere Sezione 4.10, «Pacchetti obsoleti»). In alternativa si può eseguire aptitude in «modalità grafica» e trovare i pacchetti obsoleti in «Pacchetti obsoleti e creati localmente».

  • Rimuovere i pacchetti che occupano troppo spazio e che non sono attualmente necessari (li si può sempre reinstallare dopo l'aggiornamento). È possibile ottenere un elenco dei pacchetti che occupano più spazio su disco eseguendo il comando dpigs (disponibile nel pacchetto debian-goodies) o wajig (eseguendo wajig size).

    You can list packages that take up most of the disk space with aptitude. Start aptitude into «visual mode», select ViewsNew Flat Package List (this menu entry is available only after etch version), press l and enter ~i, press S and enter ~installsize, then it will give you nice list to work with. Doing this after upgrading aptitude should give you access to this new feature.

  • Si elimino tutti i file di traduzioni e localizzazioni dal sistema se non sono necessari. È possibile installare il pacchetto localepurge e configurarlo in modo che solo poche localizzazioni selezionate vengano mantenute sul sistema. Questo ridurrà lo spazio su disco occupato da /usr/share/locale.

  • Spostare temporaneamente su un altro sistema, o rimuovere in modo permanente, i registri di sistema che si trovano in /var/log.

  • Usare un /var/cache/apt/archives temporaneo: è possibile usare una directory cache temporanea da un altro file system (periferiche di memorizzazione USB, dischi fissi temporanei, file system già in uso, ecc.)

    [Nota]Nota

    Non si usi una partizione montata via NFS, in quanto la connessione di rete potrebbe essere interrotta durante l'aggiornamento.

    Per esempio, se si possiede un disco o una penna USB montato in /media/usbkey:

    1. si rimuovano i pacchetti precedentemente scaricati per l'installazione:

      # apt-get clean

    2. si copi la directory /var/cache/apt/archives nella periferica USB:

      # cp -ax /var/cache/apt/archives /media/usbkey/

    3. si monti la directory della cache temporanea su quella attuale:

      # mount --bind /media/usbkey/archives /var/cache/apt/archives

    4. dopo l'aggiornamento, si ripristini la directory /var/cache/apt/archives originale:

      # umount /media/usbkey/archives

    5. si rimuova il restante /media/usbkey/archives.

    È possibile creare la cache temporanea su qualsiasi file system montato sul proprio sistema.

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

4.5.4. Aggiornare dapprima apt, aptitude o entrambi

Several bug reports have shown that the versions of the aptitude and apt packages in etch are often unable to handle the upgrade to lenny. In lenny, apt is better at dealing with complex chains of packages requiring immediate configuration and aptitude is smarter at searching for solutions to satisfy the dependencies. These two features are heavily involved during the dist-upgrade to lenny, so it is necessary to upgrade these two packages before upgrading anything else.

The following command will upgrade both aptitude and apt:

# aptitude install aptitude apt dpkg

This step will also automatically upgrade libc6 and locales. At this point, some running services will be restarted, including xdm, gdm and kdm. As a consequence, local X11 sessions might be disconnected.

[Nota]Upgrading with apt

Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first.

If you want to perform the upgrade with apt or if the upgrade with aptitude failed and you want to try the upgrade with apt' dependency chain resolution algorithm, you should run:

# apt-get install apt

Note that you will have to adapt other aptitude commands to use apt-get instead.

4.5.5. Uso con APT dell'elenco di aptitude dei pacchetti installati automaticamente

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"

4.5.6. Aggiornamento minimo del sistema

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

4.5.7. Aggiornare il resto del sistema

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.

4.5.8. Possibili problemi durante l'aggiornamento

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.

4.6. Aggiornare il kernel e i pacchetti collegati

Questa sezione spiega come aggiornare il kernel e identifica le relative potenziali problematiche. Si può o installare uno dei pacchetti linux-image-* forniti da Debian, oppure compilare un kernel personalizzato dai sorgenti.

Si noti che molte informazioni in questa sezione sono basate sull'assunzione che si utilizzerà uno dei kernel modulari di Debian, insieme con initramfs-tools e udev. Se si sceglie di utilizzare un kernel personalizzato che non richiede un initrd, o se si utilizza un generatore di initrd differente, alcune delle informazioni potrebbero non essere attinenti al proprio caso specifico.

4.6.1. Installazione del metapacchetto del kernel

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

4.6.2. Riordino dell'enumerazione dei dispositivi

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

4.6.3. Problemi di temporizzazione dell'avvio

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.

4.7. Cose da fare prima di riavviare il sistema

Quando aptitude dist-upgrade è giunto al termine, l'aggiornamento «formale» è concluso, ma vi sono alcune altre cose di cui ci si dovrebbe preoccupare prima del successivo riavvio.

4.7.1. Rieseguire LILO

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

4.8. L'avvio del sistema si blocca su Waiting for root file system

Procedura per il recupero da /dev/hda che è diventato /dev/sda

Taluni utenti hanno riferito che un aggiornamento potrebbe impedire al kernel di trovare la partizione radice del sistema dopo un riavvio.

In tal caso, l'avvio del sistema si bloccherà sul messaggio seguente:

Waiting for root file system ...

e dopo pochi secondi apparirà un semplice prompt di busybox.

Questo problema si può verificare quando l'aggiornamento del kernel introduce l'uso della nuova generazione di driver IDE. La convenzione per la denominazione dei dischi IDE per i vecchi driver era hda, hdb, hdc, hdd. I nuovi driver denomineranno i medesimi dischi rispettivamente sda, sdb, sdc, sdd. Il problema compare quando l'aggiornamento non genera un nuovo file /boot/grub/menu.lst per considerare la nuova convenzione di denominazione. Durante l'avvio, Grub passerà al kernel una partizione radice che il kernel non troverà.

Se dopo l'aggiornamento si è riscontrato questo problema, si consulti Sezione 4.8.2, «Come risolvere il problema dopo l'aggiornamento». Per evitare questo problema prima di aggiornare, si continui a leggere.

4.8.1. Come evitare questo problema prima dell'aggiornamento

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

  1. Attribuire l'etichetta al file system (il nome deve essere di < 16 caratteri), eseguendo il comando: e2label /dev/hda6 rootfilesys

  2. Modificare /boot/grub/menu.lst, cambiando la riga:

    # kopt=root=/dev/hda6 ro

    in

    # kopt=root=LABEL=rootfilesys ro

    [Nota]Nota

    Non si rimuova il carattere # all'inizio della riga, deve necessariamente essere lì.

  3. Si aggiornino le righe del kernel nel file menu.lst, eseguendo il comando update-grub.

  4. Si modifichi, in /etc/fstab, la riga che monta la la partizione /, per esempio:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    in

    LABEL=rootfilesys     /     ext3  defaults,errors=remount-ro 0 1

    La modifica più importante in questo caso è la prima colonna, non è necessario modificare le altre colonne di questa riga.

Per implementare l'approccio UUID:

  1. Find out the universally unique identifier of your filesystem by issuing: ls -l /dev/disk/by-uuid | grep hda6. You can also use vol_id --uuid /dev/hda6 (in etch) or blkid /dev/hda6 (if already upgraded to lenny).

    Si dovrebbe ottenere una riga simile alla seguente:

    lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a -> ../../hda6

    L'UUID è il nome del collegamento simbolico che punta a /dev/hda6, e cioé d0dfcc8a-417a-41e3-ad2e-9736317f2d8a.

    [Nota]Nota

    L'UUID del proprio file system sarà una stringa differente.

  2. Modificare /boot/grub/menu.lst, cambiando la riga:

    # kopt=root=/dev/hda6 ro

    in

    # kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro

    [Nota]Nota

    Non si rimuova il carattere # all'inizio della riga, deve necessariamente essere lì.

  3. Si aggiornino le righe del kernel nel file menu.lst, eseguendo il comando update-grub.

  4. Si modifichi, in /etc/fstab, la riga che monta la la partizione /, per esempio:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    in

    UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8  /  ext3  defaults,errors=remount-ro 0 1

    La modifica più importante in questo caso è la prima colonna, non è necessario modificare le altre colonne di questa riga.

4.8.2. Come risolvere il problema dopo l'aggiornamento

4.8.2.1. Soluzione 1

Questa soluzione è praticabile quando Grub mostra l'interfaccia del menù per selezionare la voce dalla quale si desidera avviare il proprio sistema. Se non compare, provare a premere Esc prima dell'avvio del kernel per farlo apparire. Se non si riesce ancora, si provi Sezione 4.8.2.2, «Soluzione 2» o Sezione 4.8.2.3, «Soluzione 3».

  1. Nel menù di Grub, evidenziare la voce dalla quale si desidera avviare il sistema e premere e per modificare le opzioni relative a questa voce. Apparirà qualcosa di simile a:

    root (hd0,0)
    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd /initrd.img-2.6.26-1-686

  2. Evidenziare la riga

    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro

    premere e e sostituire hdX con sdX (dove X corrisponde alla lettera a, b, c o d, a seconda del proprio sistema). Nel presente esempio, la riga diventa:

    kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro

    Poi si prema Enter per salvare la modifica. Se le altre righe mostrano hdX, si modifichino anche queste righe. Non si modifichino voci simili a root (hd0,0). Dopo che tutte le modifiche sono state effettuate, si prema b e il proprio sistema dovrebbe riprendere ad avviarsi come al solito.

  3. Ora che il proprio sistema si è avviato, sarà necessario risolvere questi problemi in modo definitivo. Si veda in Sezione 4.8.1, «Come evitare questo problema prima dell'aggiornamento» e si applichi una delle due procedure proposte.

4.8.2.2. Soluzione 2

Si avvii il proprio sistema da un supporto d'installazione Debian (CD/DVD) e al prompt si digiti rescue per avviare la modalità di ripristino. Selezionare la lingua, la località, la mappatura della tastiera, si lasci che configuri la rete (anche se tale configurazione fallisce non è un problema). Dopo un attimo comparirà la richiesta della partizione che si desidera usare come file system radice. Le scelte proposte saranno simili a quanto segue:

/dev/ide/host0/bus0/target0/lun0/part1
/dev/ide/host0/bus0/target0/lun0/part2
/dev/ide/host0/bus0/target0/lun0/part5
/dev/ide/host0/bus0/target0/lun0/part6

Se si sa quale partizione corrisponde al proprio file system radice, la si scelga. In caso contrario, provare con la prima. Se compare un messaggio d'errore per partizione di file system radice non valida, provare la seguente e così via. Provare una dopo l'altra non dovrebbe causare problemi alle partizioni e se si ha un solo sistema sui propri dischi dovrebbe essere abbastanza facile trovare la partizione giusta. Se si hanno molti sistemi, sarebbe più opportuno sapere esattamente quale partizione è quella giusta.

Una volta scelta la partizione saranno proposte varie opzioni. Si scelga di eseguire una shell nella partizione selezionata; se compare un messaggio d'errore che dice che non è possibile, si provi con un'altra partizione.

Ora si dovrebbe avere l'accesso shell come utente root al proprio file system radice montato su /target. Sarà necessario poter accedere al contenuto delle directory /boot, /sbin e /usr, che dovrebbero essere disponibili sotto /target/boot, /target/sbin e /target/usr. Se queste directory devono essere montate da altre partizioni, lo si faccia (si veda /etc/fstab se non si ha idea di quali partizioni vanno montate).

Si vada a Sezione 4.8.1, «Come evitare questo problema prima dell'aggiornamento» e si applichi una delle due procedure proposte per risolvere il problema in modo definitivo. Poi si digiti exit per uscire dalla shell di ripristino e si selezioni reboot per riavviare il sistema come al solito (non ci si dimentichi di rimuovere il supporto di avvio).

4.8.2.3. Soluzione 3

  1. Si avvii mediante la propria distribuzione Live CD preferita, come ad esempio Debian Live, Knoppix o Ubuntu Live.

  2. Si monti la partizione in cui si trova la propria directory /boot. Se non si sa quale sia, si usi l'output del comando dmesg per vedere se il proprio disco è conosciuto come hda, hdb, hdc, hdd o sda, sdb, sdc, sdd. Dopo aver trovato qual è il disco su cui si deve lavorare, per esempio sdb, eseguire il comando seguente per visualizzare la tabella delle partizioni del disco e trovare la partizione giusta: fdisk -l /dev/sdb.

  3. Presumendo che si sia montata la partizione corretta in /mnt e che la partizione contenga la directory /boot e il suo contenuto, si modifichi il file /mnt/boot/grub/menu.lst.

    Si trovi la sezione simile a:

    ## ## End Default Options ##
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd          /initrd.img-2.6.26-1-686
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode)
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro single
    initrd          /initrd.img-2.6.26-1-686
    
    ### END DEBIAN AUTOMAGIC KERNELS LIST

    e si sostituisca ogni hda, hdb, hdc, hdd rispettivamente con sda, sdb, sdc, sdd. Non si modifichi la riga simile a:

    root            (hd0,0)

  4. Si riavvii il sistema, si rimuova il LiveCD e il proprio sistema dovrebbe avviarsi correttamente.

  5. Dopo il riavvio, si applichi una delle due procedure proposte in Sezione 4.8.1, «Come evitare questo problema prima dell'aggiornamento» per risolvere il problema in modo definitivo.

4.9. Preparazione per il prossimo rilascio

Dopo l'aggiornamento ci sono molte cose che si possono fare per prepararsi per il prossimo rilascio.

  • Se il metapacchetto dell'immagine del nuovo kernel è stato inserito come dipendenza del precedente, sarà marcato come installato automaticamente, cosa che dovrebbe essere corretta.

    # aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
    
  • Si rimuovano i pacchetti obsoleti e quelli non utilizzati come descritto in Sezione 4.10, «Pacchetti obsoleti». Si dovrebbe controllare quali file di configurazione questi usano e considerare di effettuare una rimozione completa per eliminarli.

4.10. Pacchetti obsoleti

lenny introduce molte migliaia di nuovi pacchetti, ma nel contempo ritira e omette più di duemila vecchi pacchetti che c'erano in etch. Non viene fornito alcun percorso di aggiornamento per questi pacchetti obsoleti. Nulla impedisce di continuare a usare pacchetti obsoleti, se così si desidera, ma il progetto Debian terminerà il supporto di sicurezza per essi un anno dopo il rilascio di lenny[6] e non fornirà normalmente alcun altro supporto nel frattempo. La loro sostituzione con alternative disponibili, se ve ne sono, è raccomandata.

Vi sono molte ragioni per cui i pacchetti possono essere stati rimossi dalla distribuzione: non sono più mantenuti a monte, non vi sono più sviluppatori Debian interessati alla manutenzione dei pacchetti, le funzionalità fornite sono state superate da altri software o da una nuova versione, oppure non sono più considerati adatti per lenny a causa di errori. In quest'ultimo caso, i pacchetti potrebbero continuare a essere presenti nella distribuzione «unstable».

Trovare quali pacchetti in un sistema aggiornato sono «obsoleti» è facile, poiché le interfacce dei gestori di pacchetti li marcheranno come obsoleti. Se si usa aptitude, si vedrà una lista di questi pacchetti nella sezione «Pacchetti obsoleti e creati localmente». dselect fornisce una sezione simile, ma il modo di presentazione dell'elenco potrebbe essere differente.

Inoltre, se si è usato aptitude per installare manualmente dei pacchetti in etch, questi avrà tenuto traccia dei pacchetti installati per soddisfare delle dipendenze che non sono più necessari dal momento che il pacchetto viene rimosso. Analogamente aptitude, a differenza di deborphan, non marcherà come obsoleti i pacchetti che sono stati installati manualmente dall'utente, all'opposto di quelli che sono stati installati automaticamente a seguito di dipendenze.

Vi sono diversi strumenti supplementari che possono essere utilizzati per trovare pacchetti obsoleti, come ad esempio deborphan, debfoster o cruft. deborphan è altamente raccomandato, malgrado riporti, in modalità predefinita, solo le librerie obsolete: i pacchetti nelle sezioni «libs» od «oldlibs» che non vengono più utilizzati da alcun pacchetto. Non si rimuovano alla cieca i pacchetti presentati dagli strumenti, soprattutto se si usano opzioni aggressive non predefinite che possono produrre dei falsi positivi. È altamente raccomandato controllare manualmente i pacchetti suggeriti per la rimozione (ossia il loro contenuto, la loro dimensione e la descrizione) prima di rimuoverli.

Il Sistema di tracciamento dei bug (BTS) di Debian fornisce spesso informazioni aggiuntive sul perché un determinato pacchetto è stato rimosso. Si dovrebbero visionare sia i rapporti per il pacchetto stesso, sia i rapporti archiviati dei bug per lo pseudo-pacchetto ftp.debian.org.

The list of obsolete packages includes:

  • apache (1.x), il successore è apache2

  • bind (8), successor is bind9

  • php4, successor is php5

  • postgresql-7.4, successor is postgresql-8.1

  • exim (3), successor is exim4

4.10.1. Pacchetti fittizi

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.



[2] Questa funzionalità può essere disabilitata aggiungendo il parametro panic=0 ai parametri di avvio del proprio sistema.

[3] Normalmente il sistema di gestione di pacchetti di Debian non consente a un pacchetto di rimuovere o sostituire un file controllato da un altro pacchetto, a meno che non sia stato definito che il primo pacchetto sostituisceil secondo.

[4] Le regole ivi contenute sono generate automaticamente dallo script /etc/udev/rules.d/75_persistent-net-generator.rules, in modo da avere nomi persistenti per le interfacce di rete. Si elimini questo collegamento simbolico per disattivare l'assegnazione di nomi di dispositivo persistenti per i NIC tramite udev.

[5] Per maggiori informazioni sui codici di errore dell'avvio di lilo si veda The Linux Bootdisk HOWTO (in lingua inglese. La versione in italiano si trova in http://www.pluto.it/ildp/howto/bootdisk.html, ma attualmente la traduzione non è aggiornata).

[6] O per tutto il tempo in cui non uscirà un altro rilascio. Tipicamente solo due rilasci stabili sono supportati contemporaneamente.