Cómo recuperar GRUB cuando un VPS Debian 12 o 13 no arranca en Hetzner Cloud

Guía técnica actualizada (2026)

Cuando un VPS deja de arrancar tras una actualización, un apt full-upgrade, un cambio de particiones o un snapshot, el problema suele ser el mismo: GRUB no encuentra el sistema.

En Hetzner Cloud esto suele solucionarse sin pérdida de datos usando el Rescue System. Si ves mensajes típicos::

grub rescue>
error: no such device
error: no such partition

Esta guía te explica cómo recuperar GRUB en:

Debian 12 (Bookworm)
Debian 13 (Trixie)

El procedimiento es válido para Hetzner Cloud en 2026. Te puede ayudar a resolver un problema con un VPS que tengas en Hetzner.

Por qué falla GRUB en un VPS

GRUB es el cargador que arranca antes del kernel. Si no encuentra:

El UUID correcto
La partición raíz
El directorio /boot
Un kernel válido

el sistema no continúa.

En entornos cloud, la recuperación se hace desde el Rescue System, ya que no hay acceso físico a la consola.

Particularidades de Hetzner Cloud

Antes de empezar, ten en cuenta:

Dispositivo principal

Siempre aparece como /dev/vda (virtio).
No uses /dev/sda (típico de servidores dedicados).

Layout de particiones por defecto

Hetzner Cloud usa uno de estos esquemas:

Tipo de instalación	Particiones
Estándar (la mayoría)	`/dev/vda1` → `/` (una sola partición)
Con LVM	`/dev/vda1` → PV LVM → VG → LV root
Con EFI (raro)	`/dev/vda1` → ESP, `/dev/vda2` → root

Un /boot separado no es habitual salvo que lo hayas creado manualmente.

Recuperar GRUB desde el Rescue System

1. Activar el Rescue

Panel de Hetzner Cloud
Servidor → pestaña Rescue
Activar (SSH key o contraseña temporal)
Reiniciar
Conectarte por SSH como root

2. Identificar particiones

lsblk -f
fdisk -l /dev/vda
blkid

Localiza:

La partición raíz
/boot si existe
Volúmenes LVM si aparecen como LVM2_member

3. Montar el sistema instalado

Caso A: instalación estándar (una sola partición)

mount /dev/vda1 /mnt

Caso B: /boot separado (instalaciones personalizadas)

mount /dev/vda2 /mnt
mount /dev/vda1 /mnt/boot

Bind mounts necesarios

mount --bind /dev  /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys  /mnt/sys
mount --bind /run  /mnt/run

Caso EFI (poco común en Cloud)

mount /dev/vda1 /mnt/boot/efi

Caso especial: sistemas con LVM

Si lsblk muestra LVM:

Activar volúmenes:

vgchange -ay
lvscan

Localizar el LV raíz (ej. /dev/mapper/vg0-root)
Montar:

mount /dev/mapper/vg0-root /mnt

Luego aplicar los bind mounts igual que en el caso estándar.

4. Entrar en chroot

chroot /mnt

Ahora estás dentro de tu Debian real.

5. Reinstalar GRUB correctamente

Instalar siempre sobre el disco completo:

grub-install /dev/vda

Nunca sobre /dev/vda1.

Si aparece un error por restos de otro bootloader:

grub-install --force /dev/vda

Regenerar configuración:

update-grub

Debes ver que detecta los kernels instalados.

Verificaciones importantes antes de salir

Comprobar UUIDs

blkid
cat /etc/fstab

Si un UUID no coincide, corrígelo.

Confirmar que existe un kernel

ls /boot/vmlinuz*

Si no hay kernel:

apt update
apt install linux-image-amd64
update-grub

Salir y desmontar

exit
umount -R /mnt
sync

Reiniciar normalmente

Desactivar Rescue en el panel
Reiniciar
Esperar 1–2 minutos
Probar acceso SSH

Comprobaciones tras recuperar GRUB

lsblk -f
df -h
journalctl -b -p err..alert
dmesg | grep -i error

Si vuelve a aparecer grub rescue>, revisa:

UUIDs
Kernel instalado
Montaje correcto de /boot

Errores frecuentes y soluciones

Mensaje	Causa	Solución
no such device	UUID incorrecto	Revisar `/etc/fstab` y regenerar GRUB
no such partition	Tabla modificada	Confirmar layout con `lsblk`
No kernel detected	`/boot` vacío	Reinstalar kernel
grub-install falla	Disco equivocado	Usar `/dev/vda`
Sigue sin arrancar	Kernel panic temprano	Revisar `journalctl -b -1`

Último recurso: reinstalar desde Rescue

l Rescue System incluye installimage, aunque en Cloud ofrece menos opciones que en servidores dedicados.

Alternativamente, puedes usar Rebuild desde el panel.

Reinstalar es recomendable cuando:

El sistema está muy dañado
Hay corrupción de filesystem
No hay backups
El tiempo de recuperación es más costoso que reinstalar

Cómo evitar futuros problemas con GRUB

Crear snapshot antes de apt full-upgrade
No interrumpir actualizaciones de kernel
Guardar layout del disco:

lsblk -f > /root/disk-layout-$(date +%F).txt

Vigilar espacio libre en /boot
Documentar tu particionado

Si el arranque de tu VPS falla, no es el fin del mundo

Recuperar GRUB en Hetzner Cloud suele ser un proceso rápido si se sigue un método ordenado.

La mayoría de incidentes se resuelven sin pérdida de datos y en menos de 15 minutos.

Los fallos más comunes no son técnicos, sino errores de montaje, UUIDs incorrectos o kernels ausentes.

Sigamos administrando.