Recuperare un upgrade Ubuntu 24.04-26.04 fallito

Ubuntu: l’aggiornamento è fallito a metà; identificare prima il sintomo

Un aggiornamento di release da Ubuntu 24.04 a 26.04 può lasciare il server in uno di quattro stati, ognuno dei quali richiede una correzione diversa. Il programma di aggiornamento potrebbe essere ancora in esecuzione all’interno di una sessione screen con cui hai perso il contatto. dpkg potrebbe essere stato terminato mentre un pacchetto era parzialmente configurato e ora apt rifiuta ogni comando. Le sorgenti di apt potrebbero indicare 26.04 mentre i pacchetti installati sono ancora quelli di 24.04. In alternativa, il server potrebbe non avviarsi affatto. Determina quale di questi casi si applica prima di eseguire qualsiasi comando, perché la correzione adatta a uno stato può peggiorarne un altro.

Una regola vale per tutti e quattro i casi. Non riavviare finché non sai in quale stato si trova dpkg. Un riavvio durante la sostituzione dei pacchetti può trasformare un’interruzione di dpkg risolvibile nel caso di mancato avvio descritto verso la fine di questa guida. Inoltre, non avviare un secondo processo apt o dpkg mentre il primo potrebbe essere ancora attivo, perché due processi che scrivono contemporaneamente nel database dei pacchetti possono danneggiarlo.

Questa guida presuppone che tu abbia seguito la guida all’aggiornamento da 24.04 a 26.04 e creato uno snapshot prima di iniziare. In caso contrario, leggi la sezione sull’avvio tenendo presente questo aspetto, perché lo snapshot è la soluzione per lo scenario peggiore.

L'aggiornamento è ancora in esecuzione?

Molti aggiornamenti segnalati come non riusciti sono ancora in esecuzione. La sessione SSH si è interrotta, il terminale è rimasto vuoto e il programma di aggiornamento ha continuato senza di te.

do-release-upgrade è progettato per gestire questo caso. Quando viene eseguito con la propria interfaccia testuale, come avviene su un server, si avvia all'interno di una sessione GNU screen. In questo modo l'aggiornamento continua anche se il terminale da cui è stato avviato viene disconnesso. Inoltre, quando rileva di essere stato avviato da una sessione SSH, propone di avviare una seconda istanza di sshd su un'altra porta (1022 per impostazione predefinita). Puoi così accedere al server anche se il demone SSH principale si interrompe durante la sostituzione dei pacchetti. Entrambi i meccanismi sono importanti in questo caso.

Riconnettiti tramite SSH e cerca la sessione screen. Il programma di aggiornamento è stato eseguito con sudo, quindi la sessione screen appartiene a root. Un semplice screen -ls eseguito con il tuo utente non la mostrerà.

sudo screen -ls

screen -ls indica se ogni sessione è collegata o scollegata. Se ne viene elencata una, ricollegati a quella sessione. Se risulta ancora collegata perché la connessione SSH interrotta non l'ha rilasciata, -d scollega prima quella connessione obsoleta.

sudo screen -d -r

Se sono elencate più sessioni, aggiungi a -r il nome della sessione indicato da screen -ls. Anche eseguire di nuovo sudo do-release-upgrade funziona: il programma di aggiornamento verifica l'esistenza della propria sessione screen e si ricollega a quella invece di avviare una nuova esecuzione. In entrambi i casi torni all'aggiornamento in corso, che di solito è in attesa di una risposta relativa a un file di configurazione modificato o al riavvio di un servizio. Rispondi e lascia che l'operazione termini.

Se hai avviato l'aggiornamento all'interno di tmux, come raccomandato dalla guida all'aggiornamento, ricollegati prima a tmux con tmux attach. La sessione screen è in esecuzione all'interno di quel pannello tmux, quindi vedrai direttamente l'aggiornamento. Se nel pannello compare soltanto un prompt della shell, il programma di aggiornamento non è più in esecuzione in quella sessione e sudo screen -ls è il controllo successivo.

Se la porta SSH principale rifiuta la connessione, prova la porta alternativa: ssh -p 1022 user@host. Questo demone esiste soltanto per la durata dell'aggiornamento. Se non riesci ad accedere su nessuna delle due porte, usa la console del provider. Dalla console, sudo ss -ltnp mostra su quali porte è in ascolto un processo sshd, mentre sudo ufw status indica se il firewall ha consentito il traffico sulla porta alternativa.

Quando non esiste alcuna sessione screen e la console non mostra nessuna operazione in attesa, l'aggiornamento si è effettivamente interrotto. Prima di intervenire, verifica che nessun processo stia ancora lavorando sul database dei pacchetti:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Un risultato vuoto indica che dpkg è inattivo e puoi procedere con la riparazione. Un processo dpkg o apt con un tempo di esecuzione elevato e senza una sessione screen a cui ricollegarsi è bloccato. Attendi alcuni minuti, controlla nella console se è presente una domanda di debconf senza risposta e solo dopo termina il processo. Non eliminare mai i file di lock in /var/lib/dpkg/ o /var/lib/apt/lists/ mentre un processo li mantiene aperti. Il lock è l'unico meccanismo che impedisce a due processi di scrivere contemporaneamente e danneggiare il database dei pacchetti.

dpkg è stato interrotto e apt rifiuta di funzionare

Quando dpkg viene terminato tra l'estrazione di un pacchetto e l'esecuzione del relativo script di configurazione, registra lo stato incompleto in /var/lib/dpkg/status. Ogni comando apt successivo legge questo stato e si interrompe, perché apt non può procedere usando un database con operazioni non completate. Qualunque sia il messaggio mostrato da apt quando rifiuta di procedere, il primo intervento è sempre lo stesso.

sudo dpkg --configure -a

Questo completa la configurazione di ogni pacchetto che è stato estratto ma non configurato. Esegue gli script del maintainer nell'ordine determinato dalle dipendenze. Su un sistema aggiornato solo parzialmente può richiedere molto tempo, quindi non interromperlo fino al termine. Se si interrompe su un pacchetto, mostra il nome del pacchetto e dello script che ha avuto esito negativo. Annotate quel nome. È il pacchetto che ha bloccato l'aggiornamento. La sezione successiva spiega come leggere il relativo errore.

Lasciate quindi che apt ripari le dipendenze rimaste non soddisfatte a causa dell'interruzione, perché alcuni pacchetti sono stati aggiornati mentre i pacchetti da cui dipendono non lo sono stati.

sudo apt --fix-broken install

Completate quindi l'aggiornamento che il programma di aggiornamento stava eseguendo:

sudo apt update
sudo apt full-upgrade

Usate full-upgrade invece di upgrade, perché un aggiornamento di release rimuove pacchetti, mentre upgrade semplice rifiuta di rimuovere qualsiasi elemento. Leggete il riepilogo mostrato da apt prima di confermare. Un breve elenco di rimozioni è normale. Un elenco che rimuove ubuntu-server, systemd, openssh-server o il pacchetto del kernel non è normale. Rispondete no e verificate perché apt vuole procedere in questo modo prima di continuare.

Controllate il risultato prima di eseguire qualsiasi altra operazione:

sudo dpkg --audit
sudo apt-get check

dpkg --audit elenca tutti i pacchetti ancora in stato non funzionante, mentre apt-get check segnala le dipendenze non soddisfatte. Entrambi i comandi dovrebbero non produrre alcun output. Quando è così, eseguite sudo apt autoremove per rimuovere i pacchetti 24.04 da cui non dipende più nulla. Confermate quindi la release con cat /etc/os-release, eseguite sudo update-initramfs -u -k all e sudo update-grub e solo dopo riavviate il sistema.

Come leggere /var/log/dist-upgrade per trovare il pacchetto che ha bloccato l'aggiornamento

Il programma di aggiornamento scrive tutto in /var/log/dist-upgrade/. Se lo avete eseguito più di una volta, sposta i log dei tentativi precedenti in una sottodirectory il cui nome contiene un timestamp. Controllate quindi prima ls -la /var/log/dist-upgrade/ e leggete la directory corrispondente all'esecuzione che non è andata a buon fine.

main.log è il diario del programma di aggiornamento. Registra la fase in cui si trovava l'esecuzione e le decisioni prese sulle sorgenti dei pacchetti. Se il programma di aggiornamento è terminato in modo anomalo, qui è presente anche il traceback Python. Leggetelo dalla fine: le ultime righe indicano la fase in cui il processo si è interrotto. Un traceback in quella posizione indica un errore dello strumento, non di un pacchetto.

apt.log contiene il ragionamento del resolver delle dipendenze. È dettagliato e diventa importante quando apt rifiuta di calcolare completamente l'aggiornamento, cioè prima che venga modificato qualsiasi pacchetto. Se l'aggiornamento è arrivato all'installazione dei pacchetti, in genere potete ignorarlo.

apt-term.log è il file da consultare in caso di errore di un pacchetto. Cattura l'output del terminale prodotto da dpkg durante l'aggiornamento, cioè lo stesso testo che sarebbe scorso sullo schermo. L'ultimo pacchetto menzionato prima della fine è quello in fase di elaborazione quando l'aggiornamento si è interrotto. Se uno script del maintainer ha avuto esito negativo, qui trovate il relativo messaggio di errore di dpkg, seguito immediatamente dall'errore prodotto dallo script.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Confrontate il risultato con /var/log/dpkg.log, che registra con un timestamp ogni modifica di stato eseguita da dpkg. tail -n 30 /var/log/dpkg.log mostra l'ultimo pacchetto toccato da dpkg e l'operazione eseguita su di esso, fornendo la stessa risposta da una seconda fonte.

A questo punto, sulla maggior parte dei server, gli errori dipendono da poche cause ricorrenti. Un servizio che il pacchetto riavvia nel proprio postinst non si avvia perché avete personalizzato un file di configurazione. systemctl status insieme a journalctl -xeu, eseguiti sul servizio interessato, indicano la riga non accettata. Un disco può essere pieno, nella maggior parte dei casi /boot a causa dei vecchi kernel oppure /var a causa della cache dei pacchetti di apt. df -h / /boot /var mostra la situazione. sudo apt clean svuota la cache anche quando apt è altrimenti bloccato. Un disco che risulta pieno anche se du non lo indica ha una spiegazione specifica. Un pacchetto proveniente da un repository di terze parti disabilitato dal programma di aggiornamento può dipendere da una libreria che la release 26.04 non distribuisce più. Un pacchetto bloccato (apt-mark showhold) può impedire l'aggiornamento di una dipendenza. Correggete la causa, quindi eseguite di nuovo sudo dpkg --configure -a. Il comando riprende dal punto in cui si era interrotto.

Se un pacchetto rifiuta di essere configurato indipendentemente dalle operazioni eseguite e nessun componente importante dipende da esso, rimuovetelo e reinstallatelo dopo aver completato l'aggiornamento:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Usate questa procedura solo per un pacchetto che potete identificare e giustificare. Non applicatela a una libreria o a qualsiasi elemento nella catena di dipendenze ubuntu-server, perché la rimozione forzata salta i controlli che indicherebbero quali altri componenti smettono di funzionare.

Le sorgenti sono state aggiornate, ma i pacchetti no

L'aggiornamento riscrive le sorgenti apt nelle prime fasi, prima di scaricare i pacchetti. Se viene interrotto dopo questo passaggio, le sorgenti indicano 26.04, mentre i pacchetti installati sono misti. Questa situazione confonde gli strumenti ed è il motivo per cui do-release-upgrade potrebbe ora sostenere che non esiste una nuova release.

Confronta i due file che indicano quale release è installata. /etc/apt/sources.list.d/ubuntu.sources è il file delle sorgenti in formato deb822 introdotto con la 24.04 e le relative righe Suites: contengono il codename della release. /etc/os-release viene scritto dal pacchetto base-files e indica quale release è effettivamente installata.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Sono importanti tre combinazioni. Se le sorgenti indicano ancora la 24.04 (codename noble) e os-release indica ancora la 24.04, l'aggiornamento non ha superato i controlli iniziali. Dopo aver letto main.log per capire perché si è fermato, puoi eseguire di nuovo sudo do-release-upgrade. Se le sorgenti indicano il codename della 26.04, mentre os-release indica ancora la 24.04, la sostituzione dei pacchetti è iniziata ma è stata interrotta. La riparazione di dpkg descritta nella sezione precedente, che termina con apt full-upgrade, consente di completarla. Se le sorgenti indicano la 26.04 e os-release indica la 26.04, base-files è stato uno dei pacchetti installati correttamente. Il sistema ora si identifica come 26.04, anche se la maggior parte dei pacchetti appartiene ancora alla release precedente.

L'ultima combinazione è quella problematica. do-release-upgrade determina la release installata usando le stesse informazioni contenute in os-release. Se os-release indica già la 26.04, lo strumento cerca una release successiva alla 26.04. Non trovandola, segnala che non è disponibile alcuna nuova release. Lo strumento sta rispondendo a una domanda basata su os-release, ma os-release contiene un'informazione errata. Non eseguire più l'upgrader e completa l'aggiornamento con apt: esegui sudo apt update, quindi sudo apt full-upgrade, che aggiorna tutti i pacchetti ancora alla versione della 24.04, e infine sudo apt autoremove. Gli altri motivi per cui do-release-upgrade segnala che non è disponibile alcuna nuova release, ad esempio una richiesta di passaggio a una LTS che attende la prima point release, devono essere esclusi se os-release indica ancora la 24.04.

L'upgrader disabilita inoltre le sorgenti di terze parti in /etc/apt/sources.list.d/ e conserva una copia di backup di ogni file modificato, aggiungendo un suffisso al nome originale. Esegui ls -la /etc/apt/sources.list.d/ e diff su ogni file originale e sul relativo backup per vedere esattamente le modifiche apportate. Lascia disabilitate le voci di terze parti finché i pacchetti Ubuntu non sono coerenti. Riattivale singolarmente solo dopo aver verificato che il fornitore pubblichi pacchetti per la 26.04. Se apt update segnala che una sorgente è configurata più di una volta, una vecchia voce sources.list e la nuova voce ubuntu.sources descrivono la stessa suite. L'errore deb822 relativo a una sorgente duplicata spiega quale voce rimuovere.

Il server non si avvia dopo l'aggiornamento

Un riavvio evidenzia i problemi di un aggiornamento rimasto incompleto. Su un VPS, le cause probabili sono un kernel installato senza il relativo initramfs, una configurazione di GRUB mai rigenerata, un pacchetto lasciato in stato di configurazione incompleta da cui dipende un'unità all'avvio oppure un disco esaurito mentre dpkg stava scrivendo.

Apri la console del provider prima di fare qualsiasi altra operazione. Ti mostra il punto in cui l'avvio si arresta: il menu di GRUB, un kernel panic, un controllo del filesystem in attesa di una risposta oppure una shell di emergenza di systemd che richiede la password di root. Questa osservazione determina il passaggio successivo.

Se compare GRUB, avvia il kernel precedente 24.04 dal sottomenu delle opzioni avanzate. Il kernel precedente normalmente resta installato finché non viene eseguito autoremove. Dopo aver avviato il sistema con il kernel precedente, esegui sudo dpkg --configure -a e il resto della procedura di riparazione descritta nella sezione precedente, quindi sudo update-initramfs -u -k all e sudo update-grub prima di provare nuovamente il kernel nuovo. Ripristino di un VPS che non si avvia dopo un aggiornamento del kernel descrive in dettaglio la parte relativa a GRUB e initramfs.

Se arrivi a una shell di emergenza, il filesystem root è normalmente montato in sola lettura. Rimontalo ed esegui la stessa procedura di riparazione:

mount -o remount,rw /
dpkg --configure -a

Se il sistema non raggiunge neppure una shell, avvia l'immagine di ripristino del provider, monta il disco del VPS ed esegui la riparazione da un chroot. Individua la partizione root con lsblk invece di indovinarne il nome.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Prima di trascorrere un'ora in quel chroot, valuta il ripristino dello snapshot. Ne hai creato uno prima di iniziare e, con la maggior parte dei provider, il ripristino richiede pochi minuti. Poi esegui nuovamente l'aggiornamento, che su un VPS richiede ampiamente meno di un'ora; questa volta sai già quale pacchetto correggere. Il ripristino è la soluzione più rapida quando si verifica una di queste condizioni: non puoi accedere alla console o a un'immagine di ripristino, non riesci a identificare il pacchetto che ha interrotto l'aggiornamento, più di un pacchetto è bloccato oppure il server esegue un servizio atteso da altri utenti. La correzione manuale è più rapida solo quando sai esattamente che cosa si è guastato e la correzione consiste in un singolo comando.

Copia /var/log/dist-upgrade/ fuori dal server prima di eseguire il ripristino, usando l'immagine di ripristino se è l'unico modo per accedere al sistema. Il ripristino cancella quei log e un secondo tentativo fallirà nello stesso modo se non hai individuato la causa del primo problema. Che cosa può e non può ripristinare uno snapshot merita una lettura prima di fare affidamento su uno snapshot. Uno snapshot riporta indietro l'intero disco, compresi i dati scritti dopo la sua creazione. Questo va bene durante un aggiornamento, ma non una settimana più tardi.

Tre segnali che indicano la necessità di ricreare il sistema

Non tutti gli aggiornamenti possono essere recuperati. Ripristinare uno snapshot e ripetere l'operazione è semplice, ma se il problema dipende dallo stato del sistema stesso, anche il secondo tentativo fallirà. In questo caso, la soluzione corretta è usare una nuova immagine 26.04 e ripristinare i dati dal backup. Tre segnali indicano che si è arrivati a questo punto.

Il primo è il danneggiamento del database di dpkg. Se dpkg --audit o apt-get check non riesce neppure a leggere /var/lib/dpkg/status, invece di segnalare pacchetti danneggiati al suo interno, il record dei pacchetti installati è andato perso. Ubuntu conserva copie giornaliere in /var/backups/ (ls -la /var/backups/dpkg.status*), e sostituire il database con la copia più recente integra a volte risolve il problema. Tuttavia, se quella copia non corrisponde più a ciò che è realmente presente sul disco, si procede per tentativi e ogni successiva esecuzione di apt si basa su informazioni inaffidabili.

Il secondo è il malfunzionamento degli strumenti necessari per riparare il sistema. Se apt o dpkg non si avvia perché una libreria condivisa è stata rimossa o sostituita solo parzialmente, oppure systemd non riesce ad avviare le unità perché il relativo pacchetto è configurato solo in parte, non rimane alcun package manager funzionante per riparare il package manager. ldd /usr/bin/apt indica se tutte le librerie di apt sono presenti. A volte è possibile ripristinare il sistema da un chroot nell'immagine di soccorso, ma in genere questa procedura richiede più tempo di una nuova installazione.

Il terzo è che l'elenco dei pacchetti danneggiati non si riduce. Se si eseguono dpkg --configure -a e apt --fix-broken install in un ciclo per più di un'ora e ogni passaggio espone un nuovo pacchetto invece di risolvere il precedente, il sistema aveva già problemi che l'aggiornamento non ha creato: file in /usr modificati manualmente, pacchetti bloccati o mantenuti alla versione corrente, un repository di terze parti che ha sostituito librerie fondamentali oppure un aggiornamento precedente mai completato. Una nuova immagine non contiene questi problemi e ripristinarvi i dati richiede meno tempo che individuarli.

Ricreare il sistema è semplice solo se i dati si trovano in un'altra posizione. Questa è la differenza tra uno snapshot e un backup e il motivo per cui la guida all'aggiornamento richiede entrambi.

FAQ

Posso eseguire di nuovo do-release-upgrade dopo un'interruzione?

Sì, ed è il primo tentativo consigliato. Se l'upgrader è ancora attivo nella relativa sessione screen, eseguirlo di nuovo si ricollega a quella sessione. Se non lo è, esegui prima sudo dpkg --configure -a e sudo apt --fix-broken install, quindi avvia di nuovo l'upgrader. Rilegge lo stato corrente e continua l'aggiornamento. L'unico caso in cui non può essere utile si verifica quando /etc/os-release indica già 26.04, perché a quel punto considera concluso l'aggiornamento; completa invece la procedura con sudo apt full-upgrade.

Perché do-release-upgrade indica che non è disponibile una nuova release dopo un aggiornamento non riuscito?

Perché base-files, il pacchetto che scrive /etc/os-release, è stato aggiornato prima dell'interruzione. Ora lo strumento legge quel file, conclude che il sistema esegue 26.04 e non trova versioni più recenti da proporre. Confronta grep VERSION_ID /etc/os-release con grep Suites /etc/apt/sources.list.d/ubuntu.sources, quindi completa la procedura con sudo apt update && sudo apt full-upgrade.

È sicuro riavviare un server Ubuntu con un aggiornamento parzialmente completato?

Non finché sudo dpkg --audit non restituisce alcun risultato. Riavviare con un kernel estratto ma non configurato, oppure con GRUB non rigenerato, è il modo più comune per trasformare un aggiornamento risolvibile in dieci minuti in un intervento tramite immagine di ripristino. Completa la riparazione di dpkg e apt full-upgrade, esegui update-initramfs -u -k all e update-grub, quindi riavvia il server.

Come posso individuare il pacchetto che ha interrotto l'aggiornamento?

Leggi la parte finale di /var/log/dist-upgrade/apt-term.log, che contiene l'output terminale di dpkg. L'ultimo pacchetto indicato prima della fine del log è quello in fase di elaborazione; se uno script del manutentore ha avuto esito negativo, il relativo errore compare subito sopra il messaggio di errore di dpkg. tail -n 30 /var/log/dpkg.log lo conferma da una seconda fonte. Se invece main.log termina con un traceback Python, è andato in errore l'upgrader stesso e nessun pacchetto è responsabile.

Devo ripristinare lo snapshot o continuare a correggere il problema?

Ripristina lo snapshot se non riesci a identificare il pacchetto che ha avuto esito negativo, se più di un pacchetto è bloccato, se non hai accesso alla console o se il server deve tornare operativo rapidamente. Continua a correggere il problema solo quando sai esattamente che cosa si è guastato e la correzione richiede un solo comando. Copia /var/log/dist-upgrade/ fuori dal server prima del ripristino, altrimenti il secondo tentativo fallirà nello stesso modo.