VPS no arranca tras actualizar kernel: cómo recuperar

Qué hacer primero cuando un VPS no arranca tras una actualización del kernel

Un VPS que no arranca tras una actualización del kernel suele ser recuperable en pocos minutos, ya que la actualización no eliminó el kernel que funcionaba ayer. Ubuntu instala un kernel nuevo junto al anterior y solo cambia qué entrada inicia GRUB por defecto. Por tanto, el primer paso no es una reparación. Seleccione el kernel anterior en el menú de arranque, recupere el prompt de inicio de sesión y diagnostique desde un sistema en ejecución.

Arreglar esto en un servidor es distinto a hacerlo en un portátil, ya que no hay teclado conectado ni monitor que muestre el error (kernel panic). SSH tampoco responderá, dado que la máquina nunca llegó al punto en que se inicia sshd. Todo lo siguiente se realiza a través de la consola de su proveedor.

Lea su propia consola antes de cambiar nada. El texto en esa pantalla determina en qué clase de fallo se encuentra, y dos servidores que "no arrancan" pueden requerir soluciones opuestas.

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

Abra el panel de control de su proveedor y busque la consola. Los nombres comunes son consola VNC, consola web, noVNC y consola serie. Prefiera la consola serie cuando existan ambas, ya que proporciona texto real que puede desplazar y copiar, mientras que la vista VNC es solo una imagen de la pantalla. Localice este control ahora, mientras la máquina funciona correctamente, y confirme que abre. Buscarlo durante una interrupción le hace perder la calma necesaria. Esa comprobación debe realizarse en los primeros diez minutos en un VPS nuevo, junto a las reglas del firewall y las claves SSH.

La mayoría de los paneles también ofrecen un modo de rescate o imagen de recuperación. Este arranca un sistema pequeño desde la red del proveedor y conecta su disco como un dispositivo adicional, por lo que no se ejecuta nada de su disco. El modo de rescate es el recurso de emergencia cuando el propio GRUB está dañado, y también es el método para copiar datos de un servidor que ha decidido no conservar.

Normalmente necesitará un reinicio forzado desde el panel para acceder al menú de arranque, ya que no puede ejecutar sudo reboot en una máquina a la que no puede acceder. Un reinicio forzado equivale a cortar la alimentación. Los sistemas de archivos sufren un apagado incorrecto, por lo que debe esperar una comprobación del sistema de archivos en el siguiente arranque.

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

Observe la consola desde el momento en que presione reiniciar. Pulse Esc repetidamente durante los primeros segundos, o mantenga presionado Shift en una máquina que arranque en modo legacy BIOS. La ventana de tiempo es breve y el visor de consola suele tardar un segundo en conectar, así que comience a pulsar pronto y mantenga la presión.

Cuando aparezca el menú, elija "Advanced options for Ubuntu". Ese submenú lista cada kernel instalado, del más nuevo al más antiguo, con una entrada de modo de recuperación para cada uno. Seleccione la segunda entrada normal, que es el kernel inmediatamente anterior al más reciente, y presione Enter. El modo de recuperación es distinto: arranca un sistema mínimo de usuario único y sirve para tareas de reparación, no para restaurar sus servicios.

Si el kernel anterior arranca, tendrá un servidor operativo de nuevo. Confirme en qué versión se encuentra y anote los números.

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

La salida de dpkg es su lista de kernels instalados. Si solo contiene una línea, no tiene ninguna alternativa de respaldo, y eso es lo primero que debe solucionar.

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

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 bajo /etc/default/grub.d/, por lo que el kernel más reciente arranca de inmediato y no hay nada que pulsar.

También existe el caso opuesto, donde el menú aparece en pantalla y espera, pareciendo un bloqueo. GRUB registra un arranque fallido y, en el siguiente inicio, puede mantener el menú abierto hasta que alguien pulse una tecla. En una máquina sin teclado, esa espera nunca termina. Si su consola muestra un menú y nada avanza, eso es lo que ha ocurrido. Seleccione una entrada y continúe.

Solucione ambos problemas mientras la máquina esté operativa. 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"

Luego aplique los cambios y verifique que su edición haya persistido, ya que los archivos en /etc/default/grub.d/ se leen después de /etc/default/grub y pueden sobrescribir su configuración.

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 aparecerá en cualquier visor que le proporcione su panel. Los argumentos del kernel console= hacen lo mismo para los mensajes de arranque posteriores. Diez segundos de espera por arranque es un precio bajo por un menú al que realmente puede acceder a las 2 de la mañana.

¿Ante qué clase de fallo me encuentro?

Lea las últimas veinte líneas antes de que la consola deje de mostrar actividad. Cuatro patrones cubren la mayoría de los casos tras una actualización del kernel.

GRUB no encuentra sus propios archivos. Aparece un prompt grub rescue> o un error sobre una partición o archivo inexistente, y no aparece ningún mensaje del kernel. El kernel aún no ha intervenido. Esto ocurre tras un cambio en el disco o la partición, o porque el gestor de arranque se escribió en el dispositivo incorrecto, más que por el paquete del kernel en sí.

El kernel arranca pero no puede montar la raíz. Los mensajes del kernel se desplazan y luego termina en una shell busybox cuyo prompt indica (initramfs), o el arranque finaliza con un pánico por no poder montar el sistema de archivos raíz. El kernel se cargó. El initramfs, que es la pequeña raíz temporal que localiza y monta su sistema de archivos raíz real, no encontró el disco. En Ubuntu, esta shell suele ir precedida de un mensaje que indica que se ha dejado de esperar el dispositivo raíz, mencionando el UUID que buscaba. Copie ese UUID y compárelo más tarde con la salida de blkid.

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

lvm vgchange -ay
ls /dev/mapper
exit

exit devuelve el control al script de initramfs, que reintenta el montaje. Si el sistema arranca entonces, al nuevo initramfs le faltan los componentes de LVM; la reparación consiste en reconstruir esa imagen en lugar de tocar el kernel.

Nada de Linux en absoluto. La consola muestra texto del firmware, una shell UEFI (interfaz de firmware extensible unificada), una pantalla en blanco sin salida del kernel o un bucle de reinicio. El fallo ocurre antes de que Linux se ejecute. Compruebe qué modo utiliza realmente su servidor una vez que vuelva a estar operativo, ya que muchas instancias VPS arrancan en modo BIOS heredado y nunca acceden a la ruta EFI:

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

Un /boot/efi sin montar durante la actualización es una causa común en máquinas UEFI, ya que los paquetes que mantienen la partición del sistema EFI escribieron en un directorio vacío ordinario. El firmware sigue iniciando la entrada de arranque antigua hasta que esa entrada deja de coincidir con lo que hay en el disco.

Existe un patrón más que no es un fallo de arranque. Si llega a una shell de root que indica que el sistema está en modo de emergencia, el kernel arrancó pero el espacio de usuario se detuvo. Esto suele significar que hay una línea incorrecta en /etc/fstab o un sistema de archivos que falló su comprobación. Ejecute journalctl -xb en esa shell y lea el nombre de la unidad que falló.

¿Está dañado el paquete del kernel o el initramfs?

Ambos problemas parecen idénticos desde la consola y requieren reparaciones distintas. Inicie el kernel antiguo y compare los archivos.

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

Debe haber un vmlinuz- y un initrd.img- correspondiente por cada versión instalada, cada uno con un tamaño coherente. Un initrd ausente, o uno mucho más pequeño que los demás, indica que la generación del initramfs falló. La causa habitual es que /boot esté lleno; las pruebas se encuentran en los registros del gestor 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 enumera exactamente qué paquetes instalaron las últimas ejecuciones y cuándo, lo que resuelve cualquier duda sobre qué cambió.

Libere espacio primero si /boot está lleno, luego reconstruya la imagen para la versión que necesite y actualice el menú. Tome la cadena de versión de su propia salida de ls, ya que el marcador de posición a continuación no es 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 con un tamaño normal significa que la imagen ya existe. Si, por el contrario, la imagen del kernel está dañada, o dpkg -l muestra el paquete en cualquier estado que no sea ii, reinstale el paquete:

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

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

Si todas las entradas del menú fallan, arranque la imagen de rescate del proveedor y repare el disco desde fuera. Su disco aparece como un dispositivo sin montar, por lo que no hay nada ejecutándose en él y nada 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 comprometer el siguiente arranque

GRUB puede iniciar una entrada una sola vez y luego volver a la predeterminada. Establezca el valor predeterminado en un kernel de confianza y luego inicie el nuevo solo para un arranque. Si falla, un reinicio forzado desde el panel le devolverá al kernel funcional sin necesidad de ajustar tiempos en la consola.

Defina GRUB_DEFAULT=saved en /etc/default/grub, ejecute sudo update-grub y luego liste los títulos de las entradas para identificar 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 debería mostrar el título elegido como saved_entry. Esa salida es la prueba de que el mecanismo funciona, ya que guardar requiere un /boot/grub/grubenv con permisos de escritura, lo cual en algunas configuraciones no ocurre de forma silenciosa. La entrada 0 es la parte superior del menú, que corresponde al kernel más reciente. Los títulos son más seguros que los números en este caso, ya que los números cambian cada vez que se instala o elimina un kernel.

Por qué autoremove es arriesgado en un servidor sin monitor

APT mantiene una lista de paquetes de kernel que no debe eliminar por cuenta propia. Lea 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 y protege al kernel en ejecución y a los más recientes. El problema es el tiempo. Si ejecuta sudo apt autoremove --purge justo después de reiniciar con un kernel nuevo, la lista protegida ya se habrá actualizado, por lo que el kernel anterior con el que contaba ya no está protegido. En una máquina con teclado, esto es un inconveniente. En un servidor sin monitor, es la diferencia entre elegir una entrada en el menú y montar el disco desde una imagen de rescate.

Mantenga dos kernels como mínimo, y tres cuando /boot tenga espacio. Elimine los antiguos por su nombre después de comprobar uname -r, para asegurarse de no borrar nunca el que está ejecutando:

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

Ejecute ese último comando de nuevo después. Si el conteo pasa de tres a dos, es una limpieza. Si el conteo llega a uno, es una interrupción del servicio esperando al próximo reinicio.

Realice una instantánea antes de la actualización

Una instantánea tomada antes de apt upgrade es la única ruta 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 puede reintentar 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 energía; por tanto, apague el servidor primero si su proveedor admite instantáneas sin conexión. Una instantánea tampoco es una copia de seguridad, ya que normalmente reside en la misma infraestructura que el volumen que copia. Comprender la diferencia entre instantáneas de VPS y copias de seguridad reales determina cuál de ellas le salvará cuando el fallo sea mayor que un kernel.

Esto es especialmente importante en una actualización de versión, donde el kernel, las herramientas initramfs, el cargador de arranque y la configuración de GRUB cambian en una sola ejecución. Tome la instantánea inmediatamente antes de comenzar 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.

Cómo gestiona unattended-upgrades los paquetes del kernel

El paquete unattended-upgrades de Ubuntu instala actualizaciones de seguridad sin intervención, y los paquetes del kernel llegan a través del repositorio de seguridad como cualquier otro. Esto conlleva dos consecuencias.

Primero, el nuevo kernel se instala pero no se ejecuta. Un kernel solo entra en vigor al arrancar. Aparece el archivo /var/run/reboot-required y /var/run/reboot-required.pkgs indica qué proceso solicitó el reinicio, pero nada se reinicia a menos que haya habilitado 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 una razón totalmente ajena, para luego no arrancar. El cambio que impidió el arranque tiene tres meses de antigüedad, por lo que nada de lo que hizo ese día lo explica. /var/log/apt/history.log es donde encontrará la ejecución que instaló el kernel con el que ahora tiene problemas.

Reinicie a propósito, en un día que usted elija, con la ventana de la consola ya abierta. Ese simple hábito convierte una interrupción misteriosa en una selección de menú de dos minutos. Si desea la automatización sin sorpresas, mantenga las instalaciones automáticas activadas y los reinicios automáticos desactivados, y consulte cómo configurar unattended-upgrades en Ubuntu para ver los ajustes exactos. Retener los paquetes del kernel con sudo apt-mark hold linux-image-generic los detiene por completo, y al mismo tiempo detiene las correcciones de seguridad del kernel, así que considérelo una compensación que usted ha decidido aceptar en lugar de una medida de seguridad.

FAQ

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

Abra la consola del proveedor (VNC o serie) y fuerce un reinicio desde el panel de control, ya que no podrá iniciar sesión para reiniciar de forma limpia. Mientras la máquina arranca, pulse Esc repetidamente, o mantenga presionado Shift en un arranque BIOS heredado, para detener el menú de GRUB. Elija "Advanced options for Ubuntu" y seleccione la entrada situada debajo del kernel más reciente. Una vez que tenga el prompt de inicio de sesión, ejecute uname -r para confirmar qué kernel está usando y dpkg -l 'linux-image-*' para ver qué otros hay instalados. Diagnostique solo después de que el sistema esté funcionando de nuevo.

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

Las imágenes en la nube suelen configurar el tiempo de espera de GRUB a 0 en un archivo bajo /etc/default/grub.d/, por lo que el kernel más reciente arranca sin dar tiempo a pulsar nada. Establezca GRUB_TIMEOUT=10 y GRUB_TIMEOUT_STYLE=menu en /etc/default/grub, añada GRUB_TERMINAL="console serial" para que el menú también se envíe a una consola serie y, a continuación, ejecute sudo update-grub. Verifique con grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, ya que los archivos en ese directorio se leen después del archivo principal y pueden sobrescribir su edición.

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

Elimine los más antiguos y conserve al menos dos. Una partición /boot llena es un modo de fallo en sí mismo, ya que la generación de initramfs fallará y se quedará con un kernel sin una imagen funcional. Purgue por el nombre exacto del paquete tras comprobar uname -r, para que el kernel en ejecución nunca sea un candidato. Evite un sudo apt autoremove --purge general en una máquina sin monitor, ya que la lista de kernels protegidos se regenera en cada cambio de kernel y una ejecución mal programada puede dejarle con un solo kernel y sin entrada de respaldo en el menú.

¿Puede unattended-upgrades romper mi arranque?

Puede instalar un kernel que luego falle al arrancar, pero no reinicia la máquina a menos que Unattended-Upgrade::Automatic-Reboot esté establecido como true en /etc/apt/apt.conf.d/50unattended-upgrades. El patrón habitual es un fallo retardado: el kernel se instala durante una ejecución automática, aparece /var/run/reboot-required y el problema solo surge en su próximo reinicio semanas después. Reinicie de forma deliberada con la consola ya abierta y lea /var/log/apt/history.log para encontrar qué ejecución instaló el kernel con el que está arrancando.