Indice
Prima di procedere all'aggiornamento si consiglia di leggere anche le informazioni contenute in Capitolo 5, Problemi di cui essere al corrente per bullseye, dove vengono trattati i potenziali problemi non direttamente collegati al processo di aggiornamento, ma che potrebbe essere comunque importante conoscere prima di iniziare.
Prima di aggiornare il proprio sistema si raccomanda di effettuare un salvataggio completo o quantomeno una copia di sicurezza di tutti quei dati e quelle informazioni di configurazione che non ci si può permettere di perdere. Gli strumenti e i processi di aggiornamento sono abbastanza affidabili, ma un problema dell'hardware durante l'aggiornamento potrebbe generare un sistema fortemente danneggiato.
Le cose principali che si potrebbe considerare di salvare sono i contenuti
di /etc
, /var/lib/dpkg
,
/var/lib/apt/extended_states
e l'output di
dpkg --get-selections "*"
(le virgolette sono
importanti). Se si usa aptitude per gestire i pacchetti,
si dovrebbe salvare anche /var/lib/aptitude/pkgstates
.
Il processo di aggiornamento in quanto tale non modifica nulla nelle
directory /home
, tuttavia alcune applicazioni (come ad
esempio alcune parti della suite Mozilla e gli ambienti desktop GNOME e KDE)
sovrascrivono le impostazioni dell'utente preesistenti con i nuovi valori
predefiniti quando un utente avvia per la prima volta la nuova versione
dell'applicazione. Per precauzione si potrebbe quindi voler fare una copia
di sicurezza dei file e delle directory nascosti («dotfile»,
cioè file i cui nomi iniziano con un punto) che si trovano nelle directory
«home» degli utenti. Tale copia potrebbe aiutare a ripristinare
o a ricreare le vecchie impostazioni. Potrebbe anche essere il caso di
informare gli utenti su questo argomento.
Tutte le installazioni di pacchetti devono essere eseguite con i privilegi
di superutente, per cui è necessario effettuare il login come utente
root
, oppure usare su o
sudo, per ottenere i diritti d'accesso necessari.
L'aggiornamento ha alcune condizioni preliminari; prima di eseguirlo si dovrebbe verificarle.
È saggio informare in anticipo tutti gli utenti di qualunque aggiornamento si stia pianificando, anche se gli utenti che accedono al sistema tramite una connessione ssh non dovrebbero notare granché durante l'aggiornamento e dovrebbero poter continuare a lavorare.
Se si desidera prendere delle precauzioni supplementari, si esegua un
salvataggio delle partizioni degli utenti (/home
) o le
si smonti prima di aggiornare il sistema.
Con l'aggiornamento a bullseye si dovrà anche fare un aggiornamento del kernel, per cui sarà necessario riavviare il sistema. Tipicamente ciò verrà fatto dopo che l'aggiornamento è terminato.
Tra i pacchetti interessati all'aggiornamento ce ne potrebbero essere alcuni a cui sono associati dei servizi. In questo caso, tali servizi saranno fermati mentre è in corso 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 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[1] per un periodo di tempo considerevole.
Se il sistema in fase di aggiornamento fornisce servizi critici per gli utenti o la rete[2], è 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 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.5, «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.
Sebbene Debian cerchi di garantire che il sistema rimanga sempre in uno stato avviabile, c'è sempre la possibilità che si abbiano problemi a riavviare il sistema dopo l'aggiornamento. I potenziali problemi che sono noti 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, 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.
Per il ripristino d'emergenza generalmente viene raccomandato di usare è la modalità di ripristino dell'installatore di Debian bullseye. Il vantaggio di usare l'installatore consiste nel fatto che è possibile scegliere fra i suoi numerosi metodi per trovare 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.
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 installazione live. 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.
Il pacchetto initramfs-tools
include
una shell di debug[3] 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.
Se l'avvio fallisce con systemd è possibile ottenere una shell root di debug
cambiando la riga di comando del kernel. Se l'avvio di base ha successo, ma
l'avvio di alcuni servizi fallisce, può essere utile aggiungere
systemd.unit=rescue.target
ai parametri del kernel.
Atrimenti il parametro systemd.unit=emergency.target
del
kernel fornirà una shell di root non appena possibile. Tuttavia ciò viene
fatto prima del montaggio del file system radice con permessi in lettura e
scrittura. Sarà necessario farlo manualmente con:
# mount -o remount,rw /
Ulteriori informazioni su come fare il debug di un avvio non funzionante con systemd possono essere trovate nell'articolo Diagnosing Boot Problems.
Importante | |
---|---|
Se si stanno usando alcuni servizi VPN (come |
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 temporaneamente.
Gli utenti del demone watchdog fornito nel pacchetto micro-evtd
dovrebbero fermare il demone e
disabilitare il timer di watchdog prima dell'aggiornamento, per evitare un
riavvio spurio nel bel mezzo del processo di aggiornamento:
# service micro-evtd stop # /usr/sbin/microapl -a system_set_watchdog off
Il processo di aggiornamento descritto in questo capitolo è stato progettato per sistemi Debian stable «puri». APT controlla ciò che è installato nel sistema. Se la propria configurazione di APT fa riferimento a fonti aggiuntive oltre a buster o se si sono installati pacchetti da altri rilasci o da terze parti, allora per assicurare un processo di aggiornamento affidabile si potrebbe voler iniziare rimuovendo tali fattori di complicazione.
Il file di configurazione principale che APT utilizza per decidere da quali
fonti scaricare i pacchetti è /etc/apt/sources.list
, ma
può anche utilizzare i file nella
directory/etc/apt/sources.list.d/
; per i dettagli
vedere sources.list(5).
Se il proprio sistema sta utilizzando più file source-list allora sarà
necessario assicurarsi che rimangano coerenti.
L'aggiornamento diretto da rilasci Debian più vecchi di 10 (buster) non sono supportati. Si può visualizzare la propria versione di Debian con:
$ cat /etc/debian_version
Seguire le istruzioni nelle Note di rilascio per Debian 10 per aggiornare prima a Debian 10.
Di seguito vengono indicati due metodi per trovare pacchetti installati che non provengono da Debian, usando aptitude o apt-forktracer. Notare che nessuno dei due è accurato al 100% (per esempio, quello con aptitude elenca i pacchetti che erano una volta forniti da Debian ma che non lo sono più, come i vecchi pacchetti del kernel).
$ aptitude search '?narrow(?installed, ?not(?origin(Debian)))' $ apt-forktracer | sort
Questa procedura presume che il proprio sistema sia stato aggiornato fino all'ultimo aggiornamento disponibile per buster. Se non è così o non si è sicuri, seguire le istruzioni contenute in Sezione A.1, «Aggiornare il proprio sistema buster».
Si dovrebbe controllare che il database dei pacchetti sia a posto prima di
procedere con l'aggiornamento. Se si usa un altro gestore di pacchetti come
aptitude
o synaptic
controllare ogni azione in sospeso. Un
pacchetto per cui è programmata l'installazione o la rimozione potrebbe
interferire con il processo di aggiornamento. Si noti che la correzione di
questa situazione è possibile solo se i propri file source-list per APT
puntano tuttora a buster e non a
stable o a bullseye. A tale
proposito vedere Sezione A.2, «Controllare i propri file source-list per APT».
È una buona idea rimuovere i pacchetti obsoleti dal proprio sistema prima dell'aggiornamento. Possono introdurre complicazioni durante il processo di aggiornamento e possono rappresentare rischi di sicurezza dato che non sono più mantenuti.
Un aggiornamento precedente può aver lasciato indietro copie inutilizzate dei file di configurazione: vecchie versioni di file di configurazione, versioni fornite dai manutentori dei pacchetti, ecc. La rimozione dei file lasciati da precedenti aggiornamenti può evitare confusioni. Trovare questi file rimasti indietro con:
# find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
Per le righe delle fonti di APT che si riferiscono all'archivio di sicurezza
il formato è stato leggermente cambiato insieme al nome del rilascio
passando da buster/updates
a
bullseye-security
; vedere Sezione 5.1.2, «Struttura dell'archivio di sicurezza modificata».
Se la sezione proposed-updates
è elencata nei propri file
source-list per APT, la si dovrebbe rimuovere prima di tentare
l'aggiornamento del sistema. Questa precauzione serve per ridurre il rischio
di conflitti.
Se si ha un qualsiasi pacchetto non-Debian nel proprio sistema, si presti attenzione al fatto che questi possono essere rimossi durante l'aggiornamento a causa di conflitti di dipendenze. Se questi pacchetti sono stati installati aggiungendo un archivio di pacchetti supplementare nei propri file source-list per APT, si dovrebbe controllare che tale archivio offra anche pacchetti compilati per bullseye e modificare di conseguenza la riga della fonte contemporaneamente alle righe delle fonti per i pacchetti Debian.
Alcuni utenti potrebbero avere installate nel proprio sistema buster versioni non ufficiali «più recenti» da backport di pacchetti che sono in Debian. Tali pacchetti sono i candidati più probabili a causare problemi durante un aggiornamento, in quanto potrebbero generare conflitti fra file[4]. Sezione 4.5, «Possibili problemi durante l'aggiornamento» contiene alcune informazioni su come gestire i conflitti tra file nel caso si verifichino.
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
e
/etc/apt/preferences.d/
) in modo da consentire
l'aggiornamento dei pacchetti alle versioni nel nuovo rilascio
stable. Maggiori informazioni sul pinning di APT sono disponibili in apt_preferences(5).
Si raccomanda di controllare dapprima lo stato di tutti i pacchetti e di verificare che tutti siano in uno stato aggiornabile, indipendentemente dal metodo usato per l'aggiornamento. Il comando seguente mostrerà tutti i pacchetti con uno stato «Half-Installed» o «Failed-Config» e quelli con un qualsiasi stato di errore.
# dpkg --audit
È anche possibile controllare lo stato di tutti i pacchetti sul proprio sistema usando 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 e dselect. È possibile identificare i pacchetti bloccati per aptitude eseguendo
# aptitude search "~ahold"
Se si desidera controllare quali pacchetti erano bloccati per apt, 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 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 i propri file source-list per APT puntino sempre a buster come illustrato in Sezione A.2, «Controllare i propri file source-list per APT».
Prima di iniziare l'aggiornamento è necessario riconfigurare i file
source-list di APT (/etc/apt/sources.list
e i file in
/etc/apt/sources.list.d/
) per aggiungere fonti per
bullseye
e tipicamente per rimuovere le fonti per
buster
.
APT prenderà in considerazione tutti i pacchetti che possono essere trovati tramite qualsiasi archivio configurato e installerà il pacchetto con il numero di versione più alto, dando la priorità alle righe menzionate per prime. Perciò, nel caso in cui siano presenti più posizioni di mirror, elencare per prime quelle sull'hard disc locale, poi i CD-ROM e infine i mirror remoti.
Si fa spesso riferimento a un rilascio sia tramite il suo nome in codice (ad
esempio buster
,
bullseye
), 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.
Debian fornisce due mailing-list per gli annunci che aiutano a rimanere aggiornati sulle informazioni importanti relative ai rilasci di Debian:
Iscrivendosi alla
mailing-list degli annunci Debian si riceverà una notifica ogni
volta che Debian fa un nuovo rilascio, ad esempio come quando
bullseye
passa da testing
a
stable
.
Iscrivendosi alla mailing-list degli annunci di sicurezza di Debian si riceverà una notifica ogni volta che Debian pubblica un annuncio di sicurezza.
Nelle nuove installazioni APT viene impostato in modo predefinito per utilizzare il servizio APT CDN di Debian che dovrebbe assicurare che i pacchetti vengano automaticamente scaricati da un server vicino in termini di rete. Dato che questo è un servizio relativamente nuovo le installazioni più vecchie possono avere configurazioni che puntano ancora ad uno dei server Internet principali di Debian o uno dei mirror. Se ancora non lo si è fatto, è raccomandato passare all'utilizzo del servizio CDN nella propria configurazione di APT.
Per utilizzare il servizio CDN aggiungere una riga come quella seguente alla
propria configurazione delle fonti per APT (presupponendo di usare
main
e contrib
):
deb http://deb.debian.org/debian bullseye main contrib
Dopo aver aggiunto le nuove fonti, disabilitare le righe
«deb
» preesistenti ponendovi davanti un
simbolo cancelletto (#
).
Tuttavia se si hanno risultati migliori usando un mirror specifico che è vicino in termini di rete, tale opzione è ancora disponibile.
Gli indirizzi dei mirror di Debian sono reperibili in https://www.debian.org/distrib/ftplist (guardare la sezione «Elenco dei mirror Debian»).
Per esempio, si supponga che il proprio mirror Debian più vicino sia
http://mirrors.kernel.org
. Ispezionandolo con un browser web
si noterà che le directory principali sono organizzate nel modo seguente:
http://mirrors.kernel.org/debian/dists/bullseye/main/binary-armel/... http://mirrors.kernel.org/debian/dists/bullseye/contrib/binary-armel/...
Per configurare APT per l'utilizzo di un determinato mirror aggiungere una
riga come la seguente (ancora una volta presumendo di utilizzare
main
e contrib
):
deb http://mirrors.kernel.org/debian bullseye 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.
Di nuovo, dopo aver aggiunto le nuove fonti disabilitare le voci di archivio precedentemente esistenti.
Anziché usare mirror remoti dei pacchetti, si potrebbe voler modificare i file source-list di APT in modo da usare un mirror su un disco locale (eventualmente montato su NFS).
Per esempio, il proprio mirror dei pacchetti potrebbe essere in
/var/local/debian/
e avere le directory principali come
segue:
/var/local/debian/dists/bullseye/main/binary-armel/... /var/local/debian/dists/bullseye/contrib/binary-armel/...
Per poter utilizzare questo mirror con apt
, si aggiunga questa riga al proprio
sources.list
:
deb file:/var/local/debian bullseye 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, disabilitare le voci di archivio
preesistenti nei file source-list di APT, ponendovi davanti un simbolo
cancelletto (#
).
Se si vogliono utilizzare soltanto DVD (o CD o dischi
Blu-ray) si disabilitino, commentandole, le voci esistenti in tutti i file
source-list di APT ponendovi davanti un simbolo cancelletto
(#
).
Ci si accerti che in /etc/fstab
ci sia una riga che
abiliti la possibilità di montare la propria unità CD-ROM nel punto di
montaggio /media/cdrom
. Per esempio, se l'unità del
CD-ROM è /dev/sr0
, /etc/fstab
dovrebbe contenere una riga come la seguente:
/dev/sr0 /media/cdrom auto noauto,ro 0 0
Si noti che non ci devono essere spazi fra le parole
noauto,ro
nel quarto campo.
Per verificare il funzionamento, inserire un CD e provare a eseguire
# mount /media/cdrom # questo monta il CD nel punto di montaggio # ls -alF /media/cdrom # questo dovrebbe mostrare la directory radice del CD # umount /media/cdrom # questo smonta 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.
Il modo raccomandato per aggiornare da rilasci di Debian precedenti è quello di usare lo strumento do gestione dei pacchetti apt.
Nota | |
---|---|
apt è pensato per l'uso interattivo e non dovrebbe essere utilizzato in script. Negli script si dovrebbe usare apt-get che ha un output stabile più adatto per l'analisi semantica. |
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 (in /etc/apt/sources.list
e nei file in
/etc/apt/sources.list.d/
) facciano riferimento a
«bullseye
» o a
«stable
». Non ci dovrebbero essere voci per
fonti che puntano a buster.
Nota | |
---|---|
Qualche volta le righe delle fonti per un CD-ROM potrebbero fare riferimento
a « |
È 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-bullseyefase
.time -a ~/upgrade-bullseyefase
.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 fase
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-bullseye.script
per visualizzare il file.
Dopo aver completato l'aggiornamento si può arrestare
script, digitando exit
al prompt.
apt mantiene anche un registro ("log") in
/var/log/apt/history.log
dei cambiamenti di stato dei
pacchetti e dell'output del terminale in
/var/log/apt/term.log
. dpkg, in
aggiunta, registra tutti i cambiamenti di stato dei pacchetti in
/var/log/dpkg.log
. Se si usa
aptitude, anch'esso registra cambiamenti di stato in
/var/log/aptitude
.
Se si è utilizzato il parametro -t per script, si può utilizzare il programma scriptreplay per replicare l'intera sessione:
# scriptreplay ~/upgrade-bullseyefase
.time ~/upgrade-bullseyefase
.script
Anzitutto deve essere recuperata la lista dei pacchetti disponibili per la nuova versione. Lo si fa eseguendo:
# apt update
Nota | |
---|---|
Gli utenti di apt-secure possono incontrare problemi quando usano aptitude o apt-get. Per apt-get si può utilizzare apt-get update --allow-releaseinfo-change. |
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.5, «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 è difficile effettuare un ripristino.
apt può mostrare informazioni dettagliate sullo spazio su disco necessario per l'installazione. È possibile visualizzare questa stima prima di eseguire effettivamente l'aggiornamento, eseguendo:
# apt -o APT::Get::Trivial-Only=true full-upgrade [ ... ] XXX aggiornati, XXX installati, XXX da rimuovere e XXX non aggiornati. È necessario scaricare xx.xMB di archivi. Dopo quest'operazione, verranno occupati AAAMB di spazio su disco.
Nota | |
---|---|
L'esecuzione di questo comando all'inizio del processo di aggiornamento potrebbe restituire un errore, per le ragioni descritte nelle sezioni seguenti. In tal caso sarà necessario attendere finché non sarà stato eseguito l'aggiornamento minimo del sistema come descritto in Sezione 4.4.4, «Aggiornamento minimo del sistema» prima di eseguire il comando per avere una stima dello spazio necessario su disco. |
Se lo spazio disponibile è insufficiente per l'aggiornamento, apt 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
). Pulire la
cache dei pacchetti eseguendo apt clean rimuoverà tutti i
file dei pacchetti scaricati in precedenza.
Rimuovere i pacchetti dimenticati. Se si è usato aptitude o apt per installare manualmente dei pacchetti in buster, 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. Non marcheranno per la rimozione i pacchetti che sono stati installati manualmente dall'utente. Per rimuovere i pacchetti installati automaticamente che non sono più usati, eseguire:
# apt autoremove
Si può anche utilizzare deborphan, debfoster o cruft per trovare i pacchetti ridondanti. 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.
Rimuovere i pacchetti che occupano molto spazio sul disco e non sono al
momento necessari (possono sempre essere reinstallati dopo
l'aggiornamento). Se si ha popularity-contest
installato, si può usare
popcon-largest-unused per elencare i pacchetti che non si
usano e che occupano più spazio. I pacchetti che occupano più spazio possono
essere trovati con dpigs (disponibile nel pacchetto
debian-goodies
) oppure con
wajig (eseguendo wajig size
). Possono
anche essere trovati con aptitude
. Avviare aptitude in
modalità a tutto terminale, selezionare
→ , premere l e inserire
~i
, premere S e inserire
~installsize
, a quel punto si dovrebbe ottenere un
bell'elenco con cui lavorare.
Eliminare 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 | |
---|---|
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
:
si rimuovano i pacchetti precedentemente scaricati per l'installazione:
# apt clean
si copi la directory /var/cache/apt/archives
nella
periferica USB:
# cp -ax /var/cache/apt/archives /media/usbkey/
si monti la directory della cache temporanea su quella attuale:
# mount --bind /media/usbkey/archives /var/cache/apt/archives
dopo l'aggiornamento, si ripristini la directory
/var/cache/apt/archives
originale:
# umount /var/cache/apt/archives
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 i propri file source-list di APT a buster, come descritto in Sezione A.2, «Controllare i propri file source-list per APT».
Importante | |
---|---|
Se si sta aggiornando da remoto, fare attenzione a Sezione 5.1.22, «Nessuna nuova connessione SSH possibile durante l'aggiornamento». |
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.5, «Aggiornamento del sistema».
Per farlo eseguire:
# apt upgrade --without-new-pkgs
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.
Se è installato il pacchetto apt-listchanges
, esso mostrerà (con la sua
configurazione predefinita) all'interno di un paginatore informazioni
importanti sui pacchetti aggiornati dopo lo scaricamento dei
pacchetti. Premere q dopo averle lette, per uscire dal
paginatore e continuare l'aggiornamento.
Una volta completati i passaggi descritti in precedenza, si è pronti per continuare con la parte principale dell'aggiornamento. Si esegua:
# apt full-upgrade
Questo comando eseguirà un aggiornamento completo del sistema, installando le versioni più recenti disponibili di tutti i pacchetti e risolvendo 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/DVD/BD, probabilmente verrà chiesto di inserire uno specifico disco in diversi momenti dell'aggiornamento. Potrebbe capitare di dover inserire più volte lo stesso disco: ciò è dovuto a pacchetti correlati tra loro che sono stati distribuiti su diversi dischi.
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»). Ciò può essere risolto o
utilizzando aptitude, per designare tali pacchetti per
l'installazione, o provando con apt install
.
pacchetto
Nelle prossime sezioni sono descritti i problemi noti che potrebbero verificarsi durante l'aggiornamento a bullseye.
In alcuni casi il passo apt full-upgrade può fallire dopo aver scaricato i pacchetti, con l'errore:
E: Impossibile eseguire immediatamente la configurazione su "pacchetto
". Per i dettagli vedere APT::Immediate-Configure in man 5 apt.conf.
Se ciò si verifica, l'esecuzione invece di apt full-upgrade -o APT::Immediate-Configure=0 dovrebbe permettere all'aggiornamento di continuare.
Un altro possibile modo di aggirare questo problema è di aggiungere entrambe le fonti buster e bullseye ai propri file source-list di APT ed eseguire apt update.
Il processo d'aggiornamento a bullseye 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. Per maggiori informazioni sui pacchetti obsoleti in bullseye vedere Sezione 4.8, «Pacchetti obsoleti».
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 emette un avviso e cessa l'aggiornamento. Si può
evitare questa situazione specificando l'opzione -o
APT::Force-LoopBreak=1
nella riga di comando di
apt.
È possibile che la struttura di dipendenze di un sistema sia talmente compromessa da richiedere un intervento manuale; ciò normalmente significa l'uso di apt o di
# dpkg --remove nome_pacchetto
per eliminare alcuni dei pacchetti che generano il problema, o
# apt -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 buster «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 descritti in precedenza.
Durante l'aggiornamento verranno poste domande riguardanti la configurazione
o la riconfigurazione di parecchi pacchetti. Quando viene chiesto se un
qualsiasi file nella directory /etc/init.d
o il file
/etc/manpath.config
deve essere sostituito con quello
fornito dal manutentore del pacchetto, di solito è necessario rispondere
affermativamente, per garantire la coerenza del sistema. Si può sempre
ritornare alle versioni precedenti, dal momento che queste verranno salvate
con l'estensione .dpkg-old
.
Se non si è sicuri sul da farsi, ci si annoti il nome del pacchetto o del file e si sistemino le cose in un momento successivo. Le informazioni presentate sullo schermo durante l'aggiornamento possono essere riesaminate dopo essere state cercate nel file generato durante l'aggiornamento.
Quando si usa la console locale del sistema per fare l'aggiornamento, potrebbe accadere che durante l'aggiornamento la console sia spostata su una vista diversa e che si perda la visibilità del processo d'aggiornamento. Questo può accadere, per esempio, sui sistemi con un'interfaccia grafica quando viene riavviato il display manager.
Per recuperare la console su cui era in corso l'aggiornamento, usare Ctrl+Alt+F1, se si è nella schermata di avvio grafico, oppure usare Alt+F1 se si è in una console testuale locale, per tornare al terminale virtuale 1. 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.
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.
Quando si effettua il full-upgrade da buster a bullseye è fortemente raccomandata, se non è ancora stata fatta, l'installazione di un metapacchetto linux-image-*. Questi metapacchetti richiamano automaticamente una nuova versione del kernel durante gli aggiornamenti. si può verificare se ne è installato uno eseguendo:
# dpkg -l "linux-image*" | grep ^ii | grep -i meta
Se non si vede alcun output, si dovrà installare manualmente un nuovo pacchetto linux-image oppure installare un metapacchetto linux-image. Per vedere un elenco dei metapacchetti linux-image disponibili eseguire:
# apt-cache search linux-image- | grep -i meta | 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 «4.9.0-8-amd64
» è raccomandata
l'installazione di linux-image-amd64
. Si può anche utilizzare
apt per vedere una lunga descrizione di ciascun pacchetto
che aiuti a scegliere il migliore disponibile. Ad esempio:
# apt show linux-image-amd64
Si dovrebbe quindi utilizzare apt install
per
installarlo. Una volta che questo nuovo kernel è installato si dovrebbe
riavviare alla prossima opportunità disponibile per poter godere dei
benefici offerti dalla nuova versione del kernel. Tuttavia guardare Sezione 5.1.24, «Cose da fare dopo l'aggiornamento prima di riavviare» prima di effettuare il primo riavvio dopo
l'aggiornamento.
Per i più avventurosi esiste un modo agevole per compilare il proprio kernel
personalizzato su Debian. Si installino i sorgenti del kernel forniti nel
pacchetto linux-source
. Per
compilare un pacchetto binario si può usare il target
deb-pkg
disponibile nel makefile dei sorgenti. Ulteriori
informazioni possono essere trovate nel Debian Linux
Kernel Handbook, che può a sua volta essere trovato anche nel
pacchetto debian-kernel-handbook
.
Se possibile, è preferibile aggiornare il pacchetto del kernel separatamente
dall'aggiornamento full-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».
Dopo l'aggiornamento ci sono molte cose che si possono fare per prepararsi per il prossimo rilascio.
Si rimuovano i pacchetti ora obsoleti o ridondanti come descritto in Sezione 4.4.3, «Accertarsi di avere spazio disponibile a sufficienza per l'aggiornamento» e Sezione 4.8, «Pacchetti obsoleti». Si dovrebbe controllare quali file di configurazione questi usano e considerare l'eliminazione completa dei pacchetti per rimuovere i loro file di configurazione. Vedere anche Sezione 4.7.1, «Eliminare completamente i pacchetti rimossi».
È generalmente consigliabile eliminare completamenti i pacchetti rimossi. Questo è particolarmente vero se i pacchetti sono stati rimossi in aggiornamenti a rilasci precedenti (es. nell'aggiornamento a buster) o se sono stati forniti da produttori esterni. In particolare è noto che i vecchi script init.d possono causare problemi.
Attenzione | |
---|---|
L'eliminazione completa di un pacchetto in genere elimina anche i suoi file di log, perciò può essere desiderabile farne prima un backup. |
Il comando seguente mostra un elenco di tutti i pacchetti rimossi che potrebbero avere dei file di configurazione rimasti nel sistema:
# dpkg -l | awk '/^rc/ { print $2 }'
I pacchetti possono essere rimossi usando apt purge. Ipotizzando di volerli eliminare completamente tutti in una volta, si può usare il comando seguente:
# apt purge $(dpkg -l | awk '/^rc/ { print $2 }')
Se si usa aptitude
si possono anche
usare le seguenti alternative ai comandi precedenti:
# aptitude search '~c' # aptitude purge '~c'
bullseye introduce moltissimi nuovi pacchetti, ma nel contempo ritira e manca di alcuni vecchi pacchetti che erano presenti in buster. 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à solitamente il supporto di sicurezza per essi un anno dopo il rilascio di bullseye[5] e normalmente non fornirà altro supporto oltre a quello nel frattempo. È raccomandata la loro sostituzione con le alternative disponibili, se ve ne sono.
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 bullseye a causa di errori. In quest'ultimo caso, i pacchetti potrebbero continuare a essere presenti nella distribuzione «unstable».
Alcuni frontend per la gestione dei pacchetti forniscono modi semplici di trovare i pacchetti installati che non sono più disponibili da alcun repository noto. L'interfaccia utente testuale aptitude li elenca nella categoria «Pacchetti obsoleti e creati localmente» e possono essere elencati ed eliminati definitivamente dalla riga di comando usando:
# aptitude search '~o' # aptitude purge '~o'
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.
Per un elenco dei pacchetto obsoleti per Bullseye fare riferimento a Sezione 5.3.1, «Pacchetti obsoleti degni di nota».
Alcuni pacchetti da buster possono essere stati sostituiti in bullseye da pacchetti fittizi di transizione, che sono segnaposti vuoti progettati per semplificare gli aggiornamenti. Se, per esempio, un'applicazione che era precedentemente in un singolo pacchetto è stata suddivisa in diversi, può essere fornito un pacchetto di transizione con lo stesso nome del vecchio pacchetto e con le dipendenze appropriate per far sì che siano installati i nuovi. Dopo che ciò è avvenuto il pacchetto fittizio ridondante può essere rimosso senza problemi.
Le descrizioni dei pacchetti fittizi di transizione solitamente indicano il
loro scopo. Tuttavia non sono uniformi; in particolare alcuni pacchetti
«fittizi» sono progettati per rimanere installati allo scopo di
richiamare una suite software completa o per tracciare l'attuale versione
più recente di un certo programma. Si può anche trovare utile
deborphan con le opzioni
--guess-
(per esempio
*
--guess-dummy
) per identificare i pacchetti fittizi di
transizione nel proprio sistema.
[1] 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.
[2] 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.
[3] Questa funzionalità può essere disabilitata aggiungendo il parametro
panic=0
ai parametri di avvio del proprio sistema.
[4] 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.
[5] O per tutto il tempo in cui non uscirà un altro rilascio. Tipicamente solo due rilasci stabili sono supportati contemporaneamente.