Aggiornare Debian 9 Stretch a Debian 10 Buster da terminale -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 24/04/2026 Pubblicato il: 24/04/2026 22:59 Tempo di lettura: 11 min

Aggiornare Debian 9 Stretch a Debian 10 Buster da terminale è un cambio controllato, non un salto da fare a memoria. La parte delicata non è il comando finale, ma tutto quello che precede il riavvio: inventario dei pacchetti, stato dei repository, spazio disco, servizi critici e piano di ritorno. Se il sistema ospita web, mail, database o DNS, tratta l’operazione come manutenzione di produzione: prima osservi, poi modifichi, poi verifichi.

Il passaggio da Stretch a Buster è supportato, ma non è neutro. Cambiano versioni di librerie, kernel, toolchain e in molti casi anche il comportamento dei servizi. Nei sistemi reali il punto più fragile è quasi sempre un repository di terze parti rimasto fermo, un pacchetto trattenuto o un file di configurazione che non viene aggiornato come ci si aspetta. Per questo conviene procedere con una sequenza stabile: fotografia iniziale, backup minimo reversibile, aggiornamento di Stretch all’ultimo stato disponibile, modifica delle sorgenti APT, upgrade a Buster, verifica dei servizi.

Prima di toccare APT: stato atteso e rischio reale

Stato atteso: il sistema Debian 9 è raggiungibile via SSH, APT risolve correttamente i repository ufficiali, il disco ha margine sufficiente e i servizi principali sono in esecuzione. Stato osservato da cercare: repository non più firmati, errori di chiave, pacchetti in hold, spazio insufficiente in / o /var, servizi che falliscono al primo riavvio dopo l’upgrade.

Se mancano dati su ambiente e ruoli del server, non improvvisare. Un server applicativo con PHP-FPM e MariaDB richiede verifiche diverse da un host minimale con SSH e cron. La procedura sotto è pensata per una macchina Debian 9 standard, con accesso root o sudo e possibilità di aprire una seconda sessione SSH nel caso il primo terminale si chiuda durante il riavvio dei servizi.

Checklist tecnica prima dell’upgrade

Questa è la parte che evita i problemi più banali. Esegui i controlli nell’ordine, e salva l’output se il server è importante.

Verifica la release corrente e il kernel attivo:
```
cat /etc/debian_version
lsb_release -a 2>/dev/null || cat /etc/os-release
uname -a
```
Atteso: Debian 9.x e un kernel coerente con la macchina. Se il sistema non è realmente Stretch, fermati e riallinea la procedura alla release corretta.
Controlla spazio libero su filesystem critici:
```
df -h / /var /boot
```
Atteso: margine sufficiente per scaricare pacchetti e mantenere i file temporanei. Se /var è quasi pieno, è un rischio concreto perché APT e i log usano spesso quella partizione.
Identifica eventuali pacchetti trattenuti:
```
apt-mark showhold
```
Atteso: lista vuota o pacchetti conosciuti. Se trovi hold su librerie base, documenta il motivo prima di rimuoverlo.
Controlla i repository attivi:
```
grep -Rhv '^
*#' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
```
Atteso: repository ufficiali Debian 9 e, se presenti, sorgenti di terze parti note. Qualsiasi riga non riconosciuta va verificata prima dell’upgrade.
Prendi nota dei servizi critici:
```
systemctl list-units --type=service --state=running
```
Atteso: elenco dei demoni che non devono fermarsi a lungo. È la tua mappa per la verifica finale.

Se il server è remoto e non hai console out-of-band, apri una seconda sessione SSH prima di iniziare. Non è un dettaglio: se il demone SSH viene ricaricato o se il networking cambia, una sessione di riserva ti evita un accesso fisico o un intervento del provider.

Backup minimo reversibile prima di cambiare release

Qui non serve fare imaging completo del disco se il contesto non lo richiede, ma serve almeno un backup dei file di configurazione e una copia delle sorgenti APT. Il rollback di un major upgrade non è banale: se il server è critico, il vero piano di ritorno è una snapshot VM o un backup bare metal valido, non il semplice ripristino di due file.

Salva configurazioni e stato APT in una directory datata:

sudo mkdir -p /root/upgrade-stretch-buster-$(date +%F)
sudo cp -a /etc/apt /root/upgrade-stretch-buster-$(date +%F)/
sudo cp -a /etc/fstab /root/upgrade-stretch-buster-$(date +%F)/
sudo cp -a /etc/network /root/upgrade-stretch-buster-$(date +%F)/ 2>/dev/null || true

Atteso: copia locale consultabile rapidamente. Se usi NetworkManager o systemd-networkd, includi anche i rispettivi file di configurazione.

Esporta l’elenco pacchetti installati:

dpkg --get-selections > /root/upgrade-stretch-buster-$(date +%F)/dpkg-selections.txt
apt-mark showmanual > /root/upgrade-stretch-buster-$(date +%F)/apt-manual.txt

Atteso: inventario utile se devi ricostruire un host o confrontare comportamenti dopo l’upgrade.

Se hai una VM, crea snapshot o checkpoint dal layer di virtualizzazione prima di procedere. Se non è possibile, documenta esplicitamente che il rollback sarà solo logico e parziale.

Allinea Stretch all’ultimo stato prima del salto

Il passaggio di release funziona meglio se Stretch è già aggiornato completamente. Questo riduce il numero di delta e spesso evita conflitti inutili. Esegui prima l’update della release corrente, poi il cambio dei repository.

Aggiorna l’indice pacchetti:
```
sudo apt-get update
```
Atteso: niente errori di firma o repository irraggiungibili. Se compaiono errori su mirror non più validi, correggili prima di proseguire.
Installa gli aggiornamenti disponibili su Stretch:
```
sudo apt-get upgrade
```
Atteso: upgrade senza rimozioni massicce. Se APT propone rimozioni inattese, fermati e analizza il pacchetto che le causa.
Completa con l’upgrade dist:
```
sudo apt-get dist-upgrade
```
Atteso: Stretch allineato all’ultimo punto di rilascio. In questa fase possono aggiornarsi kernel e librerie.
Pulisci pacchetti obsoleti solo se hai già verificato che non servono:
```
sudo apt-get autoremove --purge
```
Atteso: rimozione di dipendenze non più necessarie. Se il server ospita software custom, controlla bene cosa sta per uscire.

Switch dei repository da Stretch a Buster

Il cuore dell’operazione è la sostituzione delle sorgenti APT. Qui conviene essere secchi e ordinati: fai backup del file, modifica solo le righe essenziali e lascia fuori i repository terzi finché non hai verificato il nuovo sistema base.

Su un sistema minimale, il file principale è quasi sempre /etc/apt/sources.list. Se usi file aggiuntivi in /etc/apt/sources.list.d/, tieni presente che alcuni repository esterni non supportano più Buster o richiedono chiavi aggiornate.

Fai una copia del file principale:
```
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
```
Atteso: backup immediato in caso di errore di editing.
Sostituisci Stretch con Buster nel file principale:
```
sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
```
Atteso: righe deb e deb-src puntate a Buster. Se il file contiene mirror personalizzati, verifica che il cambio sia coerente con il tuo ambiente.
Se hai repository terzi, disabilitali temporaneamente rinominando i file:
```
sudo mkdir -p /root/apt-disabled
sudo mv /etc/apt/sources.list.d/*.list /root/apt-disabled/ 2>/dev/null || true
```
Atteso: APT rimane limitato ai repository ufficiali durante il salto di release. È una misura conservativa, utile se non sai se il fornitore supporta Buster.
Aggiorna l’indice con i nuovi repository:
```
sudo apt-get update
```
Atteso: download dei metadati di Buster. Se ricevi errori di firma o pacchetti mancanti, il problema è quasi sempre nei mirror o nelle chiavi.

Upgrade a Buster da terminale

A questo punto fai il salto vero. Per ridurre sorprese, usa prima l’upgrade più prudente e poi quello completo. Il sistema potrebbe chiedere come gestire file di configurazione già modificati: in generale, su un host amministrato, conserva le versioni locali se sai che sono state personalizzate, ma confronta sempre il diff prima di decidere.

Avvia l’upgrade base:
```
sudo apt-get upgrade
```
Atteso: aggiornamento dei pacchetti già installati senza rimozioni invasive. Se APT segnala dipendenze irrisolvibili, non forzare: spesso serve il passaggio successivo.
Completa con l’upgrade distribuzione:
```
sudo apt-get dist-upgrade
```
Atteso: installazione dei nuovi pacchetti di Buster, rimozione di componenti obsoleti e allineamento delle dipendenze. È il punto in cui possono cambiare kernel, systemd, OpenSSL, PHP, Python o database client.
Se compare un prompt per i file di configurazione, confronta il contenuto invece di scegliere a caso. In caso di dubbio, conserva la versione locale solo se sai perché è stata modificata.
Se vuoi ridurre il rumore di pacchetti raccomandati, puoi usare un’installazione mirata per i componenti critici dopo il salto, non prima.

Durante l’upgrade osserva eventuali servizi fermati o riavviati. Su server applicativi, il comportamento più comune è un riavvio di Apache, Nginx, PHP-FPM, MariaDB o Redis al cambio di librerie. Non è un errore in sé, ma va tenuto sotto controllo se il sistema serve traffico.

Gestione dei file di configurazione e dei pacchetti in conflitto

La maggior parte dei problemi post-upgrade nasce qui. Debian tende a preservare la coerenza del sistema, ma se hai configurazioni locali non allineate ai default, APT può chiedere un intervento manuale. Il criterio pratico è semplice: se il servizio è standard e la personalizzazione è minima, parti dalla versione del maintainer; se il servizio è molto custom, conserva la tua config e fai diff riga per riga.

Per verificare cosa è cambiato, puoi usare strumenti di confronto sui file di configurazione salvati nel backup e quelli nuovi in /etc. Un esempio utile è controllare il demone SSH, la rete e i servizi web prima di riavviare tutto insieme.

Controlla i servizi falliti:
```
systemctl --failed
```
Atteso: zero unità in failed o, se presenti, una lista breve e spiegabile.
Leggi i log del boot corrente:
```
journalctl -p err -b
```
Atteso: assenza di errori critici nuovi. Se vedi errori ripetuti su un servizio specifico, intervieni prima di riavviare l’host in produzione.
Confronta i file di configurazione più sensibili con il backup fatto prima:
```
diff -u /root/upgrade-stretch-buster-$(date +%F)/sources.list /etc/apt/sources.list
```
Atteso: differenze attese e limitate. Per altri file, usa lo stesso schema di diff.

Riattivare i repository terzi solo dopo il base system

Una volta che il sistema base è su Buster e stabile, puoi valutare i repository esterni. Non farlo prima: molti problemi derivano da chiavi non aggiornate o pacchetti compilati per una release precedente. Reintroduci un repository alla volta, aggiornando e verificando subito dopo.

Ripristina un repository esterno per volta da /root/apt-disabled/ verso /etc/apt/sources.list.d/.
Esegui:
```
sudo apt-get update
```
Atteso: nessun errore di firma o release non supportata.
Se compare un errore GPG, verifica la chiave associata al repository e aggiornala con il metodo ufficiale del fornitore. Non incollare chiavi in chiaro in documenti operativi: salva solo l’origine e il comando di recupero.
Solo dopo il repo update, valuta un eventuale apt-get install dei pacchetti specifici del vendor.

Verifiche finali dopo il reboot

Il riavvio non è un atto formale: serve a validare kernel, init, rete e servizi persistenti. Dopo il reboot, controlla che il sistema risponda correttamente e che il livello di funzionalità sia quello atteso. Se il server espone servizi utenti, fai anche un test applicativo reale, non solo un ping.

Verifica la release effettiva:
```
cat /etc/debian_version
lsb_release -a 2>/dev/null || cat /etc/os-release
```
Atteso: Debian 10.x e identificazione coerente di Buster.
Controlla i servizi principali:
```
systemctl --failed
systemctl status ssh apache2 nginx php7.3-fpm mariadb --no-pager
```
Atteso: servizi attivi e senza failed. Adatta l’elenco ai demoni presenti sul tuo host.
Verifica rete e DNS locale se il server dipende da risoluzione esterna:
```
ip a
ip r
getent hosts deb.debian.org
```
Atteso: interfacce corrette, route valida e risoluzione funzionante.
Controlla i log dopo il boot:
```
journalctl -b -p warning
```
Atteso: solo warning noti o già accettati in precedenza.
Se l’host serve HTTP, esegui un controllo applicativo:
```
curl -I http://127.0.0.1/
curl -I https://tuo-dominio.example/
```
Atteso: risposta 200 o il codice previsto dal tuo stack. Un 5xx dopo l’upgrade segnala un problema applicativo o di configurazione del web server.

Rollback: cosa è realistico e cosa no

Il rollback completo da Buster a Stretch non è il piano normale. Se hai fatto snapshot, ripristina quella. Se non hai snapshot, puoi solo correggere alcuni errori di configurazione, reinstallare pacchetti specifici o riprendere da backup dei file. Tornare indietro a colpi di APT su una major release è una strada fragile e spesso più costosa di una reinstallazione pulita.

Per questo il vero rollback va deciso prima: snapshot VM, backup del sistema, accesso alla console e finestra di manutenzione. Se manca uno di questi elementi, l’upgrade è ancora possibile, ma il rischio operativo sale e va dichiarato esplicitamente.

Problemi tipici e lettura rapida del sintomo

Se APT si ferma su errori di repository, il problema è quasi sempre nella sorgente o nella chiave, non nel kernel. Se il server parte ma i servizi web non rispondono, cerca prima nei log di Apache, Nginx, PHP-FPM o del database. Se la macchina è lenta o instabile dopo l’upgrade, verifica memoria, OOM killer e spazio disco prima di inseguire ipotesi più complesse.

Un caso ricorrente è il pacchetto di terze parti che non supporta più la nuova release. In pratica il sistema base sale, ma un plugin, un agente o un modulo esterno blocca il resto. La soluzione più pulita è disabilitare temporaneamente quel repository, completare il base upgrade e poi decidere se esiste una versione compatibile o se il componente va sostituito.

Sequenza sintetica da usare in produzione

Fotografa stato, repository e servizi.
Fai backup minimo reversibile e, se possibile, snapshot.
Aggiorna Stretch all’ultimo livello disponibile.
Passa i repository da stretch a buster.
Esegui apt-get update, poi apt-get upgrade e apt-get dist-upgrade.
Riattiva i repository terzi uno alla volta.
Riavvia e verifica servizi, log e test applicativi.

Assunzione operativa: il server è un Debian 9 standard con accesso root o sudo, e l’obiettivo è arrivare a Debian 10 Buster mantenendo il più possibile la continuità dei servizi. Se il nodo è critico o include stack complessi con repository esterni pesanti, la finestra di manutenzione e lo snapshot prima del cambio non sono opzionali.