VPS no arranca tras actualizar el kernel: cómo recuperarlo

Qué hacer primero cuando un VPS no arranca después de una actualización del kernel

Un VPS que no arranca después de una actualización del kernel suele poder recuperarse en pocos minutos, porque la actualización no eliminó el kernel que funcionaba ayer. Ubuntu instala el kernel nuevo junto al anterior y sólo cambia la entrada que GRUB inicia de forma predeterminada. Por tanto, la primera medida no es reparar el sistema. Seleccione el kernel anterior en el menú de arranque, vuelva a obtener un indicador de inicio de sesión y diagnostique el problema desde un sistema en ejecución.

La forma de resolverlo en un servidor es distinta de la de un portátil, porque no hay ningún teclado conectado ni ningún monitor que muestre el panic. SSH tampoco responderá, porque la máquina nunca llegó al punto en el que se inicia sshd. Todo lo que se describe a continuación se realiza mediante la consola de su proveedor.

Lea primero la consola. El texto que aparece en esa pantalla determina la clase de fallo, y dos servidores que «no arrancan» pueden requerir correcciones opuestas.

¿Cómo accedo a la consola cuando SSH no funciona?

Abra el panel de control de su proveedor y busque una consola. Los nombres habituales son consola VNC, consola web, noVNC y consola serie. Si existen ambas opciones, prefiera la consola serie porque ofrece texto real que puede desplazar y copiar, mientras que una vista VNC sólo muestra una imagen de la pantalla. Localice este control ahora, mientras la máquina funciona correctamente, y confirme que se abre. Buscarlo durante una interrupción le quita la calma que necesita. Esta comprobación forma parte de los primeros diez minutos en un VPS nuevo, junto con las reglas del firewall y las claves SSH.

La mayoría de los paneles también ofrecen un modo de rescate o una imagen de recuperación. El proveedor arranca un sistema pequeño desde su red y conecta su disco como un dispositivo adicional, de modo que no se ejecuta nada de ese disco. El modo de rescate es la alternativa cuando el propio GRUB está dañado. También permite copiar datos desde un servidor que ha decidido no recuperar.

Normalmente necesitará hacer un reinicio forzado desde el panel para acceder al menú de arranque, porque no puede ejecutar sudo reboot en una máquina a la que no puede iniciar sesión. Un reinicio forzado equivale a cortar la alimentación. Los sistemas de archivos quedan en un estado de apagado incorrecto, así que espere una comprobación del sistema de archivos durante el siguiente arranque.

¿Cómo selecciono un kernel anterior en el menú de GRUB?

Observe la consola desde el momento en que pulse el botón de reinicio. Pulse Esc varias veces durante los primeros segundos o mantenga pulsada Shift en un equipo que arranque en modo BIOS heredado. La ventana de tiempo es breve y el visor de consola suele tardar un segundo en conectarse, por lo que debe empezar a pulsar pronto y continuar haciéndolo.

Cuando aparezca el menú, seleccione "Advanced options for Ubuntu". Ese submenú muestra todos los kernels instalados, del más reciente al más antiguo, con una entrada de modo de recuperación para cada uno. Seleccione la segunda entrada normal, que corresponde al kernel anterior al más reciente, y pulse Enter. El modo de recuperación es otra cosa: arranca un sistema de usuario único mínimo y sirve para reparar el sistema, no para volver a poner sus servicios en línea.

Si el kernel anterior arranca, ya vuelve a tener un servidor operativo. Confirme qué kernel está usando y anote los números.

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

La salida de dpkg es la lista de kernels instalados. Si sólo contiene una línea, no tiene ningún kernel alternativo. Esa es la primera cuestión que debe corregir.

El menú de GRUB nunca aparece. ¿Qué hago?

Las imágenes de nube incluyen una configuración que oculta el menú. Las imágenes de Ubuntu suelen establecer el tiempo de espera en 0 en un archivo de /etc/default/grub.d/, por lo que el kernel más reciente se inicia de inmediato y no hay nada que pulsar.

También puede ocurrir lo contrario: el menú aparece en pantalla y espera una entrada, lo que parece un bloqueo. GRUB registra un arranque fallido y, en el siguiente inicio, puede mantener el menú abierto hasta que alguien pulse una tecla. En un equipo sin teclado, esa espera nunca termina. Si la consola muestra un menú y nada cambia, eso es lo que ha ocurrido. Seleccione una entrada y continúe.

Corrija ambos casos mientras la máquina funcione correctamente. Edite /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"

A continuación, aplique el cambio y compruebe que se haya conservado, porque los archivos de /etc/default/grub.d/ se leen después de /etc/default/grub y pueden sobrescribirlo.

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

GRUB_TERMINAL="console serial" envía el menú a la consola gráfica y al puerto serie, por lo que aparece en el visor que proporcione su panel. Los argumentos del kernel console= hacen lo mismo con los mensajes de arranque posteriores. Diez segundos de espera en cada arranque es un precio bajo para disponer de un menú al que realmente pueda acceder a las 2 de la madrugada.

¿Qué clase de fallo estoy viendo?

Lea las últimas veinte líneas antes de que la consola deje de avanzar. Cuatro patrones cubren la mayoría de los problemas que aparecen después de actualizar el kernel.

GRUB no encuentra sus propios archivos. Aparece un indicador grub rescue>, o un error sobre una partición o un archivo que no existe, y no aparece ningún mensaje del kernel. El kernel todavía no interviene. Esto ocurre después de cambiar un disco o una partición, o de escribir el bootloader en el dispositivo equivocado, no por instalar únicamente un paquete del kernel.

El kernel se inicia, pero no puede montar el sistema de archivos raíz. Aparecen mensajes del kernel y después se accede a un shell de busybox cuyo indicador es (initramfs), o el arranque termina con un panic porque no se puede montar el sistema de archivos raíz. El kernel se cargó. El initramfs, que es el pequeño sistema de archivos raíz temporal que busca y monta el sistema de archivos raíz real, no encontró el disco. En Ubuntu, este shell normalmente aparece después de un mensaje que indica que se agotó el tiempo de espera del dispositivo raíz, junto con el UUID que esperaba encontrar. Copie ese UUID y compárelo más tarde con la salida de blkid.

Nunca aparece un volumen lógico. Esta es la clase anterior con una causa específica. En el indicador (initramfs), ejecute ls /dev/mapper. Si la única entrada es control, no se activó ningún volumen de LVM (gestor de volúmenes lógicos), por lo que el dispositivo raíz todavía no existe. Active manualmente los grupos de volúmenes:

lvm vgchange -ay
ls /dev/mapper
exit

exit devuelve el control al script de initramfs, que vuelve a intentar el montaje. Si el sistema arranca después, al nuevo initramfs le faltan los componentes de LVM. La reparación consiste en reconstruir esa imagen, no en modificar el kernel.

No aparece nada de Linux. La consola muestra texto del firmware, un shell UEFI (interfaz de firmware extensible unificada), una pantalla en blanco sin salida del kernel o un bucle de reinicios. El fallo ocurre antes de que se ejecute Linux. Compruebe qué modo usa realmente el servidor cuando vuelva a estar operativo, porque muchas instancias VPS arrancan en modo BIOS heredado y nunca utilizan la ruta EFI:

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

Que /boot/efi no esté montado durante la actualización es una causa habitual en máquinas UEFI, porque los paquetes que mantienen la partición del sistema EFI escriben entonces en un directorio vacío normal. El firmware sigue iniciando la entrada de arranque antigua hasta que esa entrada deja de coincidir con el contenido del disco.

Hay otro patrón que no es un fallo de arranque. Si llega a un shell de root que indica que el sistema está en modo de emergencia, el kernel se inició y el espacio de usuario se detuvo. Esto normalmente significa que hay una línea incorrecta en /etc/fstab o que un sistema de archivos no superó su comprobación. Ejecute journalctl -xb en ese shell y lea el nombre de la unidad que falló.

¿El paquete del kernel está dañado o lo está el initramfs?

Estos dos problemas se ven idénticos desde la consola y requieren reparaciones diferentes. Arranque con el kernel antiguo y compare los archivos.

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

Debe existir un vmlinuz- y un initrd.img- correspondiente para cada versión instalada, y cada archivo debe tener un tamaño razonable. Si falta un initrd o su tamaño es mucho menor que el de los archivos vecinos, significa que falló la generación del initramfs. La causa habitual es que /boot está lleno. Las pruebas están en los registros de paquetes:

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

history.log también muestra exactamente qué paquetes instalaron las últimas ejecuciones y cuándo lo hicieron. Esto resuelve cualquier duda sobre los cambios realizados.

Libere espacio primero si /boot está lleno. Después, reconstruya la imagen para la versión que necesita y actualice el menú. Obtenga la cadena de versión de la salida de su propio ls, porque el marcador siguiente no corresponde a una versión real:

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

Ese último ls es la comprobación. Un archivo de tamaño normal significa que la imagen ya está disponible. Si la propia imagen del kernel está dañada o dpkg -l muestra el paquete en un estado distinto de ii, vuelva a instalar el paquete:

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

Reparación desde el modo de rescate cuando no arranca ningún kernel

Si todas las entradas del menú fallan, arranque la imagen de rescate del proveedor y repare el disco desde fuera. El disco aparece como un dispositivo sin montar, por lo que nada de él está en ejecución ni puede interferir.

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

Probar un kernel nuevo sin poner en riesgo el siguiente arranque

GRUB puede iniciar una entrada una sola vez y después volver al valor predeterminado elegido. Establezca como predeterminado un kernel de confianza y, a continuación, inicie el nuevo sólo durante un arranque. Si falla, un reinicio forzado desde el panel le devuelve al kernel correcto sin tener que acertar con el momento de acceso a la consola.

Establezca GRUB_DEFAULT=saved en /etc/default/grub, ejecute sudo update-grub y, después, muestre los títulos de las entradas para poder indicar uno exactamente:

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 debe mostrar el título elegido como saved_entry. Esa salida demuestra que el mecanismo funciona, porque guardar el valor requiere un /boot/grub/grubenv con permisos de escritura y, en algunas disposiciones, no los tiene de forma silenciosa. La entrada 0 es la primera del menú, es decir, el kernel más reciente. Aquí los títulos son más seguros que los números, porque los números cambian cada vez que se instala o elimina un kernel.

Por qué autoremove es arriesgado en un equipo sin interfaz local

APT mantiene una lista de paquetes del kernel que no debe eliminar por su cuenta. Consulte la suya:

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

Ese archivo se regenera cada vez que cambian los paquetes del kernel. Protege el kernel en ejecución y los más recientes. El problema es el momento en que se ejecuta el comando. Si ejecuta sudo apt autoremove --purge justo después de reiniciar con un kernel nuevo, la lista de paquetes protegidos ya se habrá actualizado. Por tanto, el kernel anterior del que dependía dejará de estar protegido. En un equipo con teclado, esto es un inconveniente. En un servidor sin acceso local, es la diferencia entre seleccionar una entrada del menú y montar el disco desde una imagen de rescate.

Conserve siempre dos kernels como mínimo. Conserve tres cuando /boot tenga espacio suficiente. Elimine los antiguos por nombre después de comprobar uname -r. Así nunca podrá eliminar el kernel que está ejecutando:

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

Vuelva a ejecutar el último comando después de la limpieza. Si el recuento pasa de tres a dos, se trata de una limpieza normal. Si pasa a uno, habrá una interrupción del servicio en el próximo reinicio.

Tome una instantánea antes de la actualización

Una instantánea tomada antes de apt upgrade es la única vía de recuperación que no depende de arrancar ningún sistema. Restaurarla devuelve el disco al estado en el que el kernel antiguo era el predeterminado, y permite volver a intentar la actualización con la consola ya abierta. Las instantáneas de una máquina en ejecución son consistentes ante fallos, lo que significa que capturan el disco como si se hubiera cortado la alimentación. Por eso, apague primero el servidor cuando su proveedor admita una instantánea sin conexión. Una instantánea tampoco es una copia de seguridad, porque normalmente reside en la misma infraestructura que el volumen que copia. Entender la diferencia entre las instantáneas de VPS y las copias de seguridad reales determina cuál puede salvarle cuando el fallo es más grave que un kernel.

Esto es especialmente importante en una actualización de versión, en la que el kernel, las herramientas de initramfs, el gestor de arranque y la configuración de GRUB cambian en una sola ejecución. Tome la instantánea inmediatamente antes de iniciar una actualización de Ubuntu 24.04 a 26.04, no la noche anterior, para que el punto de restauración coincida con la máquina que está a punto de modificar. Si esa actualización todavía no se ha ofrecido en su servidor, la causa es la planificación y no una configuración dañada, porque el salto de una versión LTS a otra sólo se habilita en la primera versión de mantenimiento, 26.04.1.

Cómo trata unattended-upgrades los paquetes del kernel

unattended-upgrades de Ubuntu instala las actualizaciones de seguridad sin pedir confirmación. Los paquetes del kernel llegan a través del repositorio de seguridad, igual que los demás paquetes. De esto se derivan dos consecuencias.

Primero, el nuevo kernel se instala, pero no está en ejecución. Un kernel sólo entra en vigor durante el arranque. Aparece el archivo /var/run/reboot-required, y /var/run/reboot-required.pkgs indica qué solicitó el reinicio, pero nada se reinicia si no habilitó Unattended-Upgrade::Automatic-Reboot en /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

Segundo, ese intervalo oculta la causa. Un servidor puede instalar un kernel en marzo y reiniciarse en junio por un motivo completamente ajeno. Después puede no volver a arrancar. El cambio que dañó el arranque tiene tres meses de antigüedad, por lo que nada de lo que hizo ese día explica el fallo. /var/log/apt/history.log es donde puede encontrar la ejecución que instaló el kernel con el que ahora falla el arranque.

Reinicie de forma intencionada, el día que haya elegido, con la ventana de la consola ya abierta. Este sencillo hábito convierte una interrupción misteriosa en una selección de menú de dos minutos. Si quiere automatización sin sorpresas, mantenga activadas las instalaciones automáticas y desactive los reinicios automáticos. Consulte cómo configurar unattended-upgrades en Ubuntu para conocer los ajustes exactos. Retener los paquetes del kernel con sudo apt-mark hold linux-image-generic los bloquea por completo y también bloquea las correcciones de seguridad del kernel. Trátelo como una decisión con consecuencias, no como una medida de seguridad.

FAQ

¿Cómo inicio un kernel antiguo en un VPS sin teclado?

Abra la consola del proveedor (VNC o serie) y active un reinicio forzado desde el panel de control, porque no puede iniciar sesión para reiniciar correctamente. Cuando la máquina se reinicie, pulse Esc varias veces o mantenga pulsado Shift durante un arranque con BIOS antigua para mantener abierto el menú de GRUB. Elija "Advanced options for Ubuntu" y seleccione la entrada situada debajo del kernel más reciente. Cuando aparezca el indicador de inicio de sesión, ejecute uname -r para confirmar qué kernel está usando y dpkg -l 'linux-image-*' para ver qué otros kernels están instalados. Diagnostique el problema sólo después de que el sistema vuelva a estar en ejecución.

¿Por qué mi VPS no muestra ningún menú de GRUB?

Las imágenes para la nube suelen establecer el tiempo de espera de GRUB en 0 en un archivo de /etc/default/grub.d/, por lo que el kernel más reciente se inicia sin dar tiempo a pulsar ninguna tecla. Establezca GRUB_TIMEOUT=10 y GRUB_TIMEOUT_STYLE=menu en /etc/default/grub y añada GRUB_TERMINAL="console serial" para que el menú también aparezca en una consola serie. Después, ejecute sudo update-grub. Compruébelo con grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, porque los archivos de ese directorio se leen después del archivo principal y pueden sobrescribir su modificación.

¿Debo eliminar los kernels antiguos para liberar espacio en /boot?

Elimine los más antiguos y conserve al menos dos. Un /boot lleno provoca un fallo específico, porque la generación de initramfs falla y queda un kernel sin una imagen funcional. Elimine los paquetes por nombre exacto después de comprobar uname -r, para que el kernel en ejecución nunca sea candidato. Evite ejecutar sudo apt autoremove --purge sin restricciones en una máquina sin teclado, porque la lista de kernels protegidos se regenera cada vez que cambia el kernel y una ejecución en un momento inadecuado puede dejarle con un solo kernel y sin una entrada de reserva en el menú.

¿Las actualizaciones desatendidas pueden impedir el arranque?

Pueden instalar un kernel que después no consiga arrancar, pero no reinician la máquina a menos que Unattended-Upgrade::Automatic-Reboot esté establecido en true en /etc/apt/apt.conf.d/50unattended-upgrades. El patrón habitual es un fallo diferido: el kernel se instala durante una ejecución automática, aparece /var/run/reboot-required y el problema sólo se manifiesta en el siguiente reinicio, semanas después. Reinicie de forma deliberada con la consola ya abierta y lea /var/log/apt/history.log para averiguar qué ejecución instaló el kernel que está iniciando.