VPS non si avvia dopo aggiornamento del kernel: cosa fare

Cosa fare per prima cosa quando un VPS non si avvia dopo un aggiornamento del kernel

Un VPS che non si avvia dopo un aggiornamento del kernel è generalmente recuperabile in pochi minuti, perché l'aggiornamento non ha eliminato il kernel che funzionava il giorno precedente. Ubuntu installa il nuovo kernel accanto a quello precedente e modifica soltanto la voce avviata per impostazione predefinita da GRUB. Quindi il primo intervento non consiste nel riparare il sistema. Seleziona il kernel precedente nel menu di avvio, ottieni nuovamente un prompt di login e poi esegui la diagnosi da un sistema in esecuzione.

La procedura su un server è diversa da quella su un laptop, perché non sono collegati né una tastiera né un monitor che mostri il panic. Anche SSH non risponderà, perché la macchina non ha mai raggiunto la fase in cui viene avviato sshd. Tutte le operazioni descritte di seguito vengono eseguite tramite la console del provider.

Leggi la console prima di modificare qualsiasi cosa. Il testo visualizzato determina la categoria del problema, e due server che entrambi "non si avviano" possono richiedere correzioni opposte.

Come raggiungere la console quando SSH non funziona?

Apri il pannello di controllo del provider e cerca una console. I nomi più comuni sono VNC console, web console, noVNC e serial console. Se sono disponibili entrambe, preferisci la serial console: mostra testo reale che puoi scorrere e copiare, mentre una vista VNC è soltanto un'immagine dello schermo. Individua subito questo controllo, quando la macchina funziona correttamente, e verifica che si apra. Cercarlo durante un'interruzione del servizio ti fa perdere la calma necessaria. Questa verifica rientra nei primi dieci minuti su un nuovo VPS, insieme alle regole del firewall e alle chiavi SSH.

La maggior parte dei pannelli offre anche una modalità di soccorso o un'immagine di ripristino. Avvia un sistema di dimensioni ridotte dalla rete del provider e collega il tuo disco come dispositivo aggiuntivo, quindi nessun componente del disco viene eseguito. La modalità di soccorso è il fallback quando è danneggiato lo stesso GRUB ed è anche il metodo per copiare i dati da un server che hai deciso di non recuperare.

Di solito devi eseguire un hard reset dal pannello per raggiungere il menu di avvio, perché non puoi eseguire sudo reboot su una macchina a cui non riesci ad accedere. Un hard reset equivale a interrompere l'alimentazione. I filesystem subiscono un arresto non ordinato, quindi al successivo avvio è previsto un controllo del filesystem.

Come scegliere un kernel meno recente nel menu GRUB?

Osservare la console dal momento in cui si preme il pulsante di reset. Premere ripetutamente Esc nei primi secondi oppure tenere premuto Shift su una macchina che si avvia in modalità BIOS legacy. La finestra temporale è breve e il visualizzatore della console spesso impiega un secondo per connettersi. Iniziare quindi a premere subito e continuare a farlo.

Quando viene visualizzato il menu, scegliere "Advanced options for Ubuntu". Il sottomenu elenca tutti i kernel installati, dal più recente al meno recente, con una voce recovery mode per ciascuno. Scegliere la seconda voce normale, cioè il kernel precedente a quello più recente, e premere Invio. La recovery mode è diversa: avvia un sistema minimo a utente singolo e serve per le attività di riparazione, non per riportare online i servizi.

Se il kernel meno recente si avvia, il server è di nuovo operativo. Verificare quale kernel è in uso e annotare i numeri.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

L'output di dpkg è l'elenco dei kernel installati. Se contiene una sola riga, non esiste alcun fallback. Questo è il primo problema da risolvere.

Il menu di GRUB non viene mai visualizzato. Come procedere?

Le immagini cloud includono una configurazione che nasconde il menu. Le immagini Ubuntu impostano spesso il timeout su 0 in un file sotto /etc/default/grub.d/, quindi il kernel più recente viene avviato immediatamente e non c'è nulla da premere.

Esiste anche il caso opposto: il menu viene visualizzato e resta in attesa, dando l'impressione che il sistema sia bloccato. GRUB registra un avvio non riuscito e, al successivo avvio, può mantenere aperto il menu finché qualcuno non preme un tasto. Su una macchina senza tastiera, l'attesa non termina mai. Se la console mostra un menu e non accade nulla, è quanto è successo. Seleziona una voce e prosegui.

Correggi entrambi i problemi mentre la macchina funziona correttamente. Modifica /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Quindi applica la modifica e verifica che sia rimasta effettiva, perché i file in /etc/default/grub.d/ vengono letti dopo /etc/default/grub e possono sovrascriverla.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" invia il menu alla console grafica e alla porta seriale, quindi il menu viene visualizzato nel visualizzatore reso disponibile dal pannello. Gli argomenti del kernel console= fanno lo stesso per i messaggi di avvio successivi. Dieci secondi di attesa per ogni avvio sono un costo contenuto per poter raggiungere effettivamente il menu alle 2 di notte.

Quale classe di errore sto osservando?

Leggete le ultime venti righe prima che la console smetta di aggiornarsi. Quattro schemi coprono la maggior parte dei problemi che si verificano dopo un aggiornamento del kernel.

GRUB non trova i propri file. Viene visualizzato un prompt grub rescue> oppure un errore relativo a una partizione o a un file inesistente, e non compare mai alcun messaggio del kernel. Il kernel non è ancora coinvolto. Questo problema si verifica dopo una modifica al disco o alle partizioni, oppure quando il bootloader è stato scritto sul dispositivo errato, non a causa del solo pacchetto del kernel.

Il kernel si avvia ma non riesce a montare il filesystem root. I messaggi del kernel scorrono, poi viene visualizzata una shell busybox con prompt (initramfs), oppure l'avvio termina con un kernel panic che segnala l'impossibilità di montare il filesystem root. Il kernel è stato caricato. L'initramfs, cioè il piccolo filesystem root temporaneo che individua e monta il filesystem root reale, non ha trovato il disco. Su Ubuntu questa shell è normalmente preceduta da un messaggio che indica l'interruzione dell'attesa del dispositivo root e specifica l'UUID cercato. Copiate quell'UUID e confrontatelo in seguito con l'output di blkid.

Un volume logico non viene mai visualizzato. Questa è la classe precedente con una causa specifica. Al prompt (initramfs), eseguite ls /dev/mapper. Se l'unica voce è control, nessun volume LVM (logical volume manager) è stato attivato, quindi il dispositivo root non esiste ancora. Attivate manualmente i gruppi di volumi:

lvm vgchange -ay
ls /dev/mapper
exit

exit restituisce il controllo allo script dell'initramfs, che ritenta il mount. Se il sistema si avvia, il nuovo initramfs non contiene i componenti LVM necessari. La correzione consiste nel ricreare quell'immagine, non nel modificare il kernel.

Nessun segnale da Linux. La console mostra testo del firmware, una shell UEFI (unified extensible firmware interface), una schermata vuota senza output del kernel oppure un ciclo di riavvii. L'errore si verifica prima dell'avvio di Linux. Quando il server sarà nuovamente operativo, controllate quale modalità utilizza effettivamente, perché molte istanze VPS si avviano in modalità BIOS legacy e non utilizzano mai il percorso EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Un /boot/efi non montato durante l'aggiornamento è una causa comune sulle macchine UEFI, perché i pacchetti che gestiscono la partizione di sistema EFI scrivono quindi in una normale directory vuota. Il firmware continua ad avviare la vecchia voce di boot finché quella voce non corrisponde più al contenuto del disco.

Esiste anche uno schema che non indica affatto un errore di avvio. Se raggiungete una shell root che segnala che il sistema è in modalità di emergenza, il kernel si è avviato e l'esecuzione in userspace si è interrotta. Di solito la causa è una riga errata in /etc/fstab oppure un filesystem che non ha superato il controllo. Eseguite journalctl -xb in quella shell e leggete il nome dell'unità che ha avuto esito negativo.

Il pacchetto del kernel è danneggiato oppure lo è initramfs?

Dalla console, i due problemi appaiono identici ma richiedono correzioni diverse. Avvia il kernel precedente, quindi confronta i file.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Per ogni versione installata devono essere presenti un vmlinuz- e un initrd.img- corrispondente, entrambi con una dimensione plausibile. Un initrd mancante, oppure molto più piccolo dei file delle altre versioni, indica che la generazione di initramfs non è riuscita. La causa più comune è un /boot pieno. Le prove sono nei log dei pacchetti:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log elenca anche esattamente quali pacchetti sono stati installati dalle ultime esecuzioni e quando. Questo chiarisce quali modifiche sono state applicate.

Se /boot è pieno, libera prima spazio. Ricrea quindi l'immagine per la versione necessaria e aggiorna il menu. Ricava la stringa della versione dall'output del tuo ls, perché il segnaposto riportato di seguito non identifica una release reale:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

L'ultimo ls consente di verificare il risultato. Un file di dimensioni normali indica che l'immagine è nuovamente presente. Se invece l'immagine del kernel è danneggiata, oppure dpkg -l mostra il pacchetto in uno stato diverso da ii, reinstalla il pacchetto:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Ripristino dalla modalità rescue quando nessun kernel si avvia

Se tutte le voci del menu non funzionano, avviate l'immagine rescue del provider e riparate il disco dall'esterno. Il disco viene visualizzato come dispositivo non montato, quindi su di esso non è in esecuzione alcun sistema e nessun processo può interferire con la riparazione.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Testa un nuovo kernel senza rischiare il prossimo avvio

GRUB può avviare una voce una sola volta e poi tornare al valore predefinito scelto. Imposta come predefinito un kernel di cui ti fidi, quindi avvia quello nuovo solo per un boot. Se non funziona, un hard reset dal pannello ti riporta al kernel funzionante, senza dover intervenire sulla console entro tempi precisi.

Imposta GRUB_DEFAULT=saved in /etc/default/grub, esegui sudo update-grub, quindi elenca i titoli delle voci per poter indicare uno di essi in modo esatto:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list dovrebbe stampare il titolo scelto come saved_entry. Questo output dimostra che il meccanismo funziona, perché il salvataggio richiede un /boot/grub/grubenv scrivibile, che in alcuni layout non lo è e il problema può verificarsi senza messaggi. La voce 0 è quella in cima al menu, cioè il kernel più recente. In questo caso i titoli sono più affidabili dei numeri, perché questi ultimi cambiano ogni volta che un kernel viene installato o rimosso.

Perché autoremove è rischioso su un server senza console

APT mantiene un elenco dei pacchetti del kernel che non deve rimuovere autonomamente. Leggi il tuo elenco:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Il file viene rigenerato ogni volta che cambiano i pacchetti del kernel e protegge il kernel in esecuzione e quelli installati più di recente. Il rischio dipende dalla tempistica. Esegui sudo apt autoremove --purge subito dopo il riavvio con un kernel nuovo: l'elenco dei pacchetti protetti è già avanzato e il kernel precedente su cui facevi affidamento non è più protetto. Su una macchina con tastiera è solo un inconveniente. Su un server senza console, invece, può costringerti a montare il disco da un'immagine di ripristino invece di selezionare una voce del menu.

Mantieni almeno due kernel e tre quando /boot dispone di spazio sufficiente. Rimuovi quelli meno recenti indicando il nome, dopo aver controllato uname -r, così non puoi eliminare il kernel in esecuzione:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Esegui di nuovo l'ultimo comando. Se il numero passa da tre a due, si tratta di una pulizia. Se passa a uno, si tratta di un'interruzione di servizio in attesa del prossimo riavvio.

Crea uno snapshot prima dell'upgrade

Uno snapshot creato prima di apt upgrade è l'unico percorso di ripristino che non dipende dall'avvio di alcun componente. Il ripristino riporta il disco allo stato in cui il kernel precedente era quello predefinito. Puoi quindi riprovare l'upgrade con la console già aperta. Gli snapshot di una macchina in esecuzione sono coerenti con un arresto anomalo. Questo significa che acquisiscono il disco come se fosse stata interrotta l'alimentazione. Arresta quindi il server prima di creare lo snapshot, quando il provider supporta uno snapshot offline. Uno snapshot non è un backup, perché in genere risiede sulla stessa infrastruttura del volume copiato. Capire la differenza tra gli snapshot VPS e i backup reali determina quale dei due può salvarti quando il problema supera quello del kernel.

Questo è particolarmente importante durante un upgrade di release, perché kernel, strumenti initramfs, bootloader e configurazione di GRUB cambiano nella stessa operazione. Crea lo snapshot immediatamente prima di iniziare un upgrade da Ubuntu 24.04 a 26.04, non la sera precedente, in modo che il punto di ripristino corrisponda alla macchina che stai per modificare. Se l'upgrade non è ancora stato proposto sul server, la causa è la pianificazione e non una configurazione non funzionante, perché il passaggio da una release LTS a un'altra diventa disponibile solo con la prima point release, 26.04.1.

Come unattended-upgrades gestisce i pacchetti del kernel

Ubuntu unattended-upgrades installa gli aggiornamenti di sicurezza senza richiedere conferma, e i pacchetti del kernel arrivano dal pocket di sicurezza come tutti gli altri pacchetti. Ne derivano due conseguenze.

Innanzitutto, il nuovo kernel viene installato ma non è in esecuzione. Un kernel diventa effettivo solo all'avvio. Viene creato il file /var/run/reboot-required e /var/run/reboot-required.pkgs indica quale componente ha richiesto il riavvio, ma il sistema non si riavvia se non hai abilitato Unattended-Upgrade::Automatic-Reboot in /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

In secondo luogo, questo intervallo può nascondere la causa del problema. Un server può installare un kernel a marzo e riavviarsi a giugno per un motivo completamente diverso, quindi non riuscire ad avviarsi. La modifica che ha impedito l'avvio risale a tre mesi prima, quindi nulla di ciò che hai fatto quel giorno spiega il problema. /var/log/apt/history.log è il punto in cui trovare l'esecuzione che ha installato il kernel con cui ora si verifica il problema di avvio.

Riavvia intenzionalmente, nel giorno che hai scelto, con la sessione della console già aperta. Questa semplice abitudine trasforma un'interruzione di servizio difficile da spiegare in una selezione di due minuti in un menu. Se vuoi mantenere l'automazione senza le sorprese, lascia attive le installazioni automatiche e disattiva i riavvii automatici; per le impostazioni esatte, consulta come configurare unattended-upgrades su Ubuntu. Il blocco dei pacchetti del kernel con sudo apt-mark hold linux-image-generic li arresta completamente e impedisce anche l'installazione delle correzioni di sicurezza del kernel. Consideralo quindi una scelta consapevole con una contropartita, non una misura di sicurezza.

FAQ

Come posso avviare un kernel precedente su una VPS senza tastiera?

Apri la console del provider (VNC o seriale) e attiva un hard reset dal pannello di controllo, perché non puoi accedere al sistema per eseguire un riavvio pulito. Quando la macchina si riavvia, premi ripetutamente Esc oppure tieni premuto Shift durante un avvio con BIOS legacy, per mantenere visualizzato il menu di GRUB. Scegli "Advanced options for Ubuntu" e seleziona la voce sotto il kernel più recente. Quando compare il prompt di accesso, esegui uname -r per confermare quale kernel è in esecuzione e dpkg -l 'linux-image-*' per vedere quali altri kernel sono installati. Esegui la diagnosi solo dopo che il sistema è tornato operativo.

Perché la mia VPS non mostra alcun menu di GRUB?

Le immagini cloud impostano spesso il timeout di GRUB su 0 in un file contenuto in /etc/default/grub.d/, quindi il kernel più recente viene avviato senza lasciare tempo per premere un tasto. Imposta GRUB_TIMEOUT=10 e GRUB_TIMEOUT_STYLE=menu in /etc/default/grub, aggiungi GRUB_TERMINAL="console serial" per fare in modo che il menu sia disponibile anche su una console seriale, quindi esegui sudo update-grub. Verifica con grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, perché i file presenti in quella directory vengono letti dopo il file principale e possono sovrascrivere la modifica.

Devo rimuovere i kernel precedenti per liberare spazio in /boot?

Rimuovi quelli più vecchi e mantienine almeno due. Un /boot pieno è una causa specifica di errore, perché in questo caso la generazione di initramfs non riesce e rimani con un kernel privo di un'immagine funzionante. Dopo aver verificato uname -r, rimuovi i pacchetti indicando il nome esatto, così il kernel in esecuzione non viene mai selezionato. Evita di eseguire sudo apt autoremove --purge indiscriminatamente su una macchina senza tastiera, perché l'elenco dei kernel protetti viene rigenerato a ogni modifica del kernel e un'esecuzione nel momento sbagliato può lasciarti con un solo kernel e senza una voce di fallback nel menu.

Gli aggiornamenti automatici possono impedire l'avvio?

Possono installare un kernel che in seguito non riesce ad avviarsi, ma non riavviano la macchina a meno che Unattended-Upgrade::Automatic-Reboot non sia impostato su true in /etc/apt/apt.conf.d/50unattended-upgrades. Lo schema tipico è un errore ritardato: il kernel viene installato durante un'esecuzione automatica, compare /var/run/reboot-required e il problema si manifesta solo al riavvio successivo, anche dopo settimane. Esegui il riavvio deliberatamente con la console già aperta e consulta /var/log/apt/history.log per individuare quale esecuzione ha installato il kernel che stai avviando.