Aggiornare Debian 11 a Debian 12: guida pratica -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 26/04/2026 Pubblicato il: 26/04/2026 11:00 Tempo di lettura: 9 min

Aggiornare da Debian 11 a Debian 12 non è un salto da fare “a sentimento”: è un cambio di release che tocca repository, pacchetti di base, kernel, librerie e spesso anche servizi esposti. Se il nodo è in produzione, il criterio corretto è semplice: prima osservi, poi prepari il rollback, poi esegui l’upgrade. La procedura sotto è pensata per sistemi server classici con accesso SSH, systemd e pacchetti gestiti da APT.

Il punto chiave non è solo arrivare a Debian 12, ma arrivarci con uno stato verificabile: repository coerenti, spazio disco sufficiente, configurazioni critiche salvate, servizi controllati dopo il reboot. Se qualcosa non torna, il problema va fermato prima di forzare il passaggio successivo.

Prima di toccare APT: stato del sistema e finestra di rischio

Parti dal presupposto che l’upgrade possa interrompere temporaneamente servizi come web, mail, database, VPN o agent di monitoraggio. Il blast radius dipende da quanti pacchetti di terze parti hai installato e da quanto il sistema è stato personalizzato. Su una macchina con stack standard il rischio è contenuto; su host con repository esterni, driver aggiuntivi o software vendor, il rischio sale rapidamente.

Verifica subito la situazione di base:

cat /etc/debian_version
cat /etc/os-release
uname -a
uptime
systemctl --failed

Ti aspetti di vedere Debian 11, nessun servizio in failed e un uptime coerente con la finestra di manutenzione che hai scelto. Se c’è già un servizio rotto prima dell’upgrade, non mischiare i problemi: sistemalo o quantomeno documentalo, altrimenti il post-check non avrà valore diagnostico.

Controlli preliminari che evitano i guai più comuni

Le cause di fallimento più frequenti durante il passaggio a Debian 12 non sono “misteriose”: spazio insufficiente, pacchetti tenuti in hold, repository misti, configurazioni locali non salvate, reboot rimandato troppo a lungo. Fai questi controlli prima di cambiare i repository.

Controlla spazio su disco e inode. Se /, /var o /boot sono stretti, l’upgrade può fermarsi a metà.
```
df -h
df -i
```
Come soglia pratica, tieni margine reale su / e /var; se /boot è quasi pieno, pulisci i kernel vecchi prima di procedere.
Verifica i pacchetti in hold, perché possono bloccare dipendenze essenziali.
```
apt-mark showhold
```
Se l’elenco non è vuoto, valuta ogni voce: l’hold ha senso solo se sai esattamente perché esiste.
Individua repository non Debian, perché sono il punto in cui si rompe la coerenza del sistema.
```
grep -R --line-number -E 'deb |deb-src ' /etc/apt/sources.list /etc/apt/sources.list.d/
```
Se trovi sorgenti esterne, annotale. Alcune avranno la build per Bookworm, altre no. È meglio disabilitare temporaneamente quelle non compatibili che trascinarsi dipendenze vecchie.
Salva le configurazioni locali critiche prima dell’upgrade.
```
mkdir -p /root/backup-debian11-$(date +%F)
cp -a /etc/apt /etc/ssh /etc/nginx /etc/apache2 /etc/php /etc/mysql /root/backup-debian11-$(date +%F)/ 2>/dev/null
```
Adatta i percorsi allo stack reale. L’obiettivo è poter confrontare i file dopo, non fare un backup “decorativo”.
Se gestisci servizi esposti, registra lo stato iniziale.
```
systemctl status nginx apache2 php8.1-fpm mariadb --no-pager
```
Non devi avere tutti questi servizi, ma devi sapere quali sono attivi prima del cambio.

Se il server è remoto e senza console out-of-band, considera anche il rischio di perdere l’accesso SSH durante il reboot. In quel caso, avere una console del provider o un canale di accesso alternativo non è un optional operativo.

Repo Debian 12: il passaggio corretto da bullseye a bookworm

Debian 12 usa bookworm. L’upgrade si fa aggiornando i riferimenti APT da bullseye a bookworm, poi facendo update e l’upgrade completo. Prima di modificare i file, fai una copia dei sorgenti APT, così il rollback è immediato.

cp -a /etc/apt/sources.list /etc/apt/sources.list.bullseye.bak 2>/dev/null
cp -a /etc/apt/sources.list.d /root/sources.list.d.bullseye.bak -r 2>/dev/null

Ora sostituisci bullseye con bookworm nei file principali. Se usi sources.list.d, controlla ogni file manualmente: non dare per scontato che tutti i repository di terze parti abbiano un branch compatibile.

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
grep -R --line-number 'bullseye' /etc/apt/sources.list.d/

Se il secondo comando restituisce righe, non ignorarle: quello è il punto in cui spesso restano repo vecchi che poi generano dipendenze impossibili da risolvere.

Sequenza di upgrade: prima aggiorni l’indice, poi il sistema base

La sequenza corretta non è negoziabile: prima apt update, poi upgrade graduale, poi upgrade completo. In mezzo, osserva eventuali conflitti di configurazione e non premere “invio” a caso sulle richieste di merge dei file.

Aggiorna l’indice pacchetti.
```
apt update
```
Atteso: nessun errore di release non trovata, nessun 404 sui repository ufficiali. Se vedi errori, il problema è nei sorgenti, non nel sistema operativo.
Esegui prima l’upgrade conservativo.
```
apt upgrade --without-new-pkgs
```
Questo riduce la probabilità di introdurre pacchetti nuovi in una fase in cui vuoi ancora capire se il sistema è coerente.
Completa l’upgrade con la risoluzione dipendenze.
```
apt full-upgrade
```
Qui APT può rimuovere o sostituire pacchetti. Leggi con attenzione il riepilogo: se tocca componenti che non ti aspettavi, fermati e verifica prima di confermare.
Se usi un kernel standard, verifica che il nuovo ramo sia stato installato correttamente.
```
dpkg -l 'linux-image*' | grep '^ii'
```
Su Debian 12 il kernel e i meta-pacchetti possono cambiare; il controllo serve a capire se il sistema avrà un kernel avviabile dopo reboot.

Durante l’upgrade compariranno file di configurazione con opzioni tipo “mantenere la versione locale” o “installare la versione del manutentore”. La regola pratica è questa: se il file è tuo o del tuo provider, fermati e confrontalo; se è un file standard e non hai modifiche, di norma puoi accettare la versione del pacchetto. Non c’è una scelta universale valida per tutto.

Pacchetti e servizi che meritano attenzione speciale

In un upgrade da Debian 11 a 12, alcuni componenti meritano controlli aggiuntivi perché cambiano spesso comportamento o versione: PHP, MariaDB/MySQL, OpenSSH, Nginx, Apache, Postfix, Redis, agent di monitoraggio, moduli kernel esterni. Non è un elenco teorico: sono i punti in cui una configurazione vecchia può continuare a funzionare solo “fino al primo riavvio”.

Per PHP, per esempio, un sistema può passare da una minor release all’altra e lasciare il web server con il socket sbagliato. Dopo l’upgrade, controlla la versione attiva e i servizi FPM:

php -v
systemctl list-units --type=service | grep -E 'php.*fpm'

Per il database, verifica che il servizio parta e che i log non mostrino errori di incompatibilità tra versione vecchia e nuova. Su MariaDB, ad esempio, il controllo base è semplice:

systemctl status mariadb --no-pager
journalctl -u mariadb -b --no-pager | tail -n 50

Per SSH, il rischio tipico non è la rottura del demone, ma una configurazione ereditata male o una chiave host rigenerata senza che il client se ne accorga. Prima e dopo l’upgrade, conserva una copia di /etc/ssh/sshd_config e verifica l’ascolto sulla porta prevista.

sshd -t
ss -tlnp | grep sshd

Riavvio controllato e verifica post-boot

Il reboot non è la fine dell’upgrade: è il momento in cui scopri se il sistema è realmente avviabile con il nuovo stack. Se lavori in remoto, tieni aperta la sessione e, se possibile, una console secondaria. Dopo il riavvio, controlla subito release, kernel e servizi critici.

reboot

Dopo il ritorno online, esegui questi controlli minimi:

cat /etc/os-release
uname -r
systemctl --failed
apt update

Atteso: Debian 12 nei file di release, kernel coerente con il nuovo ramo, nessun servizio in failed, nessun errore sui repository. Se apt update mostra ancora riferimenti a bullseye, hai lasciato dentro sorgenti vecchi da sistemare.

Per il controllo applicativo, non limitarti a “il server risponde”. Verifica ogni servizio esposto con un test reale: HTTP, TLS, login, query database, invio mail, job schedulati. Un esempio per il web stack è questo:

curl -I https://localhost
curl -sS https://localhost/healthz

Se hai un reverse proxy o una CDN davanti, controlla anche l’origin direttamente, altrimenti rischi di attribuire al sistema operativo un problema che sta nel layer esterno.

Problemi tipici dopo il cambio di release e come leggerli

Molti guasti post-upgrade si presentano con sintomi banali ma radici diverse. Una pagina bianca può essere PHP-FPM fermo, estensione mancante, permessi errati o socket non aggiornato. Un 502 può arrivare da Nginx ma avere origine nel backend. Un database che non parte può dipendere da spazio, permessi, crash recovery o parametri non più validi.

Servizio in failed: usa systemctl status e journalctl -u per la causa reale, non per il sintomo.
```
journalctl -xeu nginx
journalctl -xeu php8.2-fpm
```
APT non pulito: se apt update fallisce, il sistema non è ancora in uno stato amministrabile.
```
apt update -o Debug::Acquire::http=true
```
Non serve sempre il debug, ma è utile quando vuoi capire quale repository sta rispondendo male.
Pacchetti rimossi in modo inatteso: confronta l’elenco dei pacchetti installati prima e dopo se hai fatto un inventario iniziale.
```
dpkg -l | awk '/^ii/{print $2}' > /root/packages-debian12.txt
```
Se hai il file salvato prima, puoi fare diff e vedere cosa è cambiato davvero.

Rollback realistico: cosa puoi fare e cosa no

Il rollback di un major upgrade Debian non è “torno indietro con un comando”. In pratica hai tre opzioni: ripristino da snapshot, restore di una VM/volume, oppure reinstallazione pulita con restore dei dati. Se hai snapshot del provider o del filesystem prima del cambio, quello è il rollback sensato.

Se non hai snapshot, il rollback operativo consiste nel ripristinare i repository precedenti e re-installare i pacchetti critici solo se il sistema è ancora coerente. Ma non considerarlo un piano affidabile per la produzione: è più una manovra di contenimento che un vero ritorno indietro.

cp -a /etc/apt/sources.list.bullseye.bak /etc/apt/sources.list
rm -f /etc/apt/sources.list.d/*.list

Attenzione: il comando sopra è solo un esempio di ripristino dei repository, non un rollback completo del sistema. Non tocca i dati applicativi né riporta indietro le versioni già migrate.

Checklist finale da tenere accanto alla console

Se vuoi ridurre gli errori operativi, usa una checklist breve e concreta. Non serve complicarla: serve che sia eseguibile in ordine.

Backup dei file critici in /etc e snapshot del sistema, se disponibile.
Controllo spazio, inode, hold, repository esterni e servizi già rotti.
Sostituzione di bullseye con bookworm nei sorgenti APT.
apt update senza errori.
apt upgrade --without-new-pkgs e poi apt full-upgrade.
Reboot controllato.
Verifica release, kernel, servizi, log e test applicativi.

Assunzione: il sistema è un server Debian 11 standard con accesso root o sudo, repository ufficiali e una finestra di manutenzione disponibile; se ci sono pacchetti vendor o storage particolare, i controlli preliminari vanno estesi prima di procedere.