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 prima. Ubuntu installa il nuovo kernel accanto a quello precedente e modifica soltanto la voce che GRUB avvia per impostazione predefinita. Perciò il primo intervento non consiste nella riparazione. Seleziona il kernel precedente nel menu di avvio, torna a un prompt di accesso, quindi 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 kernel panic. Anche SSH non risponderà, perché la macchina non ha raggiunto il punto 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 “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: fornisce testo reale che puoi scorrere e copiare, mentre una vista VNC mostra soltanto un'immagine dello schermo. Individua subito questo controllo, mentre la macchina è in buone condizioni, 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 ripristino o un'immagine di recovery. Avvia un sistema minimale dalla rete del provider e collega il disco come dispositivo aggiuntivo, quindi dal disco non viene eseguito nulla. La modalità di ripristino è la soluzione alternativa quando è danneggiato lo stesso GRUB. Serve anche per copiare i dati da un server che hai deciso di non recuperare.

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

Come si seleziona un kernel precedente nel menu di GRUB?

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

Quando viene visualizzato il menu, selezionare "Advanced options for Ubuntu". Il sottomenu elenca tutti i kernel installati, dal più recente al meno recente, con una voce recovery mode per ciascuno. Selezionare la seconda voce normale, cioè il kernel precedente al più recente, quindi premere Invio. La recovery mode è una modalità diversa: avvia un sistema minimo a utente singolo ed è destinata alle attività di riparazione, non al ripristino dei servizi.

Se il kernel precedente si avvia, il server torna operativo. Verificare quale kernel è in esecuzione e annotare i numeri di versione.

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. Cosa fare?

Le immagini cloud includono una configurazione che nasconde il menu. Le immagini Ubuntu impostano spesso il timeout su 0 in un file nella directory /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, all'avvio successivo, può lasciare il menu aperto finché qualcuno non preme un tasto. Su un server senza tastiera, l'attesa non termina mai. Se la console mostra un menu e non cambia nulla, è quello che è successo. Seleziona una voce e prosegui.

Correggi entrambi i problemi mentre la macchina funziona normalmente. 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"

Applica quindi la modifica e verifica che sia stata mantenuta, 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 fornito dal pannello. Gli argomenti del kernel console= producono lo stesso effetto per i messaggi di avvio successivi. Dieci secondi di ritardo per ogni avvio sono un costo contenuto per avere un menu realmente accessibile alle 2 di notte.

Quale classe di errore sto osservando?

Leggete le ultime venti righe prima che la console smetta di aggiornarsi. Dopo un aggiornamento del kernel, la maggior parte dei problemi rientra in quattro casi.

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 sbagliato, non a causa del solo pacchetto del kernel.

Il kernel si avvia ma non riesce a montare la root. I messaggi del kernel scorrono, poi viene visualizzata una shell busybox con prompt (initramfs), oppure l'avvio termina con un panic che segnala l'impossibilità di montare il filesystem root. Il kernel è stato caricato. L'initramfs, cioè la piccola root temporanea che individua e monta il filesystem root effettivo, 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 tale UUID e confrontatelo più avanti con l'output di blkid.

Un volume logico non viene mai rilevato. Questo è il caso precedente con una causa specifica. Al prompt (initramfs), eseguite ls /dev/mapper. Se l'unica voce è control, non è stato attivato alcun volume LVM (logical volume manager), 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 initramfs, che riprova a eseguire 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 visualizza testo del firmware, una shell UEFI (unified extensible firmware interface), uno schermo vuoto senza output del kernel oppure un ciclo continuo di riavvii. L'errore si verifica prima dell'avvio di Linux. Verificate quale modalità utilizza effettivamente il server quando il sistema è nuovamente operativo, 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 sui sistemi UEFI, perché i pacchetti che gestiscono la partizione di sistema EFI scrivono invece in una normale directory vuota. Il firmware continua ad avviare la vecchia voce di boot finché tale voce non corrisponde più al contenuto del disco.

Esiste anche un altro caso che non è un errore di boot. Se raggiungete una shell root che indica che il sistema è in emergency mode, il kernel è stato avviato ma il sistema userspace si è arrestato. Di solito la causa è una riga errata in /etc/fstab oppure un filesystem che non ha superato il controllo. Eseguite journalctl -xb nella shell e leggete il nome dell'unità che non è riuscita ad avviarsi.

Il pacchetto del kernel è danneggiato oppure lo è l'initramfs?

Dalla console, questi due problemi appaiono identici ma richiedono correzioni diverse. Avvia il vecchio kernel, 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. L'assenza dell'initrd, oppure una dimensione molto inferiore a quella degli altri file, indica che la generazione dell'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 durante le 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. Usa la stringa della versione mostrata dal tuo output di ls, perché il segnaposto seguente non indica 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 è il controllo finale. Un file di dimensioni normali indica che l'immagine è stata ricreata. Se invece è danneggiata l'immagine del kernel, 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

Riparare dalla modalità rescue quando nessun kernel si avvia

Se tutte le voci del menu non funzionano, avvia l'immagine rescue del provider e ripara il disco dall'esterno. Il disco viene visualizzato come dispositivo non montato, quindi al suo interno non è in esecuzione nulla 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

Testare un nuovo kernel senza compromettere il riavvio successivo

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

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

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 e, in alcuni layout, non lo è senza produrre errori visibili. La voce 0 è quella in cima al menu, cioè il kernel più recente. In questo caso i titoli sono più sicuri dei numeri, perché i numeri cambiano ogni volta che un kernel viene installato o rimosso.

Perché autoremove è rischioso su un server headless

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. Protegge il kernel in esecuzione e quelli più recenti. Il rischio dipende dal momento in cui esegui l’operazione. Se esegui sudo apt autoremove --purge subito dopo il riavvio con un kernel nuovo, l’elenco dei pacchetti protetti è già stato aggiornato. Il kernel precedente su cui facevi affidamento non è più protetto. Su una macchina con tastiera è un inconveniente. Su un server headless può fare la differenza tra selezionare una voce del menu e montare il disco da un’immagine di ripristino.

Mantieni almeno due kernel. Mantienine tre quando /boot dispone di spazio sufficiente. Rimuovi i kernel obsoleti indicando il nome dopo avere controllato uname -r. In questo modo 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, hai eseguito una pulizia. Se passa da due a uno, hai creato un’interruzione del servizio in attesa del prossimo riavvio.

Acquisisci uno snapshot prima dell'aggiornamento

Uno snapshot acquisito 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 e consente di riprovare l'aggiornamento con la console già aperta. Gli snapshot di una macchina in esecuzione sono coerenti con un arresto anomalo: acquisiscono il disco come se fosse stata interrotta l'alimentazione. Per questo, se il provider supporta gli snapshot offline, arresta prima il server. Uno snapshot non è un backup, perché di norma risiede sulla stessa infrastruttura del volume di cui è una copia. Capire la differenza tra gli snapshot VPS e i backup reali determina quale dei due può salvarti quando il problema è più grave di un kernel.

Questo è particolarmente importante durante un aggiornamento di release, perché kernel, strumenti initramfs, bootloader e configurazione di GRUB cambiano in un'unica operazione. Acquisisci lo snapshot immediatamente prima di iniziare un aggiornamento da Ubuntu 24.04 a 26.04, non la sera precedente, così il punto di ripristino corrisponde esattamente alla macchina che stai per modificare.

Come unattended-upgrades gestisce i pacchetti del kernel

unattended-upgrades di Ubuntu installa gli aggiornamenti di sicurezza senza chiedere conferma. I pacchetti del kernel arrivano dal security pocket come tutti gli altri pacchetti. Ne conseguono due aspetti.

Primo: il nuovo kernel viene installato, ma non è ancora in esecuzione. Un kernel diventa effettivo solo al boot. 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 viene riavviato 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

Secondo: 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 più ad avviarsi. La modifica che ha causato il problema di boot risale a tre mesi prima. Di conseguenza, nulla di ciò che hai fatto quel giorno spiega il problema. In /var/log/apt/history.log trovi l'esecuzione che ha installato il kernel con cui ora il sistema non riesce ad avviarsi.

Riavvia il sistema intenzionalmente, nel giorno che hai scelto, con la console già aperta. Questa semplice abitudine trasforma un'interruzione imprevista in una selezione di due minuti in un menu. Se vuoi usare l'automazione senza riavvii imprevisti, lascia attive le installazioni automatiche e disattiva i riavvii automatici. Per le impostazioni esatte, consulta come configurare unattended-upgrades su Ubuntu. Bloccare i pacchetti del kernel con sudo apt-mark hold linux-image-generic li impedisce completamente e blocca anche gli aggiornamenti di sicurezza del kernel. Consideralo quindi una scelta con un compromesso, non una misura di sicurezza.

FAQ

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

Apri la console del provider (VNC o seriale) e avvia un hard reset dal pannello di controllo, perché non puoi accedere al sistema per riavviarlo correttamente. 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 viene visualizzato il prompt di accesso, esegui uname -r per confermare quale kernel è in uso e dpkg -l 'linux-image-*' per vedere quali altri kernel sono installati. Esegui la diagnosi solo dopo che il sistema è tornato operativo.

Perché il mio VPS non visualizza affatto il menu di GRUB?

Le immagini cloud impostano spesso il timeout di GRUB su 0 in un file sotto /etc/default/grub.d/, quindi il kernel più recente viene avviato senza lasciare il tempo di premere un tasto. Imposta GRUB_TIMEOUT=10 e GRUB_TIMEOUT_STYLE=menu in /etc/default/grub, aggiungi GRUB_TERMINAL="console serial" 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 condizione di errore distinta, perché la generazione di initramfs fallisce e rimani con un kernel privo di un'immagine funzionante. Esegui la rimozione usando il nome esatto del pacchetto dopo aver controllato uname -r, così il kernel in esecuzione non viene mai selezionato. Evita un sudo apt autoremove --purge indiscriminato su una macchina senza accesso locale, 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 nessuna 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 differito: il kernel viene installato durante un'esecuzione automatica, compare /var/run/reboot-required e il problema si manifesta soltanto al successivo riavvio, anche dopo settimane. Esegui il riavvio deliberatamente con la console già aperta e leggi /var/log/apt/history.log per individuare quale esecuzione ha installato il kernel che stai avviando.