Capitolo 4. Aggiornamenti da Debian 5.0 (lenny)

Indice

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 all'indisponibilità dei servizi
4.1.4. Preparazione per il ripristino
4.1.5. Preparazione di un ambiente sicuro per l'aggiornamento
4.1.6. Rimozione dei pacchetti in conflitto
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. Preparazione delle fonti per APT
4.3.1. Aggiunta di fonti internet per APT
4.3.2. Aggiunta di fonti per APT da mirror locale
4.3.3. Aggiunta di fonti per APT su CD-ROM o DVD
4.4. Aggiornare i pacchetti
4.4.1. Registrazione della sessione
4.4.2. Aggiornamento della lista dei pacchetti
4.4.3. Accertarsi di avere spazio disponibile a sufficienza per l'aggiornamento
4.4.4. Aggiornamento minimo del sistema
4.4.5. Aggiornamento del kernel e udev
4.4.6. Aggiornamento del sistema
4.5. Possibili problemi durante l'aggiornamento
4.5.1. Il Supporto cryptoloop non è incluso nel kernel Linux di squeeze
4.5.2. Rimozioni attese
4.5.3. Errori durante l'esecuzione di aptitude o apt-get
4.5.4. Conflitti e pre-dipendenze cicliche
4.5.5. Conflitti tra file
4.5.6. Modifiche alla configurazione
4.5.7. Cambiare la sessione sulla console
4.5.8. Pacchetti che richiedono un'attenzione particolare
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. Boot timing issues (waiting for root device)
4.7. Preparazione per il prossimo rilascio
4.8. Componenti deprecati
4.9. Pacchetti obsoleti
4.9.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 squeeze, 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 si raccomanda di effettuare un salvataggio completo o quantomeno una copia di sicurezza di tutti quei dati e quelle informazioni di configurazione che non ci si può permettere di perdere. Gli strumenti e i processi di aggiornamento sono abbastanza affidabili, ma un problema dell'hardware durante l'aggiornamento potrebbe generare un sistema fortemente danneggiato.

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

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

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

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

4.1.2. Informare gli utenti in anticipo

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

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

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

4.1.3. Preparazione all'indisponibilità dei servizi

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

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

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

4.1.4. Preparazione per il ripristino

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

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

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

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

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

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

4.1.4.1. Shell di debug durante l'avvio con initrd

initramfs-tools include una shell di debug[6] 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 dmesg 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.5. 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.

[Importante]Importante

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

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

[Importante]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à. L'uso dell'applicazione GNOME update-manager per l'aggiornamento alla nuova versione è fortemente sconsigliato poiché tale programma fa affidamento sul fatto che la sessione desktop rimanga attiva.

4.1.6. Rimozione dei pacchetti in conflitto

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

	# apt-get purge splashy

4.2. Verifica dello stato del sistema

Il processo di aggiornamento descritto nel presente capitolo è stato concepito per aggiornamenti da sistemi lenny «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.

L'aggiornamento diretto dalle versioni di Debian precedenti a 5.0 (lenny) non è supportato. Seguire le istruzioni nelle Note di Rilascio per Debian GNU/Linux 5.0 per aggiornare prima a 5.0.

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

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 lenny e non a stable o a squeeze. A tale proposito si consulti Sezione A.2, «Controllare la propria lista delle fonti».

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

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" 

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

# dpkg --get-selections | grep hold

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

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

# echo nome_pacchetto hold | dpkg --set-selections

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

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

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 squeeze e modificare di conseguenza la riga della fonte contemporaneamente alle righe delle fonti per i pacchetti Debian.

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

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

Si fa spesso riferimento a un rilascio sia tramite il suo nome in codice (ad esempio lenny, squeeze), 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.3.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/squeeze/main/binary-mipsel/...
http://mirrors.kernel.org/debian/dists/squeeze/contrib/binary-mipsel/...

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

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

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

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

4.3.2. Aggiunta di fonti per APT da mirror locale

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 (eventualmente montato su NFS).

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

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

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

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

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

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

4.3.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 file system sia montato esattamente su /cdrom). Ad esempio, se il drive del CD-ROM è chiamato /dev/hdc, /etc/fstab dovrebbe contenere una riga come la seguente:

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

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

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

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

Poi, si esegua:

# apt-cdrom add

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

4.4. Aggiornare i pacchetti

Il metodo raccomandato per l'aggiornamento dalle versioni precedenti di Debian GNU/Linux prevede l'utilizzo del gestore dei pacchetti apt-get. Nelle versioni precedenti era consigliato aptitude per questo scopo, ma le versioni più recenti di apt-get forniscono delle funzionalità equivalenti e si sono mostrate anche più affidabili negli aggiornamenti.

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

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

[Nota]Nota

Qualche volta le righe delle fonti per un CD-ROM potrebbero fare riferimento a «unstable»; sebbene ciò possa generare confusione non le si dovrebbe modificare.

4.4.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-squeezestep.time -a ~/upgrade-squeezestep.script

o un comando simile. Se fosse necessario fare la trascrizione di un'altra sessione (perché, per esempio, è necessario riavviare il sistema), usare valori diversi per step in modo da indicare anche la fase dell'aggiornamento che si sta registrando. Non si collochi il file della registrazione in una directory temporanea come /tmp o /var/tmp, in quanto i file in queste directory potrebbero venir cancellati durante l'aggiornamento o durante un qualunque riavvio.

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

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

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

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

4.4.2. Aggiornamento della lista dei pacchetti

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

# apt-get update

4.4.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.4.6, «Aggiornamento del sistema». Per prima cosa, poiché ogni pacchetto necessario per l'installazione prelevato dalla rete è immagazzinato in /var/cache/apt/archives (e nella sottodirectory partial/, durante lo scaricamento), ci si dovrebbe assicurare di avere spazio a sufficienza nella partizione del file system che contiene /var per il temporaneo scaricamento dei pacchetti che saranno installati nel sistema. Dopo lo scaricamento sarà probabilmente necessario avere ulteriore spazio disponibile in altre partizioni del file system per poter installare sia i pacchetti aggiornati (che potrebbero contenere file binari più grossi o più dati), sia i nuovi pacchetti che saranno introdotti con l'aggiornamento. Se il sistema non ha spazio libero a sufficienza, si potrebbe finire con un aggiornamento incompleto dal quale potrebbe essere difficile effettuare un ripristino.

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

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

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

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

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

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

  • Rimuovere i pacchetti che sono stati precedentemente scaricati per l'installazione (in /var/cache/apt/archives). Per pulire la cache dei pacchetti, eseguire apt-get clean, rimuoverà tutti i file dei pacchetti scaricati in precedenza.

  • Rimuovere i pacchetti dimenticati. 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.9, «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).

    Si possono elencare i pacchetti che occupano molto spazio sul disco con aptitude. Si avvii aptitude in «modalità grafica», si selezioni VisteNuovo elenco unito dei pacchetti, si prema l e si inserisca ~i, si prema S e si inserisca ~installsize, a quel punto si dovrebbe ottenere un bell'elenco con cui lavorare.

  • Si eliminino 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 log di sistema che si trovano in /var/log.

  • Usare un /var/cache/apt/archives temporaneo: è possibile usare una directory di 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.

  • Effettuare un aggiornamento minimo del sistema (vedere Sezione 4.4.4, «Aggiornamento minimo del sistema») oppure degli aggiornamenti parziali seguiti da un aggiornamento completo. Questo permette l'aggiornamento parziale del sistema e permette di pulire la cache dei pacchetti prima dell'aggiornamento completo.

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

4.4.4. Aggiornamento minimo del sistema

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

Per farlo eseguire:

# apt-get upgrade

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

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

4.4.5. Aggiornamento del kernel e udev

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

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

Per procedere con questo aggiornamento del kernel, si esegua:

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

Si consulti Sezione 4.6.1, «Installazione del metapacchetto del kernel» per poter determinare quale flavor del pacchetto kernel si dovrebbe installare.

Lo spostamento di parte del firmware in pacchetti separati dell'archivio non-free (si veda Sezione 2.1.2, «Firmware spostato nella sezione non-free») potrebbe causare la necessità d'installare altri pacchetti con il firmware dopo l'aggiornamento del kernel per supportare l'hardware. Controllare se durante l'installazione del kernel o durante l'uso degli script di generazione dell'initramfs si presentano dei messaggi d'avviso e assicurarsi che i necessari pacchetti con il firmware siano installati.

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

# apt-get install udev

Riavviare il sistema[9] dopo aver aggiornato il kernel e udev.

4.4.6. Aggiornamento del sistema

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

# apt-get dist-upgrade
[Nota]Nota

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

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

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

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

4.5. Possibili problemi durante l'aggiornamento

Nelle prossime sezioni sono descritti i problemi noti che potrebbero verificarsi durante l'aggiornamento a squeeze.

4.5.1. Il Supporto cryptoloop non è incluso nel kernel Linux di squeeze

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

4.5.2. Rimozioni attese

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

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

4.5.3. Errori durante l'esecuzione di aptitude o apt-get

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.

4.5.4. Conflitti e pre-dipendenze cicliche

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

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

# dpkg --remove nome_pacchetto

per eliminare alcuni dei pacchetti che generano il problema, o

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

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

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

4.5.5. Conflitti tra file

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

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

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

# dpkg -r --force-depends nome_pacchetto

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

4.5.6. Modifiche alla configurazione

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

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

4.5.7. Cambiare la sessione sulla console

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

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

4.5.8. Pacchetti che richiedono un'attenzione particolare

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

4.5.8.1. Evolution

Evolution (il client email di GNOME) è stato aggiornato dalla versione 2.22 alla 2.30. Questo comporta il cambiamento del formato usato dal pacchetto per i dati locali ed è possibile che si verifichino delle perdite di dati se l'aggiornamento è effettuato mentre evolution è in esecuzione. La chiusura dell'applicazione potrebbe non essere sufficiente poiché alcuni componenti potrebbero comunque rimanere in esecuzione. Per evitare potenziali problemi si raccomanda di chiudere completamente l'ambiente desktop prima di iniziare l'aggiornamento a squeeze.

Durante il processo di aggiornamento evolution controlla se sono in esecuzione dei processi a esso legato e raccomanda di chiuderli. Viene effettuato anche un secondo controllo e, se necessario, offre la possibilità di chiudere i processi rimasti o di annullare l'aggiornamento per risolvere il problema manualmente.

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 lenny a squeeze è fortemente raccomandata l'installazione di un nuovo metapacchetto linux-image-2.6-*, che potrebbe essere installato automaticamente dal processo di dist-upgrade. Lo si può verificare eseguendo:

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

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

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

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

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

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

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

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

4.6.2. Riordino dell'enumerazione dei dispositivi

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

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

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

4.6.3. Boot timing issues (waiting for root device)

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.

The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell:

Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/something does not exist.  Dropping to a shell!
(initramfs) 

But if you check afterwards, all devices that are needed are present in /dev. This has been observed in cases where the root file system is on a USB disk or on RAID, especially if LILO is used.

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. Preparazione per il prossimo rilascio

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

  • Si rimuovano i pacchetti obsoleti e quelli non utilizzati come descritto in Sezione 4.9, «Pacchetti obsoleti». Si dovrebbe controllare quali file di configurazione questi usano e considerare di effettuare una rimozione completa per eliminarli.

4.8. Componenti deprecati

Con la prossima versione di Debian GNU/Linux 7.0 (nome in codice wheezy) alcune funzionalità verranno rese deprecate. Gli utenti dovranno migrare verso una delle alternative in modo da prevenire problemi durante l'aggiornamento a 7.0.

Questo include le seguenti funzionalità:

  • OpenVZ e Linux-Vserver: Debian GNU/Linux 6.0 è l'ultimo rilascio a includere gli insiemi di funzioni di virtualizzazione non presenti ufficialmente nel kernel Linux. Questo comporta che gli insiemi di funzioni OpenVZ e Linux-Vserver devono essere considerati deprecati e che gli utenti dovrebbero migrare verso una delle soluzioni di virtualizzazione presenti in linux-2.6 quali KVM, Linux Containers o Xen.

  • Il pacchetto gdm (GNOME Display Manager versione 2.20) è reso obsoleto da gdm3, una versione riscritta. Si consulti Sezione 5.6, «Cambiamenti e supporto nel desktop GNOME» per ulteriori dettagli.

4.9. Pacchetti obsoleti

squeeze introduce molte migliaia di nuovi pacchetti, ma nel contempo ritira e omette più di quattromila vecchi pacchetti che erano in lenny. 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 squeeze[11] 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 squeeze 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 l'elenco presentato potrebbe essere differente.

Inoltre, se si è usato aptitude o apt-get per installare manualmente dei pacchetti in lenny, questi avranno tenuto traccia dei pacchetti installati manualmente e saranno capaci di marcare come obsoleti quei pacchetti installati solo per soddisfare delle dipendenze e che non sono più necessari se un pacchetto viene rimosso. aptitude e apt, a differenza di deborphan, non marcheranno per la rimozione i pacchetti che sono stati installati manualmente dall'utente, all'opposto di quelli che sono stati installati automaticamente a seguito di dipendenze. Per rimuovere automaticamente i pacchetti che non sono più usati, eseguire:

# apt-get autoremove

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.

L'elenco dei pacchetti obsoleti comprende:

  • La suite di gestione dei contenuti plone. Su richiesta da parte degli sviluppatori di usare lo Unified Installer per Linux perché ritenuto l'unica piattaforma di distribuzione supportata. Lo strumento per l'installazione di Plone su un sistema Debian è lo Unified Installer, scaricabile da http://plone.org/

  • nessus, il server di scansione delle vulnerabilità e le relative librerie e altro software. È stato deprecato in favore del software fornito da OpenVAS che include openvas-server e openvas-client. Poiché non esiste una procedura d'aggiornamento automatica è necessario installare OpenVAS e migrare manualmente la configurazione del servizio Nessus (utenti, certificati, ecc.) su OpenVAS.

  • postgresql-8.3, il successore è postgresql-8.4.

  • mysql-server-5.0, il successore è mysql-server-5.1.

  • python2.4, il successore è python2.6.

  • Java 5 compresi i pacchetti sun-java5-jre e sun-java5-bin, il successore è Java 6: sun-java6-jre e i pacchetti associati.

  • apt-proxy non è più fornito, delle alternative a questo programma sono apt-cacher-ng, apt-cacher e approx. Purtroppo non esiste un metodo d'aggiornamento automatico, gli utenti di apt-proxy possono passare a una delle alternative installando manualmente un qualsiasi pacchetto tra questi.

  • Alcuni driver video obsoleti di Xorg non sono più disponibili in squeeze. Questi driver includono xserver-xorg-video-cyrix, xserver-xorg-video-i810, xserver-xorg-video-imstt, xserver-xorg-video-nsc, xserver-xorg-video-sunbw2 e xserver-xorg-video-vga. Questi potrebbero essere rimossi durante l'aggiornamento, gli utenti possono installare xserver-xorg-video-all al loro posto.

  • Il programma usplash che in lenny mostrava un'immagine durante l'avvio non è più disponibile. È stato sostituito con plymouth.

4.9.1. Pacchetti fittizi

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

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



[4] Se la priorità di debconf è impostata ad un valore molto alto potrebbe bloccare i prompt di configurazione quindi i servizi che si basano su risposte predefinite che non sono appropriate per il proprio sistema non partiranno.

[5] Per esempio i servizi DNS e DHCP, in modo particolare se non c'è ridondanza o failover. Nel caso del DHCP gli utenti finali potrebbero essere disconnessi dalla rete se il lease time è inferiore al tempo necessario per la conclusione dell'aggiornamento.

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

[7] 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 sostituisce il secondo.

[8] Esistono delle incompatibilità note tra il vecchio kernel e il nuovo udev. Se si riscontrano dei problemi dopo aver riavviato con il nuovo kernel è necessario retrocedere udev in modo da usare la versione precedente.

[9] Se si sta registrando l'aggiornamento come descritto in Sezione 4.4, «Aggiornare i pacchetti», si raccomanda di continuare ad usare script per registrare le fasi dell'aggiornamento successive al riavvio in modo da avere la registrazione dei risultati delle azioni descritte in Sezione 4.4.6, «Aggiornamento del sistema».

[10] Alcuni dispositivi, come quelli usati da crypt, RAID o LVM, hanno identificatori stabili non-UUID. In questi casi si dovrebbe usare il nome del dispositivo dato che è già non ambiguo e stabile.

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